[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
>As for XQuery being able to support other XML schema languages in future, this is nice but I'm curious as to what exactly this means in practical terms.
>
It seems the XQuery does not use (declarations for)
- facets
- key/keyref
- nillable
- details of user-defined derivation hierarchies (i.e., it is
interested in supertypes or
subtypes only as an unordered list, not as an ordered list or
anything: like substitution groups,
only the name is important)
and creates its own type hierarchy for lists and unions which is
different from WXS.
(An improvement, I presume it could be folded into WXS.)
Given all that, XQuery looks pretty good in this department. I could
easily imagine
(unambiguous) RELAX NG (with WXS datatypes and a minimal PSVI interface)
fitting in.
It might be pretty difficult to have an XQuery implementation that
supports pluggable schema
languages, of course; and the constant revalidation probably rules out a
schema language that
may want to access the whole document (Schematron, WXS key/integrity
constraints, etc.)
The main problem I see for XQuery is that XQueryX completely sucks. For
those who have
missed it, XQuery defines a nice whitespace-tokenized language, but it
also has another syntax
that looks like XML but is not XML: different namespace rules, <![CDATA[
is a function that
returns a CDATA section, <!-- a comment is a function returning a
comment-->, no encoding
considerations. A completely retrograde step, from what I can make out,
and one I hope that
needlessly clouds what otherwise is looking pretty good now. XQueryX
could be trimmed
without loss of power: scraps to the dogs under the table.
>The working group already has seen the problems caused when one group builds a "type system" (and I use the term loosely) which they believe can work for some future language only for their assumptions to come out wrong. I originally was of the mind that this was a laudable goal of XQuery and still think it is a laudable goal to have it in the data model but wonder how feasible it is to actually create an XQuery implementation with what is basically a "pluggable" type system. A validation language with pluggable datatypes (which are basically custom checking on string values) like RELAX-NG has is fairly straightforward enough but a creating a pluggable type system where you have to deal with issues like type promotion & type substitutability is a bit harder.
>
Sure, but the only (public) full-featured alternative datatype system so
far is J. Tennison's, which ultimately relies on WXS: it performs
translations. So the choices need not be between WXS and
non-WXS, but WXS and a more extensible form of WXS with which you can
define your own
types. Jenni's datatyping system really fits at the same level as
derivation-by-list and
derivation-by-union: type promotion and substitutability of primitives
occurs based on primitive
types' properties and facets, which Jenni's datatypes fit on top of.
Cheers
Rick
|