- From: Michael Kay <mhk@mhk.me.uk>
- Date: Fri, 6 Feb 2004 18:48:19 -0000
- To: "'Sarah Wilkin'" <swilkin@apple.com>
- Cc: <public-qt-comments@w3.org>, "'Michael Rys'" <mrys@microsoft.com>
> Well no, it's not. Consider: > let $source := <foo> > <a><b/></a> > <a><b/></a> > </foo> > return $source/a/b/text{ position() } > which creates two "1" text nodes, as opposed to your example which > would create "1", "2". The expression: $source/a/b/text{ position() } parses as (($source/a)/b) / (text{position()}) The value of (($source/a)/b) is a node-sequence containing two nodes. The expression text{position()} is evaluated once for each node in this node-sequence, with the positions of these nodes being 1 and 2. So I think it creates two text nodes containing "1" and "2" respectively. I actually proposed recently that position() and last() on the rhs of "/" should always be one, because I did not think that there were any cases where the current definition was useful, and because it prevented "/" being associative. But the proposal didn't gain support from the WG. > > However, I feel like we're getting off track. The issue at > hand is not > whether there's some way of reproducing position(). Being able to > construct nodes within a path (whether directly or via a > function) is a > powerful feature. Assuming it remains, the issue is how to define the > order of the elements created. > Well, I would tend to argue the other way: it is not a powerful feature, because the order of the nodes is undefined, and I for one don't see any sensible way of defining the order. Michael Kay
Received on Friday, 6 February 2004 13:47:56 UTC