Re: XML, HTML, SGML, life, the universe, and everything
On Mon, 11 Nov 1996 10:15:44 -0500, "Eve L. Maler" <firstname.lastname@example.org> wrote:
>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.
There is an alternative even for this point: don't support name token values
(enums) at all in XML 1.0. Then you are 100% conforming and you don't have to
explain the indefensible. Enums can be added as a feature in 2.0 when the
constraint is removed for SGML97.
White space handling is problematic enough in 8879 that every product interprets
the rules its own way. No one (least of all me) would complain about XML
introducing a reasonable interpretation of how to handle this area (particularly
as it is application behavior, not purely parsing behavior).
But breaking the enum constraint is a flat out obvious contradiction of the
standard. Moreover, it is unnecessary, since you don't need to declare enums as
anything but nmtokens; more than that is useful only for validation and
documentation -- it can wait for XML 2.0.
The concept of conformance is technically vital to SGML; adherence to the ISO
standard is our political lifeblood. Because of that, even WG8 itself was
unwilling to jump the gun on SGML97 when we developed the HyTime TC. We lived
with unpleasant constraints that we know will be removed in SGML97.
If you remove this one unnecessary egregious conflict with the standard, XML
will indeed conform to SGML. There will be no reasonable grounds for anyone to
claim the contrary.