March 09, 2005

via XSL-List | Follow-up response from Michael Champion from previous "Is there a reason for not using XSLT 2.0 as a default" post

NOTE: It seems that my statement that the split of the XSL working draft into the separate XSLT/FO working drafts back in the late 90's having something to do with Microsoft's current stance on support for the XSLT 2.0 working draft was completey off-base. In other words I muffed that one... 8| My apologies for a complete and total mis-cue on that one!

But no worries :) As it turns out Michael Champion recently posted a follow-up response that clarifys my previous muff and brings an official MS stance properly into place. To ensure that I have something to point to in any future comments on the matter I've copied his response below:

via XSL-List, follow-up comments from Michael Champion:
---
"M. David Peterson" wrote:
Date: Tue, 8 Mar 2005 17:32:48 -0700

"In fact one of the primary reasons Microsoft has held back from
providing direct support for the XSLT 2.0 spec is based on the last
second 'split' of the 1.0 spec into the XSL (FO) and XSLT
specifications causing an incompatible processor to be propogated and
a support nightmare to be invoked. "

I was not at Microsoft nor involved with the XSLT WG in 1998-1999, but
my understanding is similar to those who replied that the XSL-FO /
XSLT split had nothing to do with MS shipping an XSLT implementation
that was incompatible with the eventual Recommendation. There were
some interesting points raised in the replies, and I really have no
opinion about their historical accuracy or fairness.

I can only speak to the *current* perception in the WebData XML team
at MS about the lessons we as a company and an industry learned from
this experience. The sense I get from my colleagues who were around is
that it *was* a good faith effort to implement what they understood to
be the draft spec, along with various improvements to make it suitable
to known customer needs. I will say that my personal view at the
time was that Microsoft's support for XSLT, flawed and premature
though it clearly was in hindsight, was an attempt to do the Right
Thing. Furthermore, it had the result of offering considerable
credibility to XSLT and creating a demand for XSLT tools and
experience.. I can very easily imagine a world in which XSLT shared
the fate of XLink, if MS had waited for the final spec and for
customer demand to emerge before supporting it in its core products.

The MS position going forward is, as I understand it from my rather
brief experience, NEVER AGAIN -- we will not ship support of a draft
Recommendation in actual products. That is why we removed the preview
implementation of XQuery from the .NET 2.0 framework, that is why we
are waiting until XSLT 2.0 is actually a Recommendation before
announcing any implementation plans or schedule. (XQuery in SQL
Server is a bit of a special case ... in any event we're not claiming
to ship a conformant implementation, just something that leverages the
years of experience that have gone into XQuery and meets pressing
customer needs).