Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
