Signs on the Sand

@Oleg,

After my post to XML.com, followed by a post to XSL-List regarding my post to XML.com, my guess is that enough of the XML/XSLT folks are now aware to suggest that the "secret" is no longer a secret.

I just hope with all of the hope I can muster up that WebData doesn't change their mind...

One (plural) word,

Riots.

No problem Mike Champi*e*n

:D Smile and know that no matter what letter you choose to represent your intent, the fact that since you have been at MS it seems nothing short of miracles have taken place (let us not forget, oh dea XSLT community, that before MC arrived on the scene, MS had announced they would not be supporting XSLT 2.0 as "XQuery + XSLT 1.0 is all you folks need... you just don't realize it yet. :)" and have since,

- Listened to the community
- Cut XQuery from the .NET framework
- Shipped an early implementation of XQuery as part of SQL Server 2005/Express (extra credit for Michael Rys, et al.)
- Encouraged folks to use Saxon.NET, now Saxon on .NET for XSLT 2.0, XPath 2.0, and XQuery 1.0, and made hints towards the fact that they were reevaluating their earlier decision to dump XSLT 2.0
- Took two of the brightest minds in our field of pretty bright minds, and created brightest minds++ (otherwise known as LINQ/XLINQ/DLINQ)
- And in one swish of the keyboard strokes, have made an unofficial announcment thats about as official as you can get without being official suggesting in no uncertain terms that

-- LINQ does not replace XSLT,
-- XSLT 2.0 development is already under way
-- Gave us a CTP time frame to work from
-- Encouraged us all to continue to use Saxon on .NET from Saxonica

That last point I think is pretty important, as this allows us all to squeeze out all the best pieces of XSLT 2.0 by building code against an engine developed by the another top tier bright mind in Dr. Michael Kay, and in the process work together to help Microsoft figure out where the performance sweet spots exist such that when the 2007 CTP's begin to roll out we can be prepared to beat to help build the best *native* XSLT 2.0 engine money *can't* buy (don't forget, there has yet to be a penny directly made in profit from the likes of an MS build XSLT engine, and yet with one minor "bump", they stay commited to delivering what the customer asks (demands? :D) for.

My fingers are tingling with excitement from all of this...

:D

Thanks for your post Mike. I'm glad to hear that.
Btw, do you realize this is the first time somebody from MSFT says "we are doing XSLT2" publicly?
So far it was NDA, should we spread the word or it's too early and Webdata might change their mind?

PS. Sorry for not posting about XLinq, been too busy, just started reading today.

Oops, "In the meantime, there's SAXON, which NOW runs in the .NET environment". Thanks, M. David Petersen

@Mike,

by 'not' I assume you mean 'now'?

Obviously I'm not one who can be taking people to task for spelling errors, so please don't feel like I am... Just want to be sure that other folks understand that,

"In the meantime, there's SAXON, which not runs in the .NET environment."

really means,

"In the meantime, there's SAXON, which *now* runs in the .NET environment."

Regarding XSLT 2.0 in 2009 -- The very fact that it seems as if theres a good chance that XSLT 2.0 will eventually be a native member of the .NET family puts a smile on my face. I know we both agree that there's not a soul on this planet who could be designing, building, deploying, and supporting an XSLT engine, ANY version, better than Dr. Michael Kay, so the fact that he has dedicated his time to developing a .NET XSLT 2.0 engine brings comfort to my hacker soul :)

The fact that sometime around 2009+ time frame we might also gain a native XSLT 2.0 engine brings even more comfort to my hacker soul :)

Thanks!

NOTE: For those unaware, please visit http://www.saxonica.com for access to the mentioned .NET-based XSLT 2.0 (Basic and Schema Aware versions are available) engine.

2009 sounds about right for an XSLT2 fully integrated into .NET framework. Sigh indeed.

I'm as frustrated as anyone by the pace at which Microsoft moves, but then again, W3C has been working on this stuff since 1999. And we have about twice as many people working on XSLT as we do on XLinq, so it's not a matter of resource allocation so much as a reflection of the complexity of the task of implementing XSLT2 and then very thoroughly testing it, while not breaking existing customers who stick with XSLT1. I had a lot more good ideas about how Microsoft could work better / faster / smarter until I saw the magnitude of the challenges :-)

In the meantime, there's SAXON, which not runs in the .NET environment.

too bad msft decided so early on to drop XSLT2/XPATH2/QUERY1 from .NET

now we'll have to wait for an 'out-of-band' release to help us catch up. at the pace msft moves, XSLT2 will not be 'baked-in' to .NET until they release a *real* .NET 3.0.

2009 maybe? [sigh]

Posted by: mamund at June 13, 2006 7:56 PM

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.

We agree that LINQ does not replace XSLT2, except for fairly simply structured data-oriented XML instances that mainstream developers are likely to use. For very loosely structured human-oriented documents, XSLT is a great tool and LINQ doesn't even try to replace its recursive template matching approach to working with this kind of data.
In short, we think that people who are not XML experts and don't use XSLT today will be able to go farther with XLinq than with DOM when they need to reshape data, but people using XSLT today will evolve to XSLT2 more than XLinq.