ERB meeting, 30 October 1996
The ERB met this morning, 30 October 1996. Present: Bosak, Bray,
Clark, DeRose, Hollander, Kimber, Maler, Paoli, Sharpe,
Sperberg-McQueen. Absent: Magliery.
The rationale given has not been checked by the ERB and is subject
to correction and supplementation.
B.10 What form should EMPTY elements take, if there are EMPTY
elements in XML: <e>, <e/>, <e></e>, or <@e> (where the NET
string is assumed to be '/>' and '@' is assumed to be an
XML-specific flag for names of EMPTY elements; in SGML systems,
'@' to be added to the set of name-start characters).
- to allow the form <e/> to be used in XML documents, with or
without element declarations
- to allow the form <e> to be used in XML documents, if and only if
the elements are declared as EMPTY in some way (which ways are
allowed or required depends on other open questions, such as D.2)
- to use the string '/>' as the NET delimiter in the SGML
declaration of XML documents
- to specify that the <e> form is allowed for compatibility reasons
Rationale: Allowing the form <e> simplifies learning and conversion
for existing SGML and HTML documents and users -- one of the rare
cases where these two populations seem to have the same requirement.
Allowing some self-identifying form simplifies the parsing of
documents significantly, and makes it much easier to work without
explicit declarations. Allowing both forms was felt to be a useful
compromise -- part of the committee would have preferred to allow
only one form, but was evenly split between the 8879 form and the
self-identifying form. The entire committee felt unanimously,
however, that allowing both forms was workable, particularly if the
spec makes reasonably clear that one is the preferred form and the
other is included only for compatibility reasons.
The choice among the proposed self-identifying form was motivated in
part by pragmatic considerations and in part by aesthetics. If XML
EMPTY elements carry end-tags then the EMPTY keyword will have
different meanings to an XML and an SGML system; this was felt to
entail too many complications, so <e></e> was ruled out. The form
<@e> was not felt significantly easier or harder to implement than
the form <e/>, though this may vary in different implementations.
Both <@e> and <e/> may be compatible or incompatible with whatever
delimiters for empty elements are present in SGML-97. There was a
clear preference, however, for the form <e/>, based in part on the
visual effect of the slash.
-C. M. Sperberg-McQueen