Dave,
In a sense, what I'm arguing is that Richtext _doesn't_ work as
currently specified. We've seen arguments on this list against, or at
least major confusion around, <nl>. The <comment> thing is a horrible
kludge compared to the other "tags" or whatever you call them. These
things are nearly show-stoppers; what they do is to isolate richtext
to a formatting code island which very few non-MIME applications will
ever want to visit. The reason I like e-mail so much is precisely
that I can move the messages I have received into other applications,
can edit them, forward excerpts to others, can index them, stuff them
in a database, etc, totally unlike faxes, for instance. With richtext
as it is currently specified, I'll have to make a conversion program
from this botched syntax to something more reasonable. The distance
between them is not very large, but conversion between them will be a
major problem. I'm already cringing at the <excerpt>--</excerpt><nl>
<excerpt>--</excerpt> stuff I'm seeing from Nathaniel. Why can't
those <nl> remain _inside_ the excerpt element? Why is a <nl> tag
needed at the start of so many lines? I'm arguing that a relatively
minor change to, e.g. the comment element, is mandatory for one main
reason: regularity of language. What I want is something like this:
The _comment_ element suppresses presentation of its content.
It may contain text, which is ignored, and any other elements,
which have no effect on presentation. All elements inside a
comment must still obey the rules for matching start- and end-
tags, including, but not limited to, nested comments. A comment
must end in the same element in which it started.
This means that <comment>foo</comment> is ignored in its entirety,
just like it is now. <comment><comment>x</comment></comment> is an
error under the present rules, but makes sense under the above rules.
<a><comment></a><a></comment></a> is legal under present rules, and is
illegal under the new rules. Do we want the present rules?
There might be a need to have some kind of "asynchronous" way to
get rid of unwanted content, be it elements or data. SGML has such a
feature in addition to the element structure, which makes it possible
to handle it during lexical analysis instead of in the syntax. There
are reasons for this, and I don't think we should toss out the lessons
the SGML working groups learned in this process.
Change this, and what you have you done? There is no impact on
the semantics of a comment, it's still ignored, but now it's also
predictable -- you can ignore any random section of text, as long as
you ignore entire elements, and you don't have to look for nested
comments, or hide a nested </comment> as <lt>/comment>. (How do you
undo this latter transformation? You can't.)
| but rather that we want to tune it, make it closer to some other
| spec, or the like.
My argument is not that we make it close to "some other spec".
It's that we make it technically sound. An aberration like the
present "comment" should not make it into a standard.
| While I think that the issues you are raising have a basic merit,
| I think that the effect of pursuing them will be a disservice to
| RichText and, therefore, the community, since it would cause the
| window of opportunity to pass.
This sounds unduly pessimistic. What contenders are there to the
role which richtext would have? The community has expressed (at least
in part) a need for a richer text format -- will it cease to need it
if we make the richer text format syntactically sound?
| The spec has been around, as part of MIME, and commented on for
| some time now.
I think the present debate indicates pretty clearly that it has
been insufficiently commented on. I gave up reading this draft in
disgust a long time ago -- and haven't picked it up until now, because
I didn't think it had any merit at all. As I've said, a hodge-podge
of all and sundry formatting and text description features isn't all
that exciting when you have so much better things to work with. Of
course, it's really great to those who have never seen anything like
it before. I'm not trying to destroy that, I'm trying to introduce
some of the lessons a different community, largely consisting of
people with publishing and large document production experience, has
learned while trying to solve, and solving, a much larger number of
problems, some of them many orders of magnitude more complex.
Best regards,
</Erik>