Re: Recent ERB votes

> From: Tim Bray <tbray@textuality.com>

>  - The proposal for a PI that summarized the empty elements worked around
>    a few of these problems, but introduced a new syntax and was a possible
>    source of inconsistencies.
>  - Falling back to a position allowing only the <e/> syntax solves
>    all the problems cleanly, but makes it *impossible* for a valid HTML
>    document to be XML - several on the ERB felt this was political suicide.
> 
> Bearing all this in mind, the ERB voted, Maler dissenting, that:
> 
>  - XML support only the <e/> syntax for EMPTY elements - this means that
>    all the language in the spec about "undistinguished" EMPTY elements
>    can come out.
>  - In order to make it possible that a valid HTML document can be a valid
>    XML document, the XML spec will state that XML processors, when they are 
>    processing HTML documents, should recognize, in a built-in way, that the 
>    elements declared as EMPTY for HTML 3.2 (BR, HR, IMG, etc.) are empty even
>    without syntactic indication.  The manner in which an XML processor
>    is to decide whether a document is HTML is not constrained by the spec.

While I respect the fact that the ERB undoubtedly thought very hard
about this, I find this decision very unpalatable, much more so that
"introducing a new syntax" to summarize empty elements which would then
allow XML to handle empty elements as they are written in SGML
instances today.

As far as "possible inconsistencies," that seems like an odd argument
to me.  That's like saying having declarations of any kind in any
programming or markup language--in fact, *any* declaration, by virtue
of "making a statement about what will happen"--opens the door to
inconsistencies because the declaration may be a lie.  You might as
well say that requiring an element to start with an STAGO and end with
an ETAGO could lead to inconsistencies because someone might put an
STAGO and then not put the ETAGO.

What's wrong with, e.g.:

	<?XMLEmpty BR HR IMG>

to list the empty elements?  The "new syntax" doesn't seem so difficult,
and I see no more possible inconsistencies than are inherent in any
markup scheme.  Whether you also allow the <e/> syntax is an orthogonal
issue, but I personally would find the "new <e/> syntax" more of a bother
than a simple PI with a list of empty elements, and would rather not have
to worry about explaining or handling it.

Is there any chance this decision can be reviewed?

paul


Paul Grosso
VP Research, ArborText, Inc. and Chief Technical Officer, SGML Open

Email: paul@arbortext.com

Received on Wednesday, 6 November 1996 18:54:05 UTC