ietf-822
[Top] [All Lists]

Re: Text/enriched ambiguity

1993-10-30 13:27:53
Observation from the committee on spotting of square wheels....

Going back the the parent SGML syntax might be instructive here.  While
any of the methods cited could be made to work with a properly-defined
DTD,  the most obvious would be either:

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

In the first case, the parsing rule is that "colorentry" gets one
or more <c> subelements: any other type of subelements are bogus.  And
each "c" element consists of a reserved-string color name, followed by
its parameters.

In the second case, one has to reserve the color names into element
names--probably a disadvantage if you wanted to be able to name "green"
but otherwise more a matter of aesthetics than anything else.

In either case, it might be sensible to permit/require eliminating the
end-tags on the color elements, so we would actually see:

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

Not that these schemes are robust against later needing to add another
parameter or two to the colors (intensity or brightness, perhaps) and,
modulo the "yellow" issue to adding new colors.  And it isn't necessary
to invent trick delimiters that would have to be handled in a special
way in the lexical mechanisms.

This is not a suggestion that this be adopted for text/enriched, or that
it is the best alternative, only an attempt to populate the data space
with an approach with which there is successful operational experience.

  --john

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