OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] We need SAX features to say a parser supports XML

[ 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
	| 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/    |


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS