Specification complete on XPath 2.0, XSLT 2.0, XQuery 1.0 - Beta 3 of XML Feature Pack Released

I'm happy to announce another update of the XML Feature Pack. The first beta focused on XPath 2.0. The second beta focused on XSLT 2.0. This third beta rounds out the specs with support for XQuery 1.0.

Once we're not in beta, we'll post final numbers on the W3C website on the XML Query Test Suite conformance. Currently we're at 96.8% on minimal conformance and we have support for the optional full axis and serialization features. As for XPath 2.0, and XSLT 2.0, we consider this beta release to support all of the specifications with minor restrictions as listed in the getting started guide. This means that we now have support for all for the W3C recommended standards for Querying, Transforming, and Accessing XML data (except the less popular XQuery/X).

We have expanded the XML Feature Pack API to handle feedback from usability studies and to handle new features required by the standards.

We have focused on items that make the feature pack easier to use. We have made changes to allow the feature pack runtime to run under Java 2 Security, without requiring an application to enable any more security than minimally needed. We have expanded the options for the command line tools for pre-compiling xml artifacts. We have also added ANT tasks for integrating this pre-compilation support into your build scripts.

With the full standards support, updated API, and runtime and development time improvements, this feature pack release should be quite useful. In the next few days, I'll post some videos to demonstrate the new capabilities on YouTube. In the meantime, you can download the feature pack beta and join the web forums to ask questions.

Another reason for DataPower SOA appliances - XML Threat Protection

I've gotten a few questions on recent XML security buzz. On today's blog post by Rich Salz (lead architect of our appliances) discussed how XML threat protection is a required tool when exposing important services to untrusted sources. He talked about this due to the recent press interest in "XML Exploits" which was started by some XML fuzzing work by Codenomicon.

I wanted to post about it here to make sure this wasn't an unknown concept to our customers. Rich talks about "defense in depth", which is what most of our WebSphere customers are doing today. To quote Keys Botzum (one of our lead security consultants for WebSphere, "Anyone that is exposing services to untrusted sources absolutely needs to be running a XML firewall, like DataPower)". In my world, defense in depth means putting a WebSphere DataPower XML Security Gateway XS40 in front of any services that could be called by untrusted sources. Also, given the performance characteristics of the DataPower devices (basically no latency impact), you likely want to do this on all services (as sometimes hacks aren't intention and sometimes hacks come from internal sources).

If you haven't heard of XML firewalls or XML threat protection, think about network firewalls. Network firewalls are great for protecting us from threats that can be detected at the network level (like the recent Twitter and FaceBook distributed denial of service attacks), but they don't help you with threats that are in the payloads of messages themselves. XML Firewalls help you with such application level threats by turning away bad messages before they enter your enterprise applications.

If you have any questions on the concept, feel free to pop over to Rich's blog and ask.