ietf-822
[Top] [All Lists]

Re: Text/enriched ambiguity

1993-11-27 12:56:32
I know I've let this discussion lapse for a couple of weeks, but I think
I've got a handle on it at last..... 

Excerpts from TODO: 10-Nov-93 Re: Text/enriched ambiguity
rhys(_at_)cs(_dot_)uq(_dot_)oz(_dot_)au (661) 

Leave it as is.  I'm happy with it.  Maybe just a couple of words about 
whether commands inside nest or whether the parameters end at the </param> 
(this later one is my preferred option). 

It's occurred to me that, since the syntax of what falls between <param>
and </param> is left undefined, for future extensions, it's no big deal
to constrain it in such a way that EITHER approach to parsing will work.
 Since the goal of text/enriched is particularly to be easy on the
reading end, I like this approach a lot, and it really places minimal
constraints on someone who wants to use <param>.  Here's another pass at
the relevant text: 

Param -- Marks the affected text as command parameters, to be
interpreted or ignored by the text/enriched interpreter, but NOT to be
shown to the reader.  The syntax of the parameter data (whatever appears
between the initial "<param>" and the terminating "</param>") is left
undefined by this memo, to be defined by text/enriched extensions in the
future.  However, the format of such data must NOT contain nested
<param> commands, and either must NOT use the "<" character or must use
it in a way that is compatible with text/enriched parsing.  That is, the
end of the parameter data should be recognizable with EITHER of two
algorithms:  simply searching for the first occurence of "</param>" or
parsing until a balanced "</param>" command is found.  

Is there anyone who finds this unacceptable?  If we can agree on
something like this, I'm ready to release a new draft of the
text/enriched spec... -- Nathaniel 

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