Microsoft is becoming increasingly less interoperable as details on Longhorn emerge. Effectively right now there is really no programming interoperability except through SOAP and Web Services – all of Redmonds programming languages are highly proprietary. Its refusal to update IEs JavaScript/DOM/CSS to W3C standards embraced by all other browser vendors is nothing less than a direct slap to the face of all web developers. Now the latest on Microsofts support of XML standards is like a message out of Iraq – more bad news.
On data interoperability, Redmond had stuck pretty close to XML standards – although it has recently been patenting a number of its XML implementation technologies and has taken a rain check on important technologies such as XForms and RDF. But now Microsoft is backtracking on support of two key XML processing standards – XPath 2 and XSLT 2. (see bad news link above). As well Microsoft has reserved the right to step away from any new XML Schema or XML UI tag languages (XAML, XUL, etc). All of these technologies are used extensivly in Microsofts own Visual Studio, InfoPath, Biztalk and dozens of other apps and tools. Ditto for most ISVs and software toolmakers which use XPath and XSLT too.
So now even on the data interoperability side, Redmond is moving away from easy interoperability and adhering more closely to the IE-like, proprietary standards model. In a data processing world that is demanding ever more interoperability, reusability, and backward compatibility- Redmond is on an openly contrarian path that adds large and unneccessary development/interfacing time and penalties for both ISVs and developers alike. It begs the question – for a company that still has major availability, reliability, scalability, and security deficiencies as well as being one of the higher cost suppliers – how long can they hope to sell these “benefits ” to their heretofore loyal customers??
XSLT 2.0 is not yet a standard and neither is XPath 2.0 nor XQuery 1.0 for that matter. That we invest in XQuery 1.0 (which basically is a superset of XPath 2.0) at this time and not in XSLT 2.0 does not mean that we do not implement W3C recommendations. It just mean that we prioritize them. People that use the current XSLT 1.0 cannot even easily take advantage of XSLT 2.0 if we would implement it, since it uses a different namespace etc. I think providing improved XSLT 1.0 support instead of chasing the not yet completed XSLT 2.0 standard will be better for interoperability and developers (anyone remember the MS XSLT implementation based on a last call WD?).
I would recommend that you first check your facts before claiming some evil intend behind our decisions.
For those of you who were unaware a few of us got together after Mark Fussells original post regarding MS non-support for XSLT 2.0 in .NET 2.0 and began to port Saxon 8.0-b to the .NET 1.1 framework. We reached an early beta milestone on July 5th and if all goes well with a few bug fixes and a few more feature enhancements we will be releasing a general public beta release this coming Tuesday (July 20th).
Another capability that we have planned for sometime in the near future is the ability to do client-side transformations with the Saxon.NET engine. This capability does not exist right now but is viewed as an important aspect of the overall project development and as such is going to be given all the time and attention necessary to bring it into reality as soon as humanly possible.
The projects home page is http://www.x2x2x.org/x2x2x/home. We have both a SourceForge and GotDotNET project space but to be honest we havent spent much time utilizing either from the standpoint of forum communications, CVS accessibility to the source files, bug tracking, etc… This will change in the near future when we can move our focus away from writing the code to make everything work properly and more towards tracking down bugs and increasing the performance of transformations.
One other important point to bring forward… If not already obvious the port of Saxon to .NET was done to the .NET 1.1 platform. This means that the three supported elements of Saxon 8.0 (XSLT 2.0, XPath 2.0, XQuery 1.0) will be available on the .NET 1.1 platform as well as 2.0. Obviously MSs limited support for XPath 2.0 and full support for XQuery 1.0 is only available on .NET 2.0 (as far as I know at least). While in no way was this done to thwart people from upgrading to .NET 2.0 (remember, were all .NET developers as well and are excited about the release of .NET 2.0 and all that it brings with it) it does allow you to begin using all three technologies immediatelly, in a stable production environment.
Im back to writing code but I wanted to quickly update some of the blog entries that focused on MSs non-support for XSLT 2.0. Forgive me if you read this exact same post on several other blogs as well as our own project blog on the project site.