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? For example "It is possible to define collations that do not have the ability to decompose a string into units suitable for substring matching. An argument to a function defined in this section may be a URI that identifies a collation that is able to compare two strings, but that does not have the capability to split the string into collation units. Such a collation may cause the function to fail, or to give unexpected results or it may be rejected as an unsuitable argument. The ability to decompose strings into collation units is an ·implementation-defined· property of the collation." http://www.w3.org/TR/xquery-operators/#substring.functions That the drivers for this was to help translating implementations (e.g. to SQL) is something I thought I read in informal XQuery material, but I don't have a reference to hand, sorry! So instead of "if" please substitute "presumably if": a strong "if" was not the point I am making. In the formal semantics it says "A language aspect described in this specification as implementation-defined or implementation dependent may be further constrained by the specifications of a host language in which XPath or XQuery is embedded." http://www.w3.org/TR/2007/REC-xquery-semantics-20070123/#id-normativity An example of such material is how functions that are based on types being available should treat nodes with no schema: http://www.w3.org/TR/2007/REC-xquery-semantics-20070123/#jd_aux_derives_from Implementation-dependent material is listed at http://www.w3.org/TR/2007/REC-xquery-20070123/#id-impl-defined-items http://www.w3.org/TR/xpath-datamodel/#impl-summary http://www.w3.org/TR/xquery-operators/#impl-def >> 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. We had two programmers leave when we had them working on XML Schemas internals. We have never had that happening on any other technology! One left for Microsoft in the US, the other is now doing his Ph.D. > My implementation is under 20K lines of code. And the current Xerces source distro is 1.6Meg compressed. > 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. Without being argumentative or defensive, doesn't this statement contradict the earlier one? The market will be cool about XQuery variances, but will make its feelings known about XSD? It is about 8 years since XSD was released, after all. Is the "market" for XSD XSLT-like (needing completeness) or XQuery-like (tolerating variation, if it does). (I don't think conformance is the issue for XSLT as completeness is, by the way.) Cheers Rick Jelliffe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
