Chances are zero for XSLT2 in Orcas. Orcas is spec frozen now, and we can’t do a lot of work hoping that W3C will finalize the spec before we finalize the code. Also, Orcas is a tools release, so we can’t take anything other than critical bug fixes in the .NET 2.0 “red bits”. We are actively working on XSLT2 however, and there will be CTP releases starting in roughly the Orcas timeframe. It’s not clear how it will ultimately be released.
January 9th, 2007
Microsoft XML Team’s WebLog : XSLT 2.0
Our users have made it very clear that they want an XSLT 2.0 implementation once the Recommendation is complete. A team of XSLT experts is now in place to do this, the same people who have been working on the XSLT enhancements that will be shipped in the forthcoming “Orcas” release of Visual Studio / .NET 3.5. Orcas development work is winding down in advance of Beta releases over the next several months, so there is no possibility of shipping XSLT 2.0 in Orcas. The XSLT team will, however, be putting out Community Technology Previews (CTP) with the XSLT 2 functionality and appropriate tooling as the implementation matures. The eventual release date and ship vehicles (e.g. a future version of .NET or a standalone release over the Web) have not been determined, and depend on technical progress, customer demand, and other currently unknowable factors.
So Orcas Beta 2 released a few months back. Depending on your interpretation of various announcements, VS.NET 2008, which is quite stable already in Beta 2, will release somewhere between November and February. So that should mean we should expect an XSLT 2.0 CTP somewhere between now and March?
I must admit that I am getting quite excited by the anticipation of the first CTP release. Of course I can’t imagine MSFT would do something as silly as not deliver on something that the community fought as hard as we did to gain in the first place,
Our users have made it very clear that they want an XSLT 2.0 implementation once the Recommendation is complete.
… would they?
Not the MSFT XmlTeam I know and love**, that’s for sure!
A team of XSLT experts is now in place to do this, the same people who have been working on the XSLT enhancements that will be shipped in the forthcoming “Orcas” release of Visual Studio / .NET 3.5.
See!!! :D
** DISCLAIMER: The MSFT XmlTeam you know and [love|hate] might differ from the MSFT XmlTeam I know and, at present time, [HEART]. ;-)
Hey MSFT XmlTeam: How about a time frame update? Oh, and while we’re at it, will the XSLT 2.0 CTP source be a part of the forthcoming MS.NET Open Reference release? That would be *FANTASTIC*! :D
/me is waiting eagerly to hear when we all get to play with the first MS.NET XSLT 2.0 CTP release. :D
Oooh, this looks good. I too would like to see the XSLT 2.0 source as a part of the Open Reference release.
@Asbjørn,
>> I too would like to see the XSLT 2.0 source as a part of the Open Reference release.
That would *ROCK* for sure! Fingers crossed and breathe held. ;-)
>> breathe held.
And release. (fingers still crossed, however. Makes typing that much more fun ;-)
Are you being facetious? It is hard to tell in your blog posts.
It seems to me that Microsoft would rather re-invent than use standards: Infopath (xForms), Linq (xQuery), Web3S (AtomPub), xmlNavigator (xmlDom), and Xaml (Xul).
Is this a real enhancement or merely a business strategy of getting Developers, developers, developers to use THEIR products ? I am a HARDCORE .Net developer, but even I am not holding my breath on this one.
Why wait for Microsoft to 'get around to it'? I've been using AltovaXML 2007 for a few months now and it works.
@Ed,
> Why wait for Microsoft to 'get around to it'? I've been using AltovaXML 2007 for a few months now and it works.
Oh, I'm not waiting. 'Tis why I created the Saxon.NET project back in 2004, handed that project over to Dr. Michael Kay and Saxonica in 2006, and continue to build 99.100% of my web-based applications on top of this wonderful product (referring specifically to the ground-breaking work Dr. Kay has done w/ both Saxon in general as well as the Saxon on .NET API he added to the mix after taking over the project 20 months ago)
This post isn't about day-dreaming about someday having an XSLT 2.0 processor to play with. This post is about ensuring that MSFT follows through with its commitments.
@Ric,
>> Are you being facetious? It is hard to tell in your blog posts.
To the extent that I am attempting to take on a heavy subject matter w/o calling MSFT out on the carpet, yes. At this stage the status of their XSLT 2.0 implementation is unknown. If I were to state "You guys promised to deliver and haven't yet, you evil rotten double-standard bastards!" following the laws of the blogosphere by this time tomorrow this post will have gone from "where's the CTP?" to "MSFT steals candy from baby, and then eats the baby too!" or something to that effect.
>> It seems to me that Microsoft would rather re-invent than use standards: Infopath (xForms), Linq (xQuery), Web3S (AtomPub), xmlNavigator (xmlDom), and Xaml (Xul).
MSFT is profit, and therefore customer driven. If their customers say they want something, and are willing to put their money where their mouth is, MSFT is going to deliver what the customer asks for. The above mentioned technologies all have good reasons for existence. And while they might re-invent the wheel in one regard, that doesn't mean they don't/won't support the wheel as well. They're a big company, with *MANY* conflicting technologies. That's just the way it works.
In this particular case I think LINQ is *FANTASTIC*. And I can do a lot of XSLT 2.0-like work with the combination of XSLT 1.0 and EXSLT (supported via the MvpXml project), so in many respects I can understand why MSFT has been slow on their feet, *especially* when you consider the fact that we have XSLT 2.0 support via Saxon on .NET.
But what MSFT seems to have lost site of is that a native XSLT 2.0 implementation provides significant value to their customer base as it allows a seamless transition from .NET data-types and XSLTransformations due to the typed-data model presented in XPath 2.0.
For example, serializing a .NET object to XML and transforming that object into something else to then serialize that XML back into a .NET object is child's play with XPath 2.0/XSLT 2.0, validating the entire process as you go using the benefits of a Schema-Aware processor to ensure that if something goes wrong during the transformation process you know where it went wrong so you can quickly and easily fix it. Adding a debug-tool layer in this scenario is a WHOLE LOT EASIER than it would be otherwise.
Of course beyond XPath 2.0, XSLT 2.0 introduces functions and functionality that XSLT 1.0 + EXSLT simply doesn't have an answer for. And the fact that with XSLT 1.0 and EXSLT you still don't gain the advantages of XPath 2.0 should be enough to understand why XSLT 2.0 is *CRITICAL* to a company in which has built their entire architectural foundation on top of XML.
>> Is this a real enhancement or merely a business strategy of getting Developers, developers, developers to use THEIR products ?
Please see my reasoning above.
> I am a HARDCORE .Net developer, but even I am not holding my breath on this one.
I'm not holding my breathe. I'm fighting for a cause I believe in by being proactive. It wouldn't work any other way.
Thanks for staying on top of this... it will be great when MSFT produces XSLT 2.0 for the browser as well... life will get a whole lot easier!
@Peter,
>> Thanks for staying on top of this...
np. :)
>> it will be great when MSFT produces XSLT 2.0 for the browser as well... life will get a whole lot easier!
Absolutely 100% agree!