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. ...
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.
These are valid points. Please consider, and let me know
what you come up with, the idea of enhancing a stack based-parser.
I agree about the usefulness of auto-correction, and my suggestion
would complicate that ... slightly. All you need is a bit somewhere
saying "this must be matched within context" or not.
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>
I'd say try,
<colorentry>red 255 0 0</colorentry>
<colorentry>blue 0 0 255</colorentry>
The extra bracketing cited by someone else seems unnecessary to me.
Above, I used the <command> / </command> method
to delimit the colorentries. I'm not completely happy with that
because to me it is less generic than allowing commands without
matching /commands.
See for yourself: it's easier to take the string
delimited by angle brackets and act on the "verb" (which may
or may not have parameters) than to switch into and out of
"colorentry modification mode".
Cheers,
Rhys.
--
Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems