XQuery1.0/XPath 2.0 needs your help!
As I mentioned earlier, XQuery 1.0/XPath 2.0 has still one last call issue that that can benefit from user input. Basically, the question is, whether the so called value comparisons (that use the Fortran style syntax eq, lt, ge etc) should behave the same when encountering untyped values as the general comparisons (the XPath 1.0 aligned =, <, >= etc. that provide implicit existential quantification) or whether they should treat the untyped values always as strings.
The general comparisons will cast the untyped values to (basically) the type of the other value that it is compared against (or strings if both are untyped). Thus, the expression //person[@age < 42] will return all person elements where the age is less than 42 (it will actually compare the values as xs:double values for XPath 1.0 compatibility reasons).
The value comparisons according to the current spec will cast the untyped values to string regardless of the type of the other value. Thus, the expression //person[@age lt 42] will raise a type error and will not return the equivalent result.
We filed a last call comment on this and would like to see this changed and aligned with the general comparisons, since we feel that the difference is subtle and counter-intuitive (it violates the principle of "least astonishment"). There is some opposition in the working group on getting this changed however. Some people fear that the semantics of order by, that depends on the semantics of lt, will suffer. This can actually be solved by saying that order by will always treat untyped values as strings. While this is slightly inconsistent with the value comparison behaviour, it is inline with the rules of for example the max() and min() aggregators that treat the untyped values always as double values.
Basically, the semantics of XQuery/XPath would provide a simple, non-promoting value comparison primitive (that is not exposed directly in the language) that then gets used to implement the value comparisons, order by, several aggregators, etc that all have their own promotion and casting rules. In turn, the value comparisons then get used to define the general comparisons. I don't think that this is problematic and I expect that such a change will make the language much more consistent with user expectations.
However, in order to be sure, we (I and the working group) need your help!
If you have an opinion on this topic, please reply to this posting or send your preference to the public comment mailing list as soon as possible (before July 19th would be appreciated!).