RE: XQuery -- Reinventing the Wheel?

[Evan Lenz <elenz@xyzfind.com>]

Uche Ogbuji wrote:
> You refer, I assume, to the following, from XSLT 1.0:
>
> "When the source tree is created by parsing a well-formed XML document,
> the root node of the source tree will automatically satisfy the normal
> restrictions of having no text node children and exactly one element
> child. When the source tree is created in some other way, for example by
> using the DOM, the usual restrictions are relaxed for the source tree as
> for the result tree."

Yes, it is kind of funnily specified, but the needed information is in the
previous paragraph:

"The result [or source] tree may have any sequence of nodes as children that
would be possible for an element node. In particular, it may have text node
children, and any number of element node children."
http://www.w3.org/TR/xslt#root-node-children

Basically, by having the same restrictions for the source tree as for the
result tree, XSLT is able to attain true closure, where any output could, in
turn, be processed as input (as with SQL). (Note "input" and "output" refer
to abstract trees, not serializations.)

> I must say I think this is rather thin ice as it stands now.  I've always
> found this clause in the XSLT spec a bit baffling.  Since there is no
> normalized mapping from the DOM to the XPath  data model, the above can
> mean quite different things on different conforming processors.
>
> For instance, if implementor A gets a clever thought and allows processor
> A to accept a DOM document fragment of elements as a root node according
> to  the above, and implementor B decides instead that all text nodes and
> all  elements except for the first in a doc frag be ignored, both would be
> good citizens by the spec, but of course the processors could render quite
> different results.

When the XSLT spec is talking about the case of a well-formed XML document
being parsed to create a source tree, it is speaking as a matter of fact,
not normatively. I agree that it is a bit funnily specified, but this is the
accepted interpretation, as far as I know. In other words, XSLT doesn't care
where it gets a source tree from, and that source tree does not ever have to
model a well-formed XML document. It *may*, but it does not *have* to. Thus,
the only reason that both your examples would be okay from the standpoint of
the XSLT spec is that the XSLT spec does not specify *any* requirements on
how a source tree should be created. Such matters are orthogonal to the
concern of the XSLT spec.

> Not a problem as far as XSLT qua XSLT.  But once you rely on this property
> for standardized  treatment of a grove (term loosely used), which is what
> it seems your XSLT-base dproposal would do, I think you'd need to have
> strict prescription of the mapping  from multiple documents to XSLT source
> for this not to be problematic.  Maybe you already do so in your paper,
> which would, I think, cover my concerns.

I agree that how a collection of documents should be modeled as a single
source tree needs to be defined (and I do touch on this briefly in my
paper). However, I do not believe that the consideration of XSLT's viability
as a query language requires that there first be a standardized way to
create source trees. Given what I've read, this is an area where the XML
Query Working Group and I would generally agree. The specification of the
XML Query Data Model does not require that there first be a standardized way
of creating an instance of that model. This is strikingly clear in the
XQuery spec, when considering how little attention is given to what is meant
by "an implicit root node, determined by the environment in which the query
is executed."

Also, on the www-ql@w3.org list, I think Jonathan Robie made this point
fairly clear:

> -----Original Message-----
> From: www-ql-request@w3.org [mailto:www-ql-request@w3.org]On Behalf Of
> Jonathan Robie
> Sent: Tuesday, February 20, 2001 7:12 AM
> To: Jim Davis; www-ql@w3.org
> Subject: Re: First public Working Draft of W3C XML Query Language
>
>
> At 11:36 AM 2/19/2001 -0800, Jim Davis wrote:
>
> >I have not yet had time to read the new QL document, but it seems to me
> >that this functionality might be better addressed by the DASL protocol,
> >which is an IETF effort to define a query transport layer that
> can support
> >any type of query.  The DASL protocol deliberately did not propose a
> >solution for XML queries, on the hope and assumption that XML QL, when
> >defined, would be compatible.  But DASL does define means for specifying
> >the scope of document collections over which the query is to apply.
> >
> >Perhaps it's time to see how well XML QL fits with DASL?
> >
> >You can read about DASL at http://www.webdav.org/dasl/
>
> Hi Jim,
>
> It's been a while - I remember corresponding with you back in the
> XQL days.
> I *think* that XQuery should handle this requirement for you. You
> can write
> a query, then apply it to a collection of documents, and the collection
> does not need to be stated anywhere in the query. So if the protocol sets
> up an environment in which a query should be executed, it should work.
>
> I may be missing out on some of the details, though.
>
> CAVEAT EMPTOR
>
> Read the spec carefully, and let us know any problems you find.
>
> Jonathan
>

So....

Certain issues would need to be resolved, things like how the documents
should be ordered. This is also an issue for XQuery's model of a collection
as an "ordered forest".

Perhaps a more difficult issue for XSLT is how IDREFs are dereferenced when
dealing with documents that, when logically concatenated into one tree, are
no longer valid (because of non-unique IDs). XSLT is able to model invalid
trees, but its default behavior for non-unique IDs is probably not what
would be expected of a query language. Of course, when accessing the root
nodes of individual documents (a *different* root node than the source tree,
or in XQuery speak, the "implicit root node"), ID dereferencing would be
pretty straightforward as usual.

I would be interested in exploring with the community the possible issues
with regard to XSLT's use as a query language, but we should probably move
that discussion to the XSL-List.

Evan Lenz
XYZFind Corp.