March 16, 2005

Announcing the Saxon.NET 1.0 (Saxon-B 8.3 based) RC1 and Saxon# project - A true C# port of the Saxon source

I am pleased to announced two things. One is that through the ongoing efforts of Dimitre Novatchev and his FXSL project he uncovered a nasty Saxon.NET bug in which he reported (as always, Thanks Dimitre!) and I have since been able to spend the necessary time to locate, squash, and bring the final few details to order such that after being verified by Dimitre (so far so good... no doubt if one exists Dimitre will find it and let me know :) and with a successful run through a battery of tests I am working on at the moment the Saxon.NET project will have reached a 1.0 Release Candidate milestone (current base stems from the Saxon 8.3 source) signaling the very real possiblity that support for XSLT 2.0, XPath 2.0, and XQuery 1.0 in their current WD status will be made available in a 1.0 released product to developers of the .NET platform in the very near future.

For those interested I have checked all the source and compiled assemblies into Subversion which can be accessed for viewing at http://source.x2x2x.org/svn/x2x2x/saxon.net/0.1.8.3 and checked out anounymously using the same URI from a Subversion client. At the moment this is not signed but will be by weeks end when, if all goes well, I will make an official Saxon.NET 1.0 RC1 announcement.

It is my understanding that at the moment Don "DonXML" Demsak is pulling things together from the point of view of the XML-MVP community and through recent activitee in the group it is my understanding that other team members plan to get involved in taking Saxon.NET to the next level, something I am truly grateful for and thank everyone in advance for all the efforts they plan to put forth in this regard.

With this in mind and with the precursor that I will continue to provide development effort and support as needed for the Saxon.NET 1.0 release (as well as a few more sample apps I am working on and an extended documentation to cover what is not covered via Dr. Kay already) a path will have been cleared in which I will be filling with a "from-scratch" effort to port Saxon to a complete and total C# base, built around a pure .NET-based foundation. While I don't want to give the impression that I plan to move away from Saxon.NET (it seems that with recent activity in the group a lot less of my time will be required though) this new effort, labeled Saxon#, is something I will be working on from a solo perspective as I feel based on a "Heads down" effort I will be able to quickly deliver Saxon# and as such the community will have two complete Saxon-based XSLT 2.0, XPath 2.0, and XQuery 1.0 processors to work from. If you are scratching your head wondering why go to all the effort a quick view of the Saxon.NET project on Subversion will showcase the fact that Saxon.NET is built around a Java-based foundation which is compiled (after a combination of hacks against the base Saxon source to force the compiled assembly into proper File handling submission) using the IKVMC compiler from Jeroen Frijters IKVM.NET project. As such your existing Java project that makes calls directly to Saxon can now immediatelly be compiled and run on top of the .NET platform using Saxon.NET to handle the XSLT2/XPath2/XQuery processing. If theres is a better example of pure platform interoperabilty (you can do the same coming the other direction using a C#, VB.NET. *.NET codebase to make calls to the Java platform and Saxon Java source. Thats right! You can leave your SOAP REST'ing in the bath water from now on as whe needs WS-* when you have IKVM? (I just made like 470,000 enemies in one statement! Wont be the first time...) Ok, if you plan on making calls to remote applications (450,000 of you are now back, the other 20,000 never liked me anyway... ;) or something rediculous like that (lost another 50,000 on that one) then maybe I can see jumping back into the water for a quick swim (... 1.. no, nevermind) but for bouncing back and forth between Java and .NET on the same machine I doubt you will find something easier than simply adding "using java.io.FileStream;" or "import cli.System.IO.*;" (obviusly there are a million more examples of files that can be inter-swapped) to the top of your C# or Java files respectively (youll need to add the references but if I need to tell you this then I doubt you even know what I am talking about right now... its ok, go back to sleep... I'll be more quiet next time...).

So now with this said then the obvious benefit to a pure .NET foundation and a C# source is that you are taking advantage of all that .NET has to offer and not having to deal with using awkward intermingling of platform specific code (you will find a balance between what you can import and what must be called using the full classpath or namespace reference as there are obviously a TON of crashes that will take place with common things like cli.System.IO.xxx and java.io.xxx) while also gaining (or better said "not losing") some performance in the double translation that takes place via the IKVM.NET solution. Actually the performance loss isnt all taht much usually but enough to justify the port effort without even bringing the native class library into the equation... another obvious win...

With that I am heading back to the grindstone... have a great day!!! :D