There are very few existing text/enriched parsers, so this isn't a problem,
and since <param> is not used by any generator at the moment as far as I
know, we have a chance fix them all before someone does need <param>.
But some of us are using a "simple SGML" parser for
richtext and will use mostly the same code for enriched. But ...
If you thinking of feeding text/enriched into older text/richtext parsers,
then that won't work anyway because text/richtext parsers don't understand
the '<<' sequence, so this isn't a problem.
You're telling me that it's not a "drop in". Fine.
There's nothing intrisically wrong with <a b c d> as an idea except that it
is a special case of command parsing that WILL break existing parsers, much
more than <param> usage, as discussed in my previous message, would.
You just said "There are very few existing text/enriched parsers",
so why is this a problem? I understand and appreciate the capability
of auto-balancing but place a greater value on:
message context --- outside the angle brackets
operators (commands) --- inside the angle brackets
Now I'm a newbe to SGML, well ... I've been watching it for
several years, but only recently started coding for it, so I may be
all wet with this goal. John? You seem to know it pretty well.
<param>
also gives the flexibility of having multiple nestings inside a parameter
block if that every becomes necessary.
Now this is an excellent point with which I can't argue.
For me the question is: is nested <param> a real possibility?
I'm all for maximum open-endedness.
Cheers,
Rhys.
--
Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems