[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: FW: [ANN]: XQuery: A Guided Tour

• To: xml-dev@l...
• Subject: Re: FW: [ANN]: XQuery: A Guided Tour
• From: Rick Jelliffe <ricko@a...>
• Date: Wed, 01 Oct 2003 01:01:58 +1000
• In-reply-to: <830178CE7378FC40BC6F1DDADCFDD1D1173C52@R...>
• References: <830178CE7378FC40BC6F1DDADCFDD1D1173C52@R...>
• User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428

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 [expletive deleted].  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

• References:
  • RE: FW: [ANN]: XQuery: A Guided Tour
    • From: "Dare Obasanjo" <dareo@m...>

• Prev by Date: RE: Beyond Ontologies
• Next by Date: RE: FW: [ANN]: XQuery: A Guided Tour
• Previous by thread: RE: FW: [ANN]: XQuery: A Guided Tour
• Next by thread: RE: FW: [ANN]: XQuery: A Guided Tour
• Index(es):
  • Date
  • Thread