It has been pointed out to me that the specification for text/enriched
is unclear about what interpretation is to be given to the data between
<param> and </param>. In particular, should such parameters be parsed
as text/enriched data? I've gone back and forth on this, but I think
what it comes down to is that if we DON'T parse it, we complicate
text/enriched parsers as much as the now-discarded "verbatim" did. So
I'm thinking of adding the following sentence to the definition of
"param":
Anything between the initial "<param>" and the terminating "</param>" is
subject to normal text/enriched parsing, nesting, etc.
Isn't this ambiguity inherent in the two different uses of extensions? That
is,
one use is to change the attributes of the text in between the parameter
(e.g.
your color example) and one is to include additional information/data that
should not be parsed (e.g. a color table that is then used by another
extension
to reference colors by index). Seems like both capabilities are necessary -
the extension facility should provide for both uses.
On the other hand (am I out of hands?) you clearly need to address the
parsing complexity issue. Perhaps the way to address the data problem is to
force it into standard enriched syntax, so you have:
<colortable>
<colorentry 0 255 255 0>
<colorentry 1 0 255 0>
</colortable>
vs.
<colortable>
colorentry 0 255 255 0>
colorentry 1 0 255 0>
</colortable>
This places size restrictions on how the data can be organized, but perhaps
that's worth
the trouble to restrict the parsing headaches. Yet another compromise
would be to be
able to include the data as in my second example (that is, its plain text
but doesn't appear
in the normal textual output) but require that it be parsable as standard
enriched text. This
seems like the best approach. That means that you still have to come up
with a syntax
for differentiating whether an extension should include or exclude embedded
text.
Terry