Port of Santuario 1.4.5-r01

Yesterday I posted the new build of the GenXDM port of Apache‘s Santuario XML Security Java project, version 1.4.5.

This means that the port has now achieved complete parity with the official project, and further adds full support for GenXDM for all public APIs.

The 1.4.5 release of Santuario introduced some additional test cases, and as before, I copied those test cases and ported them to use GenXDM. This means that all existing test cases continue to run unmodified, and there are yet more test cases that confirm GenXDM based functionality.

Particularly if you only use the library via the javax.xml.crypto APIs, this library should now be a complete drop-in replacement for existing uses, and enables the use of GenXDM whenever you want it….

Please feel free to kick the tires, and let us know about issues you find with either the port, or GenXDM itself!

Santuario port 1.4.4-r02 release

I just posted a new version of the port of the Santuario library. This builds upon the 2011-06-27 release of GenXDM (which includes some small fixes to the bridges that help out the Santuario port). More importantly, this adds a fix for issue 10, support for the javax.xml.crypto implementation using GenXDM.

As with the port of the rest of the library, I preserved the existing API while rewriting the existing DOM-based code to use GenXDM constructs. For example, in places where a DOMStructure gets passed the implementation observes that it is an instance of that class, and provides an appropriate instance of Model and DocumentHandlerFactory to code that does the actual work. Of course, clients need to be able to pass their own instances of Model and DocumentHandlerFactory. To that end, I added a GenXDMStructure class, which is analogous to the DOMStructure class, and adds instances of the Model and DocumentHandlerFactory.

Following the pattern of DOMStructure/GenXDMStructure, for four other classes in the original API (DOMCryptoContext, DOMSignContext, DOMURIReference, and DOMValidateContext), I created new classes for GenXDM constructs. Thus, a client wishing to use the GenXDM form of the implementation merely needs to instantiate these new constructs, rather than the old DOM-specific ones.

Since the port modifies the existing DOM code to use GenXDM, this means that all of the current test cases help to validate the quality of the port. To complete the picture, though, I provided additional test cases that use the APIs with non-DOM underlying trees. Since many of the existing test cases rely on a “SignatureValidator” class, and don’t have any DOM specific code, I updated the “SignatureValidator” class to enable switching amongst different underlying tree models. Fortunately, that left only a small number of additional test case files that I needed to copy and rewrite to use GenXDM constructs.

Please check out the 1.4.4-r02 release, and let us know how it works for you. It should be functionally equivalent to the Santuario 1.4.4 release for DOM. Of course, since it uses GenXDM, it supports non-DOM XML trees for which bridges exist – that we know of, this includes Axiom & our “Cx” reference implementation.

The next release will address issue 14: porting changes made in the 1.4.5 release.

First Santuario Port Release

I’ve posted the first official release of the Santuario port to use GenXDM. I’ve labeled the release santxmlsong-1.4.4-r01. The name comes from SANTuario XML Security ON Genxdm. (If you’ve got better recommendations for the name, please suggest them, and perhaps we can use that for the next release.)

This release is supposed to be functionally equivalent to the xmlsec-1.4.4 release. I’ve attempted to keep API compatibility, but only for those methods actually being used. For example, all of the official test cases for the library pass unmodified. However, if you use some of the less frequent entry points, not covered by the test cases, then they might not be there. If that’s the case, let me know, and we can restore them!

Please feel free to take it for a spin!

For details about the project, check the project page.

April 2011 Release

We released a new version of GenXDM on April 15th of this month. With so much to work on, we were a little slow in posting notes about what went into it.

Of course, you could search the issues list, but you might miss some of the subtlety, so let me see if I can summarize the key points:

• 34 & 16 & 19: We changed the mutable API to match, as closely as possible, the XQuery Update Facility specification.
• 48: Reorganized core API packages. We wanted to get this out of the way so that we can consider the API stable.
• 9 & 11: Significant overhaul to the XPath API. See the previous post on this.
• 35: Switched to using JUnit 4. OK, well maybe clients of the code won’t care, but we do.
• 41: Clarified meaning of node identity
• 12 & 42 and various commits: DOM bridge improvements & bug fixes.
• A completely overhauled test suite that does a much better job of validating the implementation of a bridge. Also fixed the DOM & Cx bridges to match the test suite.
• A completely overhauled, and almost complete implementation of a bridge for Axiom. Note that we since fixed a bug related to the axiom bridge that didn’t make it in this release.

The bridge implementations now get tested far more fully, and we’re far more confident of their completeness, now. Please dive in and let us know what you think of the latest release!

Improved XPath API

We’re working toward our next release of GenXDM. We’ve not been doing quite as good a job at the “release early, release often” approach that we should be taking, but we’re getting closer to a new release.

One of our recent key changes dealt with a long-standing bugaboo of mine. Specifically, I filed bugs 9 and 11. Issues of the sort represented by this pair will cause us headaches further on if we don’t deal with them now. That’s because we don’t want to change the API more than we have to, but we definitely don’t want to change it after we reach a “1.0″ milestone. Issue 11, in particular, noted the presence of a lot of concrete classes in an apparent API package.

Taking the approach of diving in and seeing what happens, I started replacing all the references to concrete classes with references to interfaces. The intermediate results caused some angst (“IConvertible____” interfaces) suggesting that the abstractions were not quite right. After a brief email exchange, we figured out how to address that problem, and turned forty-one class files as part of an API into a much smaller collection of what is now just twenty-two, and also reduced the package count down to just two.

As a nice side benefit, I can describe the purpose of the new packages much more readily. One package (org.genxdm.xpath.v10) is there for mere clients of XPath. The other package (org.genxdm.xpath.v10.extend) is there if you need to add a function to the XPath engine. What makes this change even cooler – I had to implement an extension function (“here”) for the port of the XML Security library. With the newly restructured API, I was able to implement the function purely with the new API, rather than resorting to extending the implementation we have.

One final note. Now that we have this simplified API, it looks quite possible to create a javax.xml.xpath wrapper around our API. Such an API would give people who want to experiment with GenXDM a way to do so while still using what they’re familiar with. This wrapper won’t replace the API we have for at least two reasons. Our API:

• uses generics and types, producing more type-safety than does the javax.xml.xpath API
• defines how to add extension functions

Well, in any case, an implementation using javax.xml.xpath APIs is possible, but we don’t have any demand for it yet….

The new release has some other cool stuff in it, but that’s for another blog post.

Port of Apache Santuario to GenXDM

I’ve made reference to a port we’ve been working on, namely moving Apache Santuario, a.k.a. XML Security to work on top of GenXDM. I’m now pleased to announce that we’ve released said port under the Apache license, and you can now check out the project hosted on the Apache Extras site.

We think this port shows important aspects of GenXDM. It shows you can take a sophisticated code base, that cares about many details of XML, and convert it to work using GenXDM. It shows that you can build such ports in a way that provides backwards compatibility with existing DOM APIs (or other tree APIs, for that matter). It validates the mutation part of the GenXDM API, something we introduced to the code-base only after we decided to release the technology as open-source. And it shows that you can do side-by-side comparisons of XML tree technologies, and choose one at runtime that best fits your use case.

We recognize that there’s still more work to do on this port. However, we pass all the existing test cases, so most of what’s to be done really falls into the category of enhancements.

If you’re at all interested, please check out the project, and let us know what you think. If you give it a try, let us know what you find out!

Improved Mutation API

What with the holidays, and actual coding work, we’ve not crammed in to many posts for GenXDM lately.  Time to fix that.

We’ve made a critical improvement (well, in the source, we’ve not done a release with it yet).  Our original drop included a mutation API.  We added this API to facilitate the conversion of existing XML tools that actually need to mutate existing XML trees.  When we added the mutation APIs, we mirrored the functionality on what we were trying to replace: DOM.  Among the unfortunately aspects, this gave us bug 16, that of baking a notion of “owner” into the mutable API.

A key trouble is that DOM conflates the “root” of a document with that of a “factory” for new elements.  For all other XML tree APIs we’ve looked at, the APIs separate these two concepts.  GenXDM already separated these two notions by introducing a “NodeFactory”, but that still required the use of an “owner” parameter.  What to do?

XQuery Update Facility

Along our journey, we noticed XQuery Update Facility (XQUF), and consequently filed bug 19.  We brought together the two bugs – the annoying DOM notion of “ownership” and our failure to follow the XQUF APIs.  Fortunately, the XQUF APIs don’t have a notion of ownership, so perhaps we could kill two birds with one stone.  We converted our mutable API to follow the pattern of XQUF.  To prove it out, we also converted the one project that extensively uses the mutable APIs – XML Security.  This ended up being a fair chunk of work, in part because there was no way to incrementally port XML Security to the new APIs, the whole library had to be converted all at once.  (I’m using the combination of all of these changes plus holidays and such as part of my lame excuse for not posting more frequently.)

Very much like with the core GenXDM APIs, we’re not able to exactly follow the XQUF specification.  Notably, XQUF has a notion of pending changes – all the APIs we have make immediate changes.  This means that some of the methods, like “mergeUpdates”, and “applyUpdates” don’t make sense, and “propogateNamespaces” sort of makes sense, but we added “insertNamespace” instead.  For the APIs that do make sense, we’ve done our best to follow XQUF.

For now, we’re thinking that a notion of pending changes will have to wait until we see a need for it, and then we can make it a part of interfaces that extend the ones we just built.

Overall, I’m happy with the changes, because it actually simplified some of the XML Security code changes.  In places where we needed to pass along an instance of “NodeFactory”, an “owner”, and the node to be updated, we now only need to pass along the “NodeFactory” and the node to be updated.  Of course, this implies that NodeFactory actually has state, and can only be used with a single DOM Document (if that’s your underlying model), but that’s pretty easy to deal with.

Conclusion

Our mutable API now has the benefit of actually being more closely tied to the XQuery standard that we’re trying to follow.  Also simplified some of the code that actually mutates XML trees.  Overall, a significant improvement.