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

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php