Michael Rys raises an objection to the “Microsoft -Oops we did it again and broke some standards” note below. Michael comments:
“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 means that we prioritize them…. I would recommend that you first check your facts before claiming some evil intent behind our decisions.” (see below for full comment).
We consider this an important comment and topic so we have promoted it to a full posting. First, let me say that Michael is a prolific writer on XML in general and XQuery in particular – he has books and several presentations under his belt. So both Michael and I know that he is correct – XPath 2 is at the the third working draft stage, XSLT 2 is at the 7th working draft, and XQuery 1 is at its 3rd working draft – none are fully recommended standards but judging by the time and number of working drafts, they are closing in on final draft calls.
Both Michael and I also know that XPath 1 and XSLT 1 are used extensively within Microsoft products. Both XSLT 1, and XPath 1 are used behind the scenes in InfoPath 2003 and BizTalk 2004. As well both XMLs are exposed to direct developer use in BizTalk 2004, C#, ASP.NET, VB.NET and many other Visual Studio programs. In addition, there are literally hundreds of other programs that utilize both XPath and XSLT from other software vendors and within organizations.
Also Michael knows that although XQuery has more functionality than XPath 2 it is not a true superset of Xpath 2. There are notable differences (see Univ of Freiburg and the W3C for details). On the XSLT versus XQuery comparison there are several articles with the following XMLHack providing a good starting point. The critical point here is that XQuery is not a one for one replacement of neither XPath 1 or 2 nor XSLT 1 or 2.
Now if Microsoft were a corporate good citizen and did things like implement “a stick to standards” toggle in all its development and programs that emit/generate code for developers (think Visual Studio, Front Page, BizTalk, Word, etc), then I would have much less concern for “Microsoft intentions”. And “a stick to standards” is not hard to implement, Adobe has done so for GoLive. Ditto for Macromedia and Dreamweaver. A “stick to standards” toggle allows a user to insist that all W3C and other standards be observed – no proprietary extensions allowed. In Adobe and Macromedias programs, non-standard functions either disappear from the menus or become grayed out.
Now the Lord (and Bloomberg Financials) know that Microsoft has enough cash ($56 billion and counting) to easily implement such a “stick to standards” capability across all Microsoft products. And CEO Steve Ballmer has pledged and re-iterated over the past 5 years that the company will act more responsibly as befits the leading software developer in revenues worldwide. And for the past 10 years interoperability and elimination of islands of information have been in the top 3 list of CEOs priorities according to Gartner and Information Week. So the question is why not?
The reasons for why to distrust Microsoft intentionsare simple. Everytime I edit or extend a web page (a sizable chunk of my consulting business) I spend about 20-40% more time making the JavaScript and CSS and DOM coding compatible so it runs across all browsers. (See Cliff Woottons JavaScript Reference pages 90 and 192 for just some of the tables of incompatibilities one has to wade through.) IE is now the browser which is by far the most off standard and offers the most proprietary extensions that coders often unknowingly include in their web pages. And since Microsoft has stated since May of last year that they will not update IE until Longhorn in 2006/2007 I know the incompatibilities will persist unchanged until at least then.
Take Java for another example. Microsoft has polluted the Java runtime environment for the past 5 years by issuing a woefully obsolete version of the JVM. All perfectly legal. And with the new reconciliation with Sun, this obsolete JVM gets to be delivered by Microsoft until 2007. If .NET and its CLR are so good – why does it need this protective crippling crutch against Java on Windows?
And in general, Windows and Microsoft development tools are the least supportive of dejure and defacto standards. Check out Microsofts direct support across its development and app tools for Adobe PDF, Apple QuickTime, CORBA, Flash SWF, JDBC, JPEG2000, OpenGL, Real Networks RM, etc, etc. Now compare the support for these same standards in 3rd party development tools and apps.
In short I dont trust Microsofts intentions on standards because I have seen well-intentioned Microsoft employees promise time and again – “we will support the standards” or “when numbers warrant we will implement the complete API” , only to have their senior management set the record straight with restrictive practices and “cutting off the oxygen” moves.
The classic example is in the web browser space where MS product manager after product manager said “look at us, we can support the DOM, CSS, HTML, or ECMAScript standards right now”. What actually happened was a quiet short-change here and massive proprietary overstep there. And then a whole slew of FrontPage, Office, and other applications generating the proprietary, non-standard code with no switch/toggle provided so users could generate standards code if they chose(yes- I want the choice even if it means the alternate is no “coding help at all”. I want to know what the trade-offs are for generating proprietary, it-only-runs-in-Windows code).
So having seen this “standards play”, not once but many times with Web standards, OpenGL, multimedia, and BI standards to name just a few – you can imagine the alarm bells that went off when it became evident that XSLT 2 and XPath 2 standards were to be bypassed by Microsoft.
Michael , you and I know that XQuery is not a perfect superset of neither XSLT 1 or 2 nor Xpath1 or 2. Both XSLT and XPath have unique features and coding practices that either require special programming in XQuery or simply cannot be duplicated. But even if they could be duplicated this means that thousands of Microsoft and 3rd party developers may have to recode their XPath and/or XSLT work in yet another language when Microsoft XQuery-only appears. Fine for you as you have written a book on it – but I have ActionScript2, JSF, SOA and SOAP 1.1 already on my plate and as a reviewer I am giving top marks to tools like Macromedia Flex or Cape Clear Suite that use existing dialects, code and standards over short cutting/swapping out existing coding tools and practices.
In sum, if Microsft did not have a huge legal case load on its plate and had acted like a Mensch, a true win-win player(the last time win-win was used in a Microsft Press briefing was 1996 – check it out, do a search of the MS Press Releases) rather than zero-sum leader of the software marketplace; if Microsoft had not engaged in standards shenanigans so many times in the past; if Microsoft had a “stick with standards” switch/toggle built into its software as rigid and ironclad as its EULA agreements – then I might be inclined to agree with you and not mistrust the 1 Microsft Ways intentions. In any case, I promise to Keep an Open Eye.