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.
Cheers,
Rhys.