Partager via

When Backwards Compatibility Mode Isn't

  • Article

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.

Comments

  • Anonymous
    August 03, 2004
    Hey Dare,

    We launched a solid beta of the Saxon.NET project last Tuesday which is up on the projects site (http://www.x2x2x.org/x2x2x/home), as well as GotDotNET and SF.net... nothing like choices when it comes to dowloading the same dang bits, eh? :) So if you want to start playing with XPath 2.0 (and XSLT 2.0 for that matter) on .NET without having to do much more than maybe create a wrapper class here and there to keep you from going insane from type incompatibilities (I'm actually developing the complete type wrapper project for the IKVM.NET project but its slow at present trying to get everything else in that we're working on as well... I'll ping the site again when I get it done.) then it's all there waiting for ya... :) We are about to begin the architecture design for the native C# and .netfx part of the project (termed Phase Two) and we would definitely love to have your influence if you have some extra time here and there...

    Enjoy!

    <M:D/>
    m.david@x2x2x.org
  • Anonymous
    June 09, 2009
    PingBack from http://insomniacuresite.info/story.php?id=8074