This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi all, The following XPath (2.0) expression would raise an error, because the 2nd step in the expression, returns an atomic value: [1] product/substring(name,1,30)/replace(.,' ','-') This happens because, the XPath 2.0 language (and also the XPath 2.1 draft I believe -- which I'm not sure; please correct me if I am wrong) only allows the last step of an XPath expression, to return atomic values. I think, it would be nice to allow a XPath syntax something like below: product/substring(name,1,30)/replace($value,' ','-') The implicit variable reference, $value would only work if the previous XPath step is a sequence of atomic values (0-n in no's). Each call to replace function, would get an atomic value (the first argument) from the previous step. If the XPath step doesn't return an atomic value (which means, it returns node(s)), then $value will be empty sequence. This enhancement to XPath syntax would easy writing of some of complex XPath expressions. For e.g, the expression [1] (which is currently, disallowed) above currently might be accomplised like following: product/(for $n in name return replace(substring($n,1,30),' ','-')) Regards, Mukul
There's a long history to this one. There were many attempts during the development of XPath 2.0 to persuade the WG of the need for a "simple mapping operator" that would allow any expression on the left and any expression on the right. Some advocated using "/" as this operator, but there were two objections: it would mean that 1/2 evaluates to 2; and it wouldn't work for nodes, because the current path operator is not a simple mapping, because it eliminates duplicates and sorts into document order. So others advocated a different operator; but none was found that everyone liked (and some people didn't see the need anyway). Then at a very late stage of development an IBM reviewer proposed overloading "/" to allow the rhs to select atomic values, and this was accepted. Allowing the lhs to select atomic values as well is in some ways a logical development. It still leaves the problem of (1/2), and it also leaves the problem of deciding under exactly what circumstances the sorting and deduplication should occur. The case where the lhs selects atomic values and the rhs selects nodes is probably unusual, but it can't be ignored.
Hi Mike, Thanks for the answer. (In reply to comment #1) > It still leaves the problem of (1/2). Can't we treat this case, as returning an empty sequence (i.e, if both lhs & rhs of "/" are atomic values)? btw, I'm now slightly inclined to think, that the current design (i.e, allowing only last step of XPath expression, to have atomic values) is probably correct. An XPath (2.x) expression essentially has to select nodes from an input XML document (it may though return atomic values, from 2.x onwards). Allowing something like, /atomic_value(s)/node(s) (or, /atomic_value(s)/atomic_value(s)) is like enhancing mathematical capability of the language, and not adhering to the design principles of XPath (which is, essentially to select nodes from input document. Or more correctly, a sequence of XDM item values, in XPath 2.x). I'm now inclined to take my comment back. Regards, Mukul
Thanks - I'm marking this as WONTFIX, as per your comment #2. Please confirm that this is OK.
(In reply to comment #3) > Thanks - I'm marking this as WONTFIX, as per your comment #2. Please confirm > that this is OK. I agree with the resolution. Thanks for looking at this. Regards, Mukul