June 22, 2005

Before the MS XSLT 2.0 rumors become solidified in concrete by days end read the second sentence | Oh, and some questions and answers regarding where Saxon.NET fits into all of this

[UPDATE: With as many references to XML-related technologies, specifically XSLT 2.0, as well as the overabundance of references to the .NET platform and the Saxon (and Saxon.NET) processor how did Google determine that the best ads to sit side by side with this post should be related to World War II? Might wanna' check that "amazingly advanced" ad matching technology you've been toutin' there Google... think you might have a glitch or two to deal with, but maybe its just me ;)]

monogatari

The best approach to interoperability is to focus on getting widespread, conformant implementation of the XSLT 2.0 specification.

Atsushi Eno doesn't blog often but when he does I tend to drop whatever it is I am doing and devour every word, putting it to memory and committing to a local Subversion repository of important posts just in case something horrible were to happen to the original and a 404 was found upon my next visit. Two reasons for this:

• Look at his code. It's all open source and an integral part of the Mono project as Atsushi is the genius hacker behind Mono's System.Xml implementation. As such, you can gain access to each and every line Atsushi has checked into source control.
• XSLT falls under his development jurisdiction. Did I mention the fact that his code ROCKS!? I learn a TON from reading Atsushi's source code and you can too if the desire were to exist. :)

Its amazing how much you can learn from reading someone's source code. Of course if they don't have half a clue with what they're doing what you learn is that they don't have half a clue and their code sucks. This is MOST DEFINITELY NOT the case when Atsushi Eno has been anywhere near the source you are currently reading from.

But this is of course beside the point. What nearly had me dropping straight to my knees in praise and gratitude for whatever the Allmighty did to bring the above statement into this document was quickly thwarted by the follow-up sentence:

I just quoted from Microsoft's statement on XML Schema. Mhm, am so dazzled that I might have mistyped.

If you access the document and implement a search for XSLT you will quickly realize that the letter sequence 'x', 's', 'l', and 't' is never found together as one word, a word of acronymic descent but a word none the less (depending on dictionary used and context of course but isn't that true of every word?) By running a quick visual scan of the document you will then find the following header and bolded statement following it:

Conclusion / Recommendations

The best approach to interoperability is to focus on getting widespread, conformant implementation of the XSD 1.0 specification

Even given the faked attempt to suggest that Microsoft had all but announced support for the XSLT 2.0 specification one has to recognize the fact that Atsushi seemed to choose the variation that he felt was more in line with making the entire statement plausible if such a statement and implementation were to take place. However, thats infering quite a bit into a few short words so please don't take this as anything more than my personal interpretation. I'd bet if you were to ask him[contact info in right column] to expound his thoughts he may just do that, but then again maybe he's said all he is going to say.... for now ;)

Either way I plan to pay twice as much attention to what takes place in Atsushi's development activitees as it seems this tends to be the best way to get a feel for what is priority and what is not (pretty basic logical deduction there, huh? :)

So to beat this post to death, lest ask the question:

Does Atsushi know something we don't?

The recent XSLT related activity on the XML WebData blog, posted by Nithya, the new PM for (among other things) the future of XSLT support at MS (whatever that may be) definitely suggests they have listened and learned from what I personally believe is now considered a significant mistake in which they have open the doors back up and stated (not-quite literally, but close):

[Paraphrase("http://blogs.msdn.com/xmlteam/archive/2005/06/07/426511.aspx")]

What do you want for XSLT support in the Orcas delivery time frame and should this include XSLT 2.0? If you want it (as a community) and it seems within reason this is what we plan to do.

The links contained in this post are links I personally plan to pay some very specific study time to as well as continual monitoring of any changes that take place and what these changes are. Without a doubt if something seems significant I will report it to this blog. But it never hurts to have more than one set of sensors keeping tabs on the System.Xml namespace and furthermore the System.Xml.Xsl for both the Mono project as well as Microsoft's own implementations of the Common Language Infrastructure standard.

Now, one might ask "If MS were to implement XSLT 2.0 support where does that leave Saxon.NET"

Good question. First off Saxon and as such Saxon.NET is more than XSLT 2.0 as XQuery is also fully supported as is XPath 2.0 (of which would be a mandatory development project to be able to then implement XSLT 2.0). But lets take all the standards support out of the equation and look further as just how much Saxon (8.x series) offers via extension functions, optimizations, extended language functionality, etc... And this doesnt cover the area of Saxon SA which if you were to look at all that is offered for rquired licensing fee of $500 U.S. dollars you will quickly realize just how much of a genius Dr. Kay [in many ways, but the focus in this example is Saxon] is when it comes to the development of ALL the necessary functionality that enables the ability to do so much more than any of os ever dreamed would even be possible. If you haven't already, go purchase a license for a copy of SaxonSA and find out what I am refering to... Too much to list here but you can find an overview list and further details in the Q&A section on the main Saxonica web presence at Saxonica.com.

Now, I am not suggesting that Saxon.NET also comes in an SA version. But it is my understanding that there is an extreme amount of interest in Saxon.NET SA and as such my guess would be you will eventually find this as an option for a growing list of available products, licensed directly from Saxonica. But please take my own opinions with a grain of salt and contact Dr. Kay through the Saxonica web site if you feel this is something you would like to have in your .NET toolbox at some point in the future.

So to summarize that blob of text hangin over the top of this sentence... Q: If MS implements XSLT 2.0 support in Orcas does Saxon.NET still have a place in the .NET developers toolbox?

"A MOST RESOUNDING YES!!!" would be my response to such a question and as such you are going to continue to see an active stream of releases coming from the Saxon.NET namespace.

How can I be so sure?

Well, since I am the only active developer on the project I can pretty much announce whatever it is I feel I will continue forward with from a personal standpoint and this is something I definitely plan to continue forward with just as much, if not more so, if this recent MS XSLT 2.0 window of possibility is to come to fruition. If you think about it, with the possibility of native XSLT 2.0 support as a real possibility in MS's future then between now and then the importance of continued integration into the .NET FCL such that the transition from one to the other is, quite literally, seemless is probably the most important contribution I can make to the .NET XSLT community and I have ever desire, plan, and intention to do just that. Add to this the potential of the features of Saxon.NET SA if it were to come into fruition and you have yourself a pretty kick a$$ combination of capabilities that by that point should simply interact with the System.Xml namespaces and related types as if they came from the exact same internal source tree -- seemless and perfect. :D

Seems like a pretty good reason, huh?

Enjoy your day!

[*Orcas is to Visual Studio.NET what Chicago was to Windows 95... Project code name. Orcas is the Longhorn-enabled delivery of Visual Studio.NET which is slated as the next major release to follow Whidbey, the current project code name for Visual Studio.NET 2005]