So I’m not sure if I should claim the title as my *BEST TITLE EVER* or one of life’s most embarrassing moments.
Guess time will tell, ;-) and in the mean time: Having a few spare cycles now that CMJ is over and the death march to the Nov. 1st amp.fm private beta release is at worst a brisk walk/jog in the park as far as feature completion is concerned (the Jan. 1st, 2008 @ 12:00:01 public release is a different matter all together, but even that isn’t going to be anything like that last 8 months have been), I took a few moments to catch up on my most favorite product and company of all time,
In the below linked post to the Saxon-Help mailing list you will find a link to the resources file that contains the following overview of the new Java API called “snappy” which, as Dr. Kay points out, “… is closely modelled on the successful .NET API.”
*SWEET*! Well, sweet from the perspective that my brothers and sisters in software development in which use Java as their primary development environment can now understand just how good we .NET developers have had it over the last 20 or so months since Dr. Kay first introduced the Saxon on .NET product. To each of you, I can assure you of one thing,
Snappy’s gunna’ *ROCK YOUR WORLD*!
Thanks, Dr. Kay!
Details follow.
Saxonica: XSLT and XQuery Processing: New Java API
New Java API
A brand new Java API is available in package net.sf.saxon.s9api (pronounced “snappy”, stands for Saxon 9 API). This is closely modelled on the successful .NET API. The design aims were to:
*
Provide an API that is well documented and uncluttered by implementation detail
*Provide uniformity across XSLT, XPath, and XQuery (for example, allowing XSLT and XQuery to be combined naturally in a single pipeline)
*Maximise the ability to create compiled objects that are reusable across multiple threads
*Reuse existing JAXP classes and interfaces where appropriate, but abandon them when they no longer deliver the right functionality
*Provide an accurate representation of the XDM data model
*Provide access to all mainstream Saxon functionality needed by typical users
*Provide escape hatches to underlying implementation classes and methods for power users
*Exploit new Java 5 features such as type-safe enumerations, generics, and iterables, while retaining support for JDK 1.4 users
The new API does not replace any existing APIs: it is a separate layer on top of the Saxon product. It is provided in a separate JAR file, saxon9-api.jar, and can be used only with Java 5. The main Saxon jar files, however, continue to work with JDK 1.4.
For details see the Javadoc: go to package net.sf.saxon.s9api and start with the Processor class.
Saxon will continue to support standardized interfaces such as JAXP and XQJ. However, JAXP has become cluttered and inconsistent, and is still missing support for many XSLT 2.0 features. XQJ has been designed with a client-server architecture in mind, and while it is usable with Saxon, it is not really optimized for the kind of applications where Saxon is deployed. For users who want to exploit Saxon fully in their applications, rather than retaining portability across XSLT/XPath/XQuery implementations, the new API offers a much cleaner choice.
M. David:
I love the title :)
But then again, you ALWAYS come up with quirky titles.
As a .Net XML developer, I am _very_ excitd about this!
@Ric,
>> I love the title :)
*SWEET*! :D
>> But then again, you ALWAYS come up with quirky titles.
Some call it a talent. Others call it annoying. Me? I call it me :D
Thanks for the smile, Ric!