I shouldn't be confusd with someone who has intimate knowledge about
full-blown SGML. My expertise is much more focused on Internet mail.
I agree with Mark Keasling in that it is best to think of <param> as
<comment> gratuitously renamed. I believe the wording of the draft
spec supports that view and that view makes it easier to write a
parser that can deal with both richtext and enriched depending on a
mode variable. I don't think anyone has made a convincing case that
there are any real advantages of any other view.
In text/richtext, <comment> could nest--when parsing it, you had to at
least tokenize everything, recognize <comment> and </comment>
commands, and keep a depth count. That minimal requirement on parsers
also exists in text/enriched.
The restrictions placed on composers of text/enriched should
necessarily be stricter than the requirements made of parsers. A
parser that chose to do so should be able to continue to maintain a
command stack and merely turn off output while inside <param>. To
allow parsers to choose this strategy when it is convenient for them
to do so, composers should have the same command nesting restrictions
inside <param> as they do outside <param>.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up