The latest draft for text/enriched has an "extensions" parameter and an
<extension> command that depends on it, neither of which I like.
Nathaniel and I exchanged private mail about this, and he suggested I
post my analysis to the list. So here we go.
The draft says about "extensions":
This raises the obvious question of why the extension in use needs to
be declared at all. The answer is that by declaring the extension
mechanism in use, cooperating implementations can extend text/enriched
in a manner that allows them to be sure that both share the same
interpretation of an extended command.
So what we are guarding against is the situation where e.g. <red> can
have two different meanings, depending on the value of the `extensions'
parameter. What if the two extensions are used in the same document?
Furthermore, to use non-X-token extension names or non-x-token
commands, IANA registration is required anyway: the danger of
conflicting command names does not exist at all. Okay, it is possible
that two different meanings for <x-red> may develop, but this is
inevitable for private extensions (which is what they are). This can be
sorted out when the commands are offered for IANA registration.
Thus, I think the `extensions' parameter is useless and complicates
things unnecessarily.
Now, about <extension>: the draft specifies that the contained text
should be ignored
if the named extensions from the extensions parameter are not recognized.
What if the UA recognizes *some* extensions but not all of them? Which
<extension>-enclosed texts should it ignore?
I believe this is the wrong approach and there is a better way, which
also has other advantages. Let us replace <extension> with a new
command <param> whose purpose is to encapsulate parameters to
commands. An example of its use would be
<postscript-font><param>Times-Roman-12pt</param>
... some text ...
</postscript-font>
The semantics of <param> would be like <comment> unless directly
preceded by a recognized command. Thus, in the above example interpreters
that recognize <postscript-font> would parse the parameter text and others
would ignore it altogether. It would thus be safe to define new
commands with parameters, since the parameter text would be ignored
by older implementations (just like the command).
This would also solve the problems of restricted character set and
length that are caused by embedding parameter information in command
names as in <postscript-font-Times-Roman-12pt>; it would keep the
command namespace clean (otherwise it would soon be cluttered with
things like <color-*>) and preserve the original function of
<comment>: comments, never to be parsed by the interpreter.
By the way, do people really want to use comments in their enriched
texts? Its not like including comments in TeX or nroff macro
definitions; these languages are much more complicated.
--
Luc Rooijakkers Internet:
lwj(_at_)cs(_dot_)kun(_dot_)nl
Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands tel. +3180652271