[Top] [All Lists]

Re: Text/enriched ambiguity

1993-10-31 21:42:19
      I'd like to see that too.   But I say we already have it. 

      This is why I like the 

              <colorentry red 255 0 0> 

Leaving aside the need to determine what commands don't need a balancing
</> command, I may just point out that this will defeat another of my
auto-correction schemes: if I am parsing a command name and I encounter
a whitespace character, I assume that the '>' was left out or truncated
in some fashion, and I insert it myself.  This is in the interests of
minimising the number of characters that are skipped over to find a
matching '>' when something goes wrong.  I could no longer make this
assumption with commands such as yours.  Maybe my lexical analyser is
just a little too paranoid. :-)

The opposite could very well happen.   It is arguable that any 
SGML-ish parser should ignore commands it doesn't understand, 
passing the text unmodified,  in which case you could say that 

              <colorentry> red 255 0 0 </colorentry> 

                      *must* be result in "red 255 0 0" being 
displayed as part of the message. 

This is the default behaviour for text/enriched at the moment, so we
don't have the SGML/HTML problem.  It's also why we need a general command
like <param>, so we can wrap up "viewer directives" like so:

        <param><colorentry> red 255 0 0 </colorentry></param>

Then, a parser that doesn't understand <colorentry> can say "I don't know
what this is, but I can safely drop it".  Maybe my previous message wasn't
very clear, but this is what I was getting at.

Now, since there is only one mechanism to indicate where viewer directives
occur, we can invent a different syntax for <param> blocks if we like.  To
extend my previous example, and using '()' instead of '{}':

        <param>colorentry(red(255 0 0) blue(0 0 255))</param>

But, I am still unconvinced we should define such a syntax now, but rather
say that <param> is where it will happen and that we'll leave it until
experimentation suggests what syntax is best.



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