RE: [xml-dev] Who can implement W3C XML Schema ?

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:
 
          http://www.w3.org/TR/xmlschema-formal/
 
 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.
 
 Jonathan
 
 
 -----------------------------------------------------------------
 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>

Received on Thursday, 21 March 2002 10:29:09 UTC