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

On Sun, 10 Nov 1996 22:14:33 -0500, "Eve L. Maler" <elm@arbortext.com> wrote:

>At 07:47 PM 11/10/96 GMT, Charles F. Goldfarb wrote:
>>On Fri, 08 Nov 1996 12:17:15 -0800, Tim Bray <tbray@textuality.com> 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.

>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. 

>>> XML is a subset of SGML in spirit and in fact, and
>>>XML is designed so that the adjustments required in existing SGML tools
>>>are trivial.
>>
>>The above statement is inconsistent on its face. If XML is a subset of 
>>SGML "in
>>fact", why should existing "compliant" SGML tools require any adjustments?
>>One
>>can argue (but not here, please) whether a DTD-less markup language is 
>>a subset
>>of SGML in spirit, but to be one in fact means that conforming XML
>>documents
>>must conform to 8879. At present, they don't.
>
>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.

>>2. XML's white space handling should be defined as a data content notation
>>(XMLWS), applicable to the document element. (Suitable shortref mappings 
>can
>>prevent normal SGML RE handling from taking place.) The behavior of the
>>notation
>>can be dependent on attribute values and/or element types, so existing XML
>>white
>>space behavior and/or other useful behaviors could be supported. (It is
>>possible, incidentally, that full SGML applications might want to use this
>>notation.)
>
>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.

Received on Monday, 11 November 1996 05:37:05 UTC