Today Arpan (the PM for XML query technologies in the .NET Framework) and I were talking about features we'd like to see on our 'nice to have' list for the Orcas release of the .NET Framework. One of the things we thought would be really nice to see in the System.Xml namespace was XPath 2.0. Then Derek being the universal pessimist pointed out that we already have APIs that support XPath 1.0 that only take a string as an argument (e.g. XmlNode.SelectNodes) so we'd have difficulty adding support for another version of XPath without contorting the API.

Not to be dissuaded I pointed out that XPath 2.0 has a backwards compatibility mode which makes it compatible with XPath 1.0. Thus we wouldn't have to change our Select methods or introduce new methods for XPath 2.0 support since all queries that used to work in the past against our Select methods would still work if we upgraded our XPath implemention to version 2.0. This is where Arpan hit me with the one-two punch. He introduced me to a section of the XPath 2.0 spec called Incompatibilities when Compatibility Mode is true which reads

The list below contains all known areas, within the scope of this specification, where an XPath 2.0 processor running with compatibility mode set to true will produce different results from an XPath 1.0 processor evaluating the same expression, assuming that the expression was valid in XPath 1.0, and that the nodes in the source document have no type annotations other than xdt:untypedAny and xdt:untypedAtomic.

I was stunned by what I read and I am still stunned now. The W3C created XPath 2.0 which is currently backwards incompatible with XPath 1.0 and added a compatibility mode option to make it backwards compatible with XPath 1.0 but it actually still isn't backwards compatible even when in this mode?  This seems completely illogical to me. What is the point of having a backwards compatibility mode if it isn't backwards compatible? Well, I guess now I know if we do decide to ship XPath 2.0 in the future we can't just add support for it transparently to our existing classes without causing some API churn. Unfortunate.

Caveat: The fact that a technology is mentioned as being on our 'nice to have' list or is suggested in a comment to this post is not an indication that it will be implemented in future versions of the .NET Framework.


 

Wednesday, 21 July 2004 11:33:47 (GMT Daylight Time, UTC+01:00)
They screw up everything nowadays! Incompatible backwards compatible mode - so ridiculous, but sad :(
Wednesday, 21 July 2004 13:38:59 (GMT Daylight Time, UTC+01:00)
XPath 2.0 isn't set in stone yet. So, did you take your own advice from http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=e9527310-11d7-49a3-ad95-15cd1581532e [duck] and file a "bug report" with the XQuery/XSLT people, raise hell with your representatives on those WGs, lobby your AC representative to agree to vote against the thing if it isn't fixed?

Not that I really expect them to fix it; after all it was about 3 years ago that you first made your mark in the XML world by reading them the riot act about the lack of insert/delete/update support in XQuery. The response was something like "if we did that, it would delay the Recommendation until 2003" :-)

Mike Champion
Wednesday, 21 July 2004 13:41:40 (GMT Daylight Time, UTC+01:00)
XPath 2.0 isn't set in stone yet. So, did you take your own advice from http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=e9527310-11d7-49a3-ad95-15cd1581532e [duck] and file a "bug report" with the XQuery/XSLT people, raise hell with your representatives on those WGs, lobby your AC representative to agree to vote against the thing if it isn't fixed?

Not that I really expect them to fix it; after all it was about 3 years ago that you first made your mark in the XML world by reading them the riot act about the lack of insert/delete/update support in XQuery. The response was something like "if we did that, it would delay the Recommendation until 2003" :-)

Mike Champion
Comments are closed.