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