RE: top-level location-path context dependencies

Context items are part of XPath which is shared by XSLT and XQuery, thus
there is a huge alignment and backwards-compatibility concern.

If XQuery could do what it wanted without paying attention to XPath,
there may not even be a notion of an implicit context item...

In XQuery, the solution is very simple if you make it explicit:

Bind a variable to the sequence.

And note that there are many scenarios that do not have this issue, so I
doubt that all implementations will need to support implicit querying
over a context sequence.

Best regards
Michael

> -----Original Message-----
> From: Jason Hunter [mailto:[email protected]]
> Sent: Sunday, April 18, 2004 10:37 AM
> To: Michael Rys
> Cc: Howard Katz; Michael Kay; [email protected]
> Subject: Re: top-level location-path context dependencies
> 
> Michael Rys wrote:
> 
> > This would not be backwards-compatible and have some interesting
> 
> This is the first time I've heard of backwards compatibility being a
> major concern in a pre-1.0 release!
> 
> 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.
> 
> The ability to set a context sequence (not just a node) is a benefit
to
> XQuery programmers.  It should be allowed.
> 
> > side-effects. The easiest way is that you define your input document
to
> > be always a document node which can contain more than one element
node.
> > Then //foo would give you exactly what you would expect (if you
start on
> > an element node, the result probably would not be what you expect if
you
> > have a foo element on the top).
> 
> I (or my vendor) should be able to define it as makes sense in
my/their
> context.  Sometimes (rarely) a single node suffices.  More often a
> sequence is what you need.  If you want to find all foo elements in
all
> the documents available to your environment, it sure be quite nice if
> there was a standard way.  It's such a common need that vendors are
all
> going to provide it.  It's just a question of whether they'll be able
to
> do it within the spec or by deviating.
> 
> It's an arbitrary limitation that goes against a common need.
> 
> > Also, you can set the context node to any node you want, as long as
it
> > makes overall sense.
> 
> "You can have any node so long as it's one."
> 
> -jh-