This discussion seems to have reaffirmed the utility of <param> (or
something like it), but we still haven't resolved the issue of syntax
inside a <param> ... </param> block. Should a simple text/enriched
process read blindly until the </param>, or should it parse for
text/enriched structures, check for nesting, etc.? Alas, I think there
are good arguments both ways....
Hmmm ... we can have it both ways I think:
(a) The contents of the <param> block follow text/enriched
conventions. i.e. '<' becomes '<<', commands have the
usual syntax, etc.
(b) There are no requirements on balancing commands: the
block extends until the next </param>.
Thus, we can have <param><colorentry>...</colorentry></param> or
<param><colorentry>...</param> or any number of other different
structures. If some twisted individual puts <param><param></param>
into the text it is interpreted as a parameter block containing
<param>.
We could make some recommendation that the first element of a
parameter block must be a command which indicates what kind of parameter
block it is, so that implementations that understand parameter
blocks can skip those blocks that aren't for them.
I don't think this would screw up parsers too much: the lexical
analyser still pulls text/enriched tokens out in the normal way,
so it isn't like <comment> or <verbatim> which required special
handling at the lowest lexical levels. The default handling is
to just toss away tokens until </param> is encountered.
Comments?
Cheers,
Rhys.