- From: TAN Kuan Hui <kuanhui@xemantics.com>
- Date: Thu, 28 Apr 2005 09:22:33 +0800
- To: "'Charles Brooking'" <charles.brooking@research.canon.com.au>, <www-ql@w3.org>
> > Consider the path expression $a/$b. > > If $a is a singleton, then the expression is equivalent to $b. > This is not true because it is dependent on the items contained in $b which is subjected to path interpretation. Say, if $b contained a list of QName items, then it has to be evaluated against $a and not some blind looping. I totally disagree with the above generalization which is dangerously misleading. > > > > However, if $a is not a singleton, then a query such as > > > > let > > $a := (<a1/>, <a2/>, <a3/>), > > $b := (1, 2, 3) > > return > > $a/$b > > > > will return > > > > (1, 2, 3, 1, 2, 3, 1, 2, 3) This side-effect is really disturbing; a path operator is now treated blindly as an iterator in the presence of a sequence in the follow-on expression without regard for the context in which it is evaluated. This can be confusing to preach and can potentially make XQuery painful to debug. I suggest that the atomic values returning from the last step must be a result of evaluating against the preceding step. Wherein the above example, there should be an attempt to convert each item into a QName to evaluate against the previous resulting sequence; failing which we should throw an error instead. This will keep the semantics of the path expression intact. In your example, the numerics 1,2,3 cannot be converted to QNames and therefore should throw an error. I can appreciate your example if it is, $a/fxn123() > > > > let > > $a := (<a1/>, <a2/>, <a3/>), > > $b := (<b1/>, <b2/>, <b3/>) > > return > > $a/$b > > > > return > > > > (<b1/>, <b2/>, <b3/>, <b1/>, <b2/>, <b3/>, <b1/>, <b2/>, <b3/>) > > > > because the expression bound to $b constructs unique elements > > each time it is evaluated? > > Yes. > > > Or should (<b1/>, <b2/>, <b3/>) be returned? I appreciate the subtlety of the significance of node identity being highlighted. However, to preserve the semantics of path expressions, can I also suggest that there is an attempt to convert every item in $b into QNames for evaluation. We can throw an error or warn if the conversion fails or quietly convert the item into () for evaluation but not making the path operator "/" into a blind iterator. If an iteration construct is required, please advocate alternative syntax so as to keep the xpath semantics consistent.
Received on Thursday, 28 April 2005 01:22:42 UTC