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