Re: B.10 Empty elements?
At 06:49 PM 10/12/96 EDT, email@example.com wrote:
>> B.10 What form should EMPTY elements take, if there are EMPTY elements
>> in XML: <e>, <e/, or <e></e> (where '/' is assumed the NET string)
>> (7.3, 11.2.3)?
>Only one of these, <e></e>, can be parsed reliably without a DTD,
>unles you are prepared to use lookahead to the end of the document or
>untiul the next close tag of a container.
>Two other possibilities:
>(1) use a naming convention, e.g.
>(1b) add something (e.g. @) as a name start character:
> where all elements starting with @ are EMPTY, by convention.
> An amendment to SGML could allow <@ to be a delimiter to start
> a tag of an EMPTY element, and then the convention would become
> supported syntax.
>Both of these are using syntax, but are using a kind of syntax for
>which there is precedent.
>I don't have strong feelings on these, but wanted to raise them since
>they are both compatible with SGML as it stands today.
Another couple of possibilities:
(2) provide the necessary markup declarations in a "partial DTD" so that
empty elements can be understood:
<!ELEMENT e - O EMPTY><!--or whatever-->
(2b) provide the necessary "instance parameters" rather than whole markup
declarations (which generally provide more info than is needed for
read-only processing functions):
<?XML empty e><!--or whatever-->
These relate to B.2, required vs. optional DTDs. I find the idea of
partial DTDs really appealing, since you don't have to create redundant
PIs (which could possibly get out of sync with the original DTD), but also
find the PI idea appealing because certain kinds of markup declarations
contain a lot of overkill info. I prefer both of these over the naming
convention ideas because the latter mess up the user's available GI
If supplying instance parameter in whatever form is a possibility, then
there's no reason to ban EMPTY elements (which are quite popular in many
DTDs today) from XML, and we can gracefully do away with the need to
supply the extra info if SGML97 starts allowing the end-tag.