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!
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.