Re: B.10 Empty elements?

At 12:33 AM 10/18/96 -0400, Gavin Nicol wrote:
>>   I think empty elements are needed, and that the <empty></empty> syntax
>>is unnacceptable. I think we should ignore the BUGs in ESIS that reflect
>>the view that empty elements are useful containers that _cannot contain
>>anything_. Empty elements are useful for _point_ phenomena in a text. They
>>identify a position in the text and attach properties to it (a good example
>>being TEI milestones). This is an important kind of thing to describe, and
>>is accordingly common.
>>
>>I think that in this case we can diverge to one of the NET syntaxes (I like
>><point-tag/> myself). We are already going to have to explain that without
>
>I am 100% in agreement here.

>I am another one that would like to see regexps allowed for content
>models, though I'd go further, and hope to be able to use regexps for
>content and attribute value validation as well. Still, given the SGML
>compatability rule, I guess this is out of the question....

Indeed. The SGML compatibility rule [*] is the real problem, in that the (core)
concrete syntax (actually, even the abstract syntax) is *lexically*
inadequate. The issue has always been one of tokenization. The denotation
of an empty element is indistinguishable from the start tag of an element
with content: in SGML systems the DTD has always been present to resolve 
the ambiguity on what from a lexical point of view are essentially "semantic"
grounds. Without a DTD, the alternatives are restricted to either disallowing
empty elements altogether or disambiguating them *lexically*.

If a NET variant can be made to work (I still don't see how, though), that's
fine. Otherwise, IMHO, since the need for empty elements is clear cut, it's
time to bite the bullet and seriously consider a syntax that requires
preprocessing before it can be accepted by, ah, legacy SGML processors.
(For instance, the STAGC proposal discussed a few months back on CTS.)

[*] This rule tends to be invoked much more often in the interests of
*forwards* compatibility of legacy systems [will old tools grok new stuff?]
than the backwards compatibility of new specs [will new tools grok old stuff?]


Arjun
--
"Features whose purpose is to cause errors should be removed" -- Erik Naggum

Received on Friday, 18 October 1996 16:08:11 UTC