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] Who can implement W3C XML Schema ?

[ Lists Home | Date Index | Thread Index ]

XML Schema Part 1 needs to be rewritten. It is difficult to read and does not seem to be completely understood by anyone from implementors to the people whose names appear as editors of the document. The tutorial is next to useless to implementors since it is non-normative and also contains bugs. 
PS: It is interesting that although multiple contributors to this email thread on XML-DEV mention their satisfaction with Microsoft XML schema processors you ignore them and mention Xerces [which in fact was complained about] and MSV[which was mentioned as being the only other parser that may have APIs as good as the Microsoft APIs by the particular person who mentioned it]. 

	-----Original Message----- 
	From: Jonathan Robie [mailto:jonathan.robie@softwareag.com] 
	Sent: Thu 3/21/2002 6:58 AM 
	To: Ronald Bourret; xml-dev@lists.xml.org 
	Cc: www-xml-schema-comments@w3.org 
	Subject: Re: [xml-dev] Who can implement W3C XML Schema ?

	At 10:48 PM 3/20/2002 -0800, Ronald Bourret wrote:
	>Jonathan Robie wrote:
	> > 3. In places where the spec is not clear, or where you as an implementor of
	> > XML Schema find it difficult to implement, let's see some email traffic
	> > sent to XML Schema.
	>In all honesty, will this do any good?
	I am not sure whether you are asking only whether point 3 will do any good.
	My guess is that some things help more than others.
	1. Putting pressure on companies to be compatible with XML Schema will
	clearly make a difference. If people's marketing departments know that
	people really want conformance, conformance will improve.
	2. Pointing out ambiguities and bugs in the XML Schema spec will also
	clearly help. These are taken very seriously, and they really are resolved.
	3. Pointing out things that are difficult to implement probably makes less
	of a difference - we have enough implementors on the XML Schema WG that we
	know what is hard to implement, and these things are being discussed within
	the Working Group already.
	>First, people (and not just on xml-dev) have been complaining for a long
	>time about how difficult the XML Schemas spec is to read. While the WG
	>should be credited for writing the tutorial in response, they didn't fix
	>the spec itself. While I'm sure there are many reasons for this -- I
	>would imagine wanting to finish in a timely fashion being one of the
	>main ones -- the consequences of this decision are now making themselves
	>felt in interoperability problems.
	XML Schema Part 1 is a real bear to read. I have a hard time reading it
	myself, and I'm on the Working Group.
	The tutorial is extremely helpful for users, but inadequate for
	implementors, who must use the spec itself. Realistically, I doubt that
	Part 1 will become easy to read, though it may become easier. What *is*
	likely, though, is that we can clarify ambiguities, fix bugs, and possibly
	remove some of the areas of complexity that are not being implemented
	correctly anyway.
	>Second, I don't think that rewriting this sentence here or clarifying
	>that paragraph there will really do much good. The difficulty of the
	>language pervades the spec and I feel that the only real solution is to
	>rewrite the spec from scratch. Given the number of different
	>interpretations that already exist in the form of conflicting schema
	>tools, it seems unlikely that this would introduce any new problems.
	Here, I disagree.
	The Formal Description really does account for most of XML Schema:
	I think the Formal Description is useful as an overview of how complex XML
	Schema really is under the hood, and it is nowhere near as bad as I had
	once thought. The things that it does not describe are listed in Appendix
	B. Personally, I would like to see us finish the Formal Description, make
	it normative, and make XML Schema agree with it.
	I also think we need to use test suites and public pressure to get schema
	tools to actually do what the spec says. Yesterday, two implementations
	were nominated as good: MSV and Xerces. If good implementations are
	available, the presence of bad implementations is not a problem, as long as
	people know what the good implementations are.  Even the good
	implementations probably aren't good enough - but do keep in mind that the
	XML Schema REC is not yet a year old, and compatibility does seem to be
	improving significantly.
	I don't find XML Schema graceful or beautiful, but I do think it is useful,
	and it is widely implemented in commercial products. I do find RELAX-NG
	both graceful and beautiful, but commercial support for it is very limited.
	Personally, I never liked SQL, and I used Quel as my relational query
	language back when I used relational databases, because I liked the
	language better. It was cleaner, more orthogonal, and just made more sense
	to me. But this was not for commercial development. SQL, like XML Schema,
	is good enough, and it is widely available. It isn't really useful for me
	to wish that Quel had replaced SQL. Some day, RELAX-NG or some other
	beautiful schema language may supplant XML Schema. In the meantime, I doubt
	that commercial vendors will switch schema languages, because they have
	made large commitments to XML Schema. Most of us who do practical things
	with XML are likely to use XML Schema for at least some of our work. Let's
	make sure XML Schema is as useful as possible!
	I am not saying we should abandon RELAX-NG. I like it, and would like to
	see it gain market share. But I think that the XML industry as a whole is
	*going* to be using XML Schema in the near future. Let's make the best of it.
	The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
	initiative of OASIS <http://www.oasis-open.org>
	The list archives are at http://lists.xml.org/archives/xml-dev/
	To subscribe or unsubscribe from this list use the subscription
	manager: <http://lists.xml.org/ob/adm.pl>


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

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