[Top] [All Lists]

Re: Text/enriched ambiguity

1993-10-29 15:42:35
The problem with the 

<colorentry 0 255 255 0>

example is that there is no matching </colorentry> or 
</colorentry 0 255 255 0>

      Whoah...   hang on.   WHY is this a problem? 

      I've always seen these as "commands" and coded accordingly. 
If you get a <bold> and then a </bold>,  fine.   If you get a <bold> 
and never encounter the </bold>,  still fine.

Maybe, maybe not.  In a stack-based parser, this could be a real
pain in the neck.  It also defeats auto-correction schemes to some
extent.  Have a look at the metamail richtext code which I added
auto-correction to in the lexical analysis: it attempts to rebalance
commands if the user stuffed something up (e.g. through hand-composition).

Unless there is a matching </> command or a different way to indicate
commands that don't need a </>, auto-correction and stack-based parsers
will be defeated.

For the colorentry example, I can't see anything wrong with (to define
two colours):

        <colorentry>red 255 0 0 blue 0 0 255</colorentry>

The extra bracketing cited by someone else seems unnecessary to me.



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