Re: XML, HTML, SGML, life, the universe, and everything

At 10:36 AM 11/11/96 GMT, Charles F. Goldfarb wrote:
>>>>Existing SGML tools can, if they're compliant, read XML today modulo
>>>>*only* overlapping enumerated attribute values and perhaps some 
>>>>mild inconsistencies as to which RE's are where.  
>>>
>>>The former makes XML *not* conforming SGML. 
>
>You didn't address this point, Eve.

True.  That one is incompatible.  (I snipped out the parts I agreed
with.)  The ERB has made some incredibly hard decisions, all to keep
compatibility with SGML design, and in the process often went against
several of our other principles.  Perhaps the notion of a successful
SGML on the Web is incompatible with SGML86.  If so, we've pared down
the true incompatibilites to a tiny list, all because of our
commitment to SGML86 and our belief in the SGML97 process.

>>The latter could avoid being
>>>nonconforming if the spec were written carefully (see below).
>>
>>(No matter where the REs are, the *document* would still be valid SGML. 
>>It's the *parser behavior* which would differ slightly from "XML 
>>processor" behavior...)
>
>Conforming SGML means that any conforming system will produce the same ESIS. At
>present, an XML document is not conforming SGML. 

But if the XML document is valid -- that is, a full DTD is available 
(leaving aside for a moment whether the DTD's attlists are all 
8879-valid) -- the ESIS is essentially the same, right?  "ESIS" is 
a slippery concept anyway, and the major parsers already produce some
differences regarding REs, as I understand it.

>>Regarding *writing* XML, it's certainly possible for existing tools
>>to need adjustment.  Most SGML-aware editors normalize things like
>>NET.  In order to write them out again, they'd need to be modified.
>>(Not that this is achingly hard to do.)
>
>True, but it is the parsing that determines conformance, and you haven't
refuted
>my point: XML at present is not conforming SGML.

I'm sorry, but I think this is missing the point of XML somehow.  I'll 
let my remarks above stand.

>>The problem is that only one NOTATION attribute is allowed on any
>>one attlist, and this would be a major invasion of the user's markup
>>design space.  (If 8879 were to relax this, it could open up a whole
>>new way to do architectural forms!)
>
>Not at all. The notation attribute need only be attached to the document
>element, as everything else is part of its content. Subelements can have their
>own notations as well. This is certainly a smaller "invasion of the user's
>markup design space" than the  use of dedicated empty element type names or
>built-in entity declarations. And, it makes XML a conforming subset of SGML,
>rather than a W3C competitor to ISO.

I don't understand how attaching white-space semantics to the document
element will help all the other subelements, since it differs on a
per-element basis.  And the moment you add a notation to a subelement,
it can no longer have any other notations.

        Eve

Received on Monday, 11 November 1996 10:14:22 UTC