[Top] [All Lists]

Re: Text/enriched ambiguity

1993-10-27 12:26:23
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

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 
one use is to change the attributes of the text in between the parameter 
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 
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:

        <colorentry 0 255 255 0>
        <colorentry 1 0 255 0>


        colorentry 0 255 255 0>
        colorentry 1 0 255 0>

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 


<Prev in Thread] Current Thread [Next in Thread>