Re: B.10 Empty elements?
> > If minimization is not allowed where content is possible, and any tag
> > without content is defacto, empty, then why should I need the </e>?
> <Chapter><title>this is a 200-page chapter, sorry</title>
> <P> .....
> We can't process the PGBRK and the other elements inside Chapter until
> we've seen </Chapter>, and hence have deduced that there is no </PGBRK> --
> otherwise we'd think all the <P> elements were within PGBRK.
Not disputing your case case:
1. Is the extreme case the common case? I would have a chat
with an author that produced a 200 page chapter.
2. Isn't this a case where the DTDlessness bites? IOW, if a
DTD is allowed, you know that <PGBRK> is minimized. If a DTD
is allowed, but is not used, is that a problem with XML or
3. Is the processing time severe for the case you state?
I realize this question has many hands to argue with.
> Of course, it could simply have been a user error...
Yes but that is the reason for validation in authoring
where I believe a DTD is at its most useful. The case
for network is determined by the operations the receiver
must perform to do *something useful* which seems to be
in these discussions, be rendering. I agree completely
that the DTD should not be needed there, but that unless
one can *spot* the <pgbrk> and determine it is empty,
it is needed. So, wouldn't it be a design error on the
transmitter's part not to indicate a DTD is needed to
> If empty elements were marked syntactically, e.g.
> then there would be no problem.
> This can be done by allowind @ as a name start character, and then
> saying that in XML, empty elements have names starting with @.
> If SGML could be augmented to allow a different open tag delimiter for
> EMPTY elements, it could use <@, and the entire problem would vanish.
That appears to me to be a solution. Doesn't this break compatibility
with SGML? Is it something that SGML 97 could quickly address?