This is a conversation that Jeff Julian began and has since been followed up by Soumitra Sengupta on the Microsoft XML team and later by Oleg Tkachenko. The title of the piece doesn't give a clear understanding as to what the conversation is about so let me summarize:
Soumitra: snip... I am interested in your take on XQuery. Did we make the right or wrong call on this?
Jeff: snip... Yeah, I would say you made the wrong decision.
Soumitra: XQuery is not a W3C recommendation yet and will not be for at least a year (maybe more) snip...
I'll let you follow the link if your'e interested in following this "saga" in the making and potentially participating in it yourself. But some things have recently come to my attention that I had never even considered in regards to all of this so let me quickly follow with some comments on the matter.
In a recent conversation with someone close to this situation it has become suddenly and painfully obvious why Microsoft first cut XSLT 2.0 and has since cut XQuery (there is still a subset supported in Yukon, but the .NET client/server support is gone) from the release of .NET 2.0. Obviously this was a painful blow to the XSLT community when we first heard about it and I will be the first to admit that I experienced a bit of a sense of glea when I first discovered that XQuery would be cut as well [I don't hate XQuery I just love XSLT so its tough not to have those kinds of feelings when the "competition" gets cut right along with you]. But even when that happened the obvious still didn't occur to me. It wasn't until I read the following that it suddenly dawned on me why the support was cut:
"Clearly MS helped put XSLT on that map by supporting it in IE5, but that experience (or rather, the fact that a pre-Rec version was initially supported and that has to be maintained for a long time in the future) has made the idea of supporting XSLT 2 *before* a Recommendation a total non-starter here."
Obviously the same is true for XQuery. No W3C Rec, no MS support. Plain and simple. Now, I'm not suggesting that I happen to know any specifics as to whether this is an official policy for EVERYTHING at Microsoft. But I think its obvious for something as big as XSLT 2.0 and XQuery that the implications of long term support of a technology within a product require that MS has some sort of assurity that what they ship is going to be what is officially deemed a W3C recommendation. To be honest, now that my eyes have been opened to what should have been obvious I don't blame them one bit. If I was Microsoft I would be covering my A$$ too...
While its obvious there was nothing "revealing" in the above statement that shouldn't already be obvious it does do one thing for the little XSLT 2.0 candle burning inside of me: It does give me a bit of hope that when the final rec comes from the W3C that MS may decide to offer support in some future release of the CLI (.NET as it is known in today's marketing terms). My guess is (and this is just a guess, my connections to Microsoft are not THAT strong) that if we, as the XSLT community, can showcase the fact that adding support for XSLT 2.0 is something that adds value to their customer base then there is no reason why they wouldn't find reason to put the resources into bringing this support into the CLI fold at some point in the future.
Maybe with Saxon, Saxon-SA, and their Saxon.NET counterparts we will be able to prove just that... I guess maybe in some ways its up to us?
Something to think about...
TrackBack URL for this entry:
http://www.xsltblog.com/xslt-blog-mt/mt-tb.cgi/180
It is good to see that my take on the whole XSLT2/XQuery situation (made back in Oct.) was pretty accurate, although I made sure to take a swipe at the W3C (which the guys from MS couldn’t really do).
I should have paid more attention to you then Don… I can’t believe I am asking the East Coast Don for forgiveness (I feel like I’m in an episode of the Sopranos ;) but can I have it? :D
Cheers!
See Arpan Desai’s discussion of the timing issue as well.