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!).
While I have been a bit quiet over the last couple of weeks mainly due to presenting at two TechEd's, attending SIGMOD and still having to do my day jobs, we had quite an explosion of weblogs of the SQL Server XML and XQuery team members. Besides Shankar Pal and Mike Rorke, we now also have the following members of the test team providing useful postings:
- Galex's Semi-Structured Blog: Galex Yen is one of our testers and has written one post so far on simple types.
- John Gallardo's Weblog: John is another one of our testers and has been posted several articles on XQuery related issues.
- Typed XML in SQL Server 2005: Denis Ruckebusch is - you guessed it - another one of our testers who has extensively written already about typed XML (XML validation, XQuery over typed data, static typing).
Shankar has an important weblog entry on how to upgrade XML indices from previous CTPs to the June CTP.
Mike provides among others a posting on how to run an XSLT transform where both the XML and the XSLT is provided as an XML datatype parameter (see also my code sample for my April weblog that shows similar code :-)) and some insight into how namespaces are being resolved in XQuery.
Finally (for this posting), we have also published updates to most of our whitepapers on MSDN, including
and have a new whitepaper on our XQuery support. Feel free to send me your feedback on the whitepapers!
I have also updated my link collections with the new team weblogs and whitepaper. Now if only I could get community server to provide for a resyndication feature. That way I could easily setup a team weblog that resyndicates all the XML/XQuery team weblogs in one place while providing the whitepaper and presentation links...