RE: [xml-dev] XML Schema: "Best used with the ______ tool"

["Michael Kay" <mike@saxonica.com>]

> 
> XQuery is interesting in that in several places it allows 
> implementations to fail (unless it has changed) if they 
> cannot for example figure out how to convert an XQuery into 
> their native query capabilities.

That's a surprising interpretation of the spec, I wonder where you get it
from?

The spec is fairly liberal about allowing optimizations, including rewrites
to code that has different behaviour in error cases - I wonder if that's
what you are referring to?

Far more of a problem is that in the database industry, there is not a
strong culture of standards conformance. People have come to regard it as
acceptable that each vendor's dialect of SQL contains "added value"
extensions, and this mindset is carrying through to the XQuery world. It's
not just a vendor attitude, it's also a user attitude - they don't expect or
demand conformance, so they don't get it. That's partly of course because
they would be locked in to the vendor anyway, because even if the query
language is interoperable, so many other aspects of the product aren't: the
database loading and tuning utilities, backup procedures, etc etc. 

I think you will probably find that there is a very good level of
interoperability between non-database implementations of XQuery.

> 
> So what is the reason? That XSD is just too damn big to be 
> implemented fully by many system, not on technical reasons 
> but for commercial reasons:
> the cost of the extra features are too much.

Implementing XSD is challenging, but it's certainly not prohibitively
expensive. My implementation is under 20K lines of code.

It's true that there are people who have chosen to implement subsets of it -
perhaps they feel their market only requires a subset. There were people who
only implemented subsets of XSLT, and the market soon made its feelings
felt.

Michael Kay
http://www.saxonica.com/