- 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>
> $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 http://www.saxonica.com/
Received on Sunday, 1 May 2005 13:11:19 UTC