W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: Shortrefs fatally flawed

From: David G. Durand <dgd@cs.bu.edu>
Date: Wed, 2 Oct 1996 13:58:27 -0400
Message-Id: <v02130509ae785b2e9375@[]>
To: w3c-sgml-wg@w3.org
At 12:36 PM 10/2/96, Paul Prescod wrote:
>At 11:09 AM 10/2/96 -0400, David G. Durand"  (David G. Durand wrote:
>>   I just realized that we are seriously hosed if we endorse the use of
>>shortrefs and some pseudo-element to implement an SGML-compatible a quoting
>>syntax for XML. Say, we define a pseudo element <pe>, for the sake of
>>argument. Now we need to document a restriction that no element may be
>>called <pe>, or else we will generate a terribly wrong ESIS.
>That doesn't seem like a big deal to me. I can't create an element called
>FULL_NAME either. =) (okay, okay, in the RCS)

Yes, but how would feel about a compiler that said you can't use the
variable name "i" because it's needed to keep FORTRAN compatibility. It's
bad because it's an ad-hoc restriction with no internal justification in
terms of the structure of XML. (We're not using the RCS for names anyway,
if I understood the internationalization thread). I suppose we add some XML
non-NAMECHAR to the SGML delcaration, and use that in the element name.
Since that only makes the converted SGML ugly, I don't have a problem with

>>We are also
>>likely to make the process of creating content models extremely difficult,
>>due to the name conflict,
>What's so difficult about avoiding a name conflict?

explaining it so it doesn't sound like a hack. A task made harder, of
course, because it is a hack.

 SGML has enough rules that say "something simple, BUT NOT some random
special case". This is a classic design problem. For an SGML example, try
to make a SHORTREF containing the character 'B' sometime.

  -- David

RE delenda est.

David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science          | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/
Received on Wednesday, 2 October 1996 13:54:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:03 UTC