Re: XQuery Expression Context issues

A few comments on your comments from an XPath/XSLT perspective:

- A variable is a QName.  Does this really mean that variable names are
compared with namespace-uri and localname instead of textually?  This
seems like overkill to me.  But if so, do they have a default namespace?

This behavior is retained from XPath 1.0. It's not widely used, but it does
allow an XSLT stylesheet to import a stylesheet module such as math.xsl
which defines a global variable whose name is math:pi. I've suggested a
possible simplification that a variable declared locally within an XPath (or
XQuery) expression - i.e. not imported from the context - must be in the
default namespace.

- Is the focus passed through calls to user defined functions?  I
certainly hope not, because it makes separate compilation and
optimization of user defined functions much more difficult.

This is an interesting and contentious issue. The original thinking in the
XSL group was that user-defined functions should have the same access to
context information that system functions have. But having implemented this
in XSLT, I certainly understand how it can have a negative impact on
optimisation, so we might have to forgo this. We will need some form of
words that allows an XSLT implementor to continue to support extension
functions that worked under XSLT 1.0, though.

- In XPath 1.0, the context position and size are only set by '[]', not
by '/'.

Actually, you can't tell whether they are set or not, because there is no
way of testing context position or size on the rhs of "/" in XPath 1.0, as
the expressions you are allowed there can't include calls to position() and
last().

In XPath 2.0 it's still quite difficult to construct an expression that's
sensitive to this, but it can be done, e.g.

   chapter/sublist(section, 1, last())

which selects the first section of the first chapter, the first two sections
of the second chapter, the first three of the third, and so on. Although
this isn't very useful, I think it's important that the concepts of "context
node" and "context position" are always aligned.

- I would like to add my support to issue 217.  The definition of
context document makes it very difficult to know at query analysis time
to which document an absolute path expression refers.

This is a really difficult one. I entirely share your views about the
desirability of making absolute path expressions truly "absolute". It's a
question of how much we can afford to break XPath 1.0 compatibility.

- However, within XPath 1.0, there was no way to refer to another
document, so every occurrence of '/' as a root had to refer to the same
document.

This isn't true. Although most of the XPath spec is written as if there is
only one document, the semantics of unary "/" clearly say that it refers to
the root node of the document that contains the context node. When XPath 1.0
is used within XSLT 1.0, a node-set (supplied as a variable via the context)
may definitely include nodes from multiple documents, and although this is
explained in XSLT rather than XPath, there is nothing in XPath that says
otherwise.

Mike Kay

Received on Friday, 11 January 2002 02:15:35 UTC