Poor Man's XQuery Update

By Erik Wilde
September 12, 2008

The IETF just published RFC 5261, An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors. It is a language situated somewhere between the long-obsolete XUpdate and the much more complex XQuery Update Facility. Here's the abstract:

Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic <add>, <replace>, and <remove>  directives a set of patches can then be applied to update an existing XML document.

The language is not a complete diff language for XML, it only talks about add, replace and remove operations on the node level, defining operations for the basic node types in an XML document (elements, attributes, text, namespace declarations, comments, processing instructions). The idea is that you have an XML document (potentially large), you apply a patch to it (hopefully small), and this updates the XML document (here are examples for adding, replacing, and removing elements).

At first i thought this would be ideal as a small exercise in XSLT: Everything is XPath-based, so it would be almost trivial to implement. As it turns out, though, this is not true at all. It is almost impossible to implement, because XSLT (not even XSLT 2.0) has no function for dynamically evaluating XPaths. Most XSLT processors have an extension function for (for example, evaluate() in saxon), because it is a well-known weakness of the language, but it is almost impossible to dynamically evaluate XPaths in standard XSLT (unless you write a complete XPath parser in XSLT, which is probably a pretty advanced undertaking).

One could still use XSLT to generate an XSLT which then applies the patch, but that does not seem to be very elegant. Is there some better way in which XSLT could be used to implement something that at first sight looks so well-suited for XSLT? I guess my approach will be to write XSLT that does use an extension function, and with XSLT 2.0 the could could at least be written in a way that it checks for the availability of a function and let the code adapt to various execution environments.

You might also be interested in:

News Topics

Recommended for You

Got a Question?