[
Lists Home |
Date Index |
Thread Index
]
Welcome to my world. :)
Errata that create incompatible changes between iterations are part and parcel of the W3C process. Quite frankly, there are more significant errata and design issues to worry about than the fact that the XML Core working group took a few years to fix a gaping hole in the XML 1.0 REC.
-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
Sent: Fri 10/25/2002 8:35 AM
To: Dare Obasanjo; John Cowan
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] We need SAX features to say a parser supports XML
At 7:55 AM -0700 10/25/02, Dare Obasanjo wrote:
>I'm typically against errata that make sweeping changes but I have
>to acknowledge that the purpose of errata is to fix mistakes. The
>original policy for the version number in the XML declaration was
>broken and extremely short sighted. This is a glaring mistake that
>should have been fixed a long time ago but was probably left to lie
>since no other versions of XML were in the works at the time.
Errata can fix editorial mistakes. They can correct spelling errors.
They can make unclear parts of the spec clear. They can remove
confusing parts of non-normative sections. They can even change the
BNF grammar provided that the new grammar is equivalent to the old
one. For instance the second edition removed the productions for the
xml:lang attribute values. This change was acceptable because it did
not affect what was and was not well-formed since those productions
were not actually referenced. Parsers that had enforced those
constraints were demonstrably in error. At the extreme, I'm willing
to accept a fix for an actively contradictory and inconsistent part
of the spec.
However, errata cannot fix design mistakes. There is nothing
inconsistent or unclear about XML 1.0's treatment of the version
attribute. The specification lays out very clearly what parsers may
and may not do with it, and what is and is not well-formed. It might
have been better to have used a different production for version six
years ago. However what was used allowed any string. Changing that
now changes the fundamental definition of the XML language. By
incorporating this erratum you create a new language that is similar
but not identical to XML 1.0. (Actually I suspect it is a strict
subset). Any way you slice it, though, it isn't XML 1.0.
If the working group issues errata simply because it can design a
better language with hindsight, then there's a hell of a lot more we
can fix that's a lot more important than this. However, this is
properly the work of a new specification, not an erratum. A
different, incompatible, grammar is a new language. If the W3C
insists on calling all of the different languages they're producing
"XML 1.0", then the rest of us are going to have to start talking
about the 2001 version of XML 1.0 vs. the 2002 version of XML 1.0 vs.
the June 27, 2003 version of XML 1.0. It will just be one big,
honking mess that confuses everyone who isn't enamored of language
law.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| XML in a Nutshell, 2nd Edition (O'Reilly, 2002) |
| http://www.cafeconleche.org/books/xian2/ |
| http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
|
