W3C home > Mailing lists > Public > www-ql@w3.org > April to June 2004

RE: top-level location-path context dependencies

From: Michael Rys <mrys@microsoft.com>
Date: Sun, 18 Apr 2004 11:03:24 -0700
Message-ID: <EB0A327048144442AFB15FCE18DC96C702A7D605@RED-MSG-31.redmond.corp.microsoft.com>
To: "Jason Hunter" <jhunter@acm.org>
Cc: "Howard Katz" <howardk@fatdog.com>, "Michael Kay" <mhk@mhk.me.uk>, <www-ql@w3.org>

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

> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@acm.org]
> Sent: Sunday, April 18, 2004 10:37 AM
> To: Michael Rys
> Cc: Howard Katz; Michael Kay; www-ql@w3.org
> 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
> XQuery programmers.  It should be allowed.
> > side-effects. The easiest way is that you define your input document
> > be always a document node which can contain more than one element
> > 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
> > have a foo element on the top).
> I (or my vendor) should be able to define it as makes sense in
> context.  Sometimes (rarely) a single node suffices.  More often a
> sequence is what you need.  If you want to find all foo elements in
> 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
> going to provide it.  It's just a question of whether they'll be able
> 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
> > makes overall sense.
> "You can have any node so long as it's one."
> -jh-
Received on Sunday, 18 April 2004 14:04:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:43 UTC