- From: Eve L. Maler <elm@arbortext.com>
- Date: Sun, 10 Nov 1996 22:14:33 -0500
- To: Charles@sgmlsource.com, Tim Bray <tbray@textuality.com>
- Cc: W3C-SGML-WG@w3.org
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. 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...) >> 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.) >... >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!) >... Eve
Received on Sunday, 10 November 1996 22:12:59 UTC