Re: top-level location-path context dependencies

Michael Kay wrote:

>>Yes, I understand you're talking about XSLT 2.0, but I don't see why 
>>XQuery 1.0 needs to be backwards compatible with XSLT 1.0 or why the 
>>limitations that may need to be placed on XSLT 2.0 need to apply to 
>>XQuery 1.0 across the board.
> I think that if "." or "/" always returned a single item in XSLT and XPath,
> but could return multiple items in XQuery, the user community would be
> entitled to complain loudly. We have always had the view that where XQuery
> uses XPath syntax, it gives it the same semantics. This is not an issue of
> backwards compatibility, it's an issue of cross-language compatibility.
> Michael Kay

XPath was designed (it appears to me) as a language for querying within 
a document.  XQuery is being designed (it appears to me) as a language 
for querying across any number of documents.  Thus I think the default 
context, while appropriately singular in an XPath view of the world, can 
naturally be extended to a sequence in the XQuery view of the world.

Michael Kay wrote:
 > Replacing the concept of "context item" by one of "context sequence"
 > (or "default set of documents") would create mayhem:

I say it would create a situation where some thought was required to 
determine the appropriate behaviors in some edge cases.  Every change 
implies that.  It's far from "mayhem".  Below are my thoughts on the 
edge cases you bring up.

 > what would context position
 > and context size then be, for example?

The dynamic context position and size are needed because we're assuming 
a somewhat odd thing: that the default context item of an XQuery is 
being simulated as one node in a larger sequence -- even though the 
query can't see the larger sequence!  I see that as a hack:  "Here's 
item 3 of 5, but in the entire universe of your query you can't see the 
other 4."  If the default context can be a sequence, then you don't need 
those artificial contextual supports.  You just have a sequence.  The 
proposed change simplifies the specification.

 > Would "." also return a sequence?

I think relative paths like "." and "foo" in the outermost context don't 
make much sense in an XQuery environment.  I don't think "." should ever 
return a sequence.

 > Would id() search multiple documents, perhaps finding multiple
 > elements with the same ID?

I think that id() should be used within a context of a single document 
and if that's not the case it's an error.  The method's a leftover from 
a single-document view of the world.

 > What would the query name(/*) do?

Well, /* returns all the child elements of all the items in the dynamic 
context sequence, and name() returns their names.

The short answer to all your questions is that with absolute paths you 
assume input() before the leading slash, with input() as a standard 
input sequence assigned externally to the XQuery code.

 > If //x were able to return nodes from multiple documents when used at the
 > top level of a query, then presumably you would also want it to be 
able to
 > do the same when used at other levels (for composability). What new 
 > construct would you want to introduce for setting the context sequence?

I don't really follow you there.  //x behaves the same as input()//x 
would in the May draft.  If you want all x elements that are descendants 
to the current node, you use .//x.

 > I agree that it's a pity (from the XQuery point of view) that input() has
 > gone. It never made much sense in XPath or XSLT, but I don't see any 
 > why there shouldn't be XQuery-only functions just as there are XSLT-only
 > functions.

Perhaps that's where we compromise.  You don't *need* an implied input() 
so long as you can have an explicit input().  But not having either? 
That's unworkable.


Received on Monday, 19 April 2004 17:34:24 UTC