Re: B.10 Empty elements?

lee@sq.com wrote:
> 
> > If minimization is not allowed where content is possible, and any tag
> > without content is defacto, empty, then why should I need the </e>?
> 
> Consider
> 
> <Chapter><title>this is a 200-page chapter, sorry</title>
> <PGBRK>
> <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 
practice?

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 
process?
 
> If empty elements were marked syntactically, e.g.
> <@PGBRK>
> 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?
Charles?

len

Received on Monday, 14 October 1996 20:24:28 UTC