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

RE: Variable references in path expressions

From: Michael Kay <mhk@mhk.me.uk>
Date: Sat, 30 Apr 2005 23:46:09 +0100
To: "'TAN Kuan Hui'" <kuanhui@xemantics.com>, "'Michael Rys'" <mrys@microsoft.com>, "'martin'" <martin@x-hive.com>
Cc: "'Charles Brooking'" <charles.brooking@research.canon.com.au>, <www-ql@w3.org>
Message-ID: <E1DSEE7-0007EN-IM@bart.w3.org>

> $a/$b == $b if $a is a singleton does not make sense to me
> with the "/" operator. 

I think this is because you have failed to appreciate that "/" is a mapping
operator, the equivalent of the map() higher-order function in functional
programming languages. map() takes two arguments, a sequence and a function,
and it applies the function to each item in the sequence. Similarly "/"
computes the value of the expression on the right once for each item in the
sequence that results from evaluating the expression on the left. When you
think of "/" this way, there is nothing else that $a/$b could possibly mean.

The main purpose of generalizing the XPath 1.0 path expression, which only
allowed axis steps on the right of the "/", was to allow function calls and
union expressions. For example, you can write a path expression such as
$a//b/id(@code)/@ref, or $a/b/(c|d). Generalizing the construct to allow any
expression on the right is a reasonable thing to do, given that the
semantics are perfectly well-defined and align with a common feature of
functional programming languages. The fact that it allows some expressions
that aren't very useful (such as $a/$b) is immaterial - we allow you to
write $a+0 as well.

You need to distinguish between this syntactic generalization of XPath 1.0
path expressions, which introduced the ability to write $a/$b, and the
(subsequent) semantic generalization, which allowed the expression on the
right to yield atomic values instead of nodes. These two enhancements seem
to have been confused on this thread.

With a QName on the right, interpreting $a/xs:QName($b) to mean
$a/*[node-name()=xs:QName($b)] would make no sense at all in terms of "/" as
a mapping operator. Of course one could have overloaded the "/" operator
that way, but it would not have been a logical extension to the XPath 1.0
meaning, and it would only create a shorter way of writing something that
can already be written with a predicate.

Michael Kay
Received on Sunday, 1 May 2005 13:11:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:17 UTC