• Login / Register
    • Help

Find Communities by: Category | Product

XProc Engine version 1.0.13 has been released recently - download from here. It offers a number of improvements and upgrades.


XProc Engine passes 99.85 % of the XProc test suite (one failing test).

Version 1.0.12 implemented XProc Recommendation May 11th 2010, .


For the complete change log, see XProc Engine Changes.

I have submitted the results of running the XQuery Update Test Suite against the xDB version that is currently in development to the W3C. You can find a summary of the test results and details (large document) on the W3C homepage.


As you can see, xDB scores >90%, with 66 failures of 725 tests. So what is keeping us from 100%?


Update Statement Placement


XQUTS specifies a set of rules dictating where update statements are allowed to be in an XQuery, and where not. The intent is to completely separate updates and regular queries. We have partially implemented these rules, but reluctantly, and only for the sake of specification compliance. By default, xDB doesn't enforce these rules unless you explicitly ask for them. This is because we think returning values after executing an update is a very valuable thing, for example returning how many elements your query updated, and this is made impossible with strict checking.


I know others in the Working Group share this sentiment, let's see if we can fix that by adjusting the spec in the future.


Namespace Binding Conflicts and Inheritance


Many of the tests in the XQUTS suite center around namespace bindings, copying nodes, and updating the namespace bindings correctly. This might make sense in some applications that treat XML as text, or directly serialize results out, but for xDB, this is simply superfluous. xDB is a native XML database, so nodes are stored with their complete (namespace URI, prefix, local name) triple. If you serialize nodes, xDB will automatically fix up your namespace declarations and bindings, so all is fine.


As a consequence, we have never implemented "declare copy-namespaces preserve, inherit", nor has a customer ever asked for it as far as I know. We also don't have issues with conflicting namespace bindings.


I don't think we will implement this anytime soon. I personally feel that this whole namespace prefix messing complicates the specification and implementations, for no good reason if your implementation handles the XML info set properly. There is some validity in this if you use a text editor to write XML, but even then it is in my experience highly unlikely that people actually run into conflicting namespace bindings, e.g. by binding the same prefix to different URIs.


Schema Element Tests


Another thing we do not implement at the moment is schema-element tests. They allow users to declare a variable as - for example - containing documents where the root element is of the schema-element type X. This presumably makes a lot more sense in XQuery implementations that use static typing. Again, a feature no user has ever asked for, but I'm thinking about implementing it, for the sake of standards compliance.


The Remaining Issues


That being said, there are still some corner cases where we fail and which I'd like to fix, seven to be precise. I think all of them are rare corner cases, and in at least two cases I'm not sure if it's actually a bug or simply an ambiguity in the spec.

Just cross-posting in case you didn't catch it:


The xDB Desktop App and Atmos Reader are simple applications that add features like web 2.0 style tagging, ranking, summary, flat file collections and full-text search to desktop files and optionally push files to the EMC Atmos onLine storage cloud to be accessed from an iPhone.


These applications were built to explore a composition of different EMC developer platforms.



For those who are interested in XProc, or willing to learn more about its possible applications, I decided to put online my slides from this year's XML-in-Practice conference. In the presentation, I give a (very) brief introduction to XProc and discuss its potential as an application integration technology.

XProc Engine version 1.0.9 has been released today - download from here. The new version reflects the latest changes to the XProc specification (see the not-yet-published Editor's draft) and improves the overall level of compliance. As of today, XProc Engine passes 99.81% of the XProc test suite (one failing test).


Except for fixing various bugs found in the previous versions, version 1.0.9 introduces a number of new features. The most significant one is probably the inclusion of the Saxon plug-in that adds XSLT 2.0 support to the engine; a feature that was much needed. Support for XSLT 2.0 also represents an important step towards complete support of the XProc specification.


Speaking of plug-ins, the plug-in architecture has been completely redesigned, with the aim to make creating extension plug-ins easier for application developers. The new plug-in infrastructure also makes it possible to use the plug-ins from the command-line, which the previous versions of the engine didn't support.


Other significant new features include the new security API (which allows application developers to contol various security aspects related to running XProc pipelines, such as accessing resources, importing XProc pipelines, executing steps etc.) and much improved, from-the-ground-up reimplemented, support for XML serialization.


For the complete change log, see XProc Engine Changes.

Vojtech Toman

New XProc Draft

Posted by Vojtech Toman Jun 1, 2009

The XML Processing Model WG published a new XProc draft last week. You can find an overview of the most significant changes on Norman Walsh's blog. (Norman is the chair of the WG and is also responsible for Calabash, an open source XProc implementation.)


XProc became a W3C Candidate Recommendation on 26 November 2008. Yesterday's draft represents a culmination of a 6 months long effort during which the WG has addressed all of the outstanding CR issues. As Norman believes — and I share his view — the specification is very close to being done.


The next step is Proposed Recommendation — but for that, the XProc test suite needs to be expanded (contributors welcome!) and “our implementors need to get to complete coverage”. I am certainly working on both.


Vojtech Toman

XRX with XProc

Posted by Vojtech Toman Apr 14, 2009

XProc is the perfect enabling technology for other XML standards that require a certain level of XML processing capabilities — a nice example of which is XForms.


From the ground up, XForms is entirely based on the XML model. While this clearly is an advantage from the design perspective, it can also be seen as one of the main reasons of the low adoption of the standard. The XForms model and the XForms instance data are XML documents, and to manipulate them, the ability to process XML data is necessary.


With the increasing proliferation of native XML offerings, and growing adoption of XQuery as the query language in these tools, things finally seem to be getting in motion for XForms — as demonstrated, for instance, by the recent buzz around the XRX (XForms/REST/XQuery) web application architecture. In short, XRX makes it possible to deploy XForms in end-to-end XML environments, eliminating the need for using non-XML models, such as middle-tier objects or (often costly) conversions of the submission data to relational structures.


XProc with its declarative, native XML processing model fits seamlessly in the XRX stack. XProc pipelines have the same power as XQuery (which is supported in XProc via the p:xquery step), while providing the application developers with additional functionality such as schema validation, XInclude processing, or HTTP support. But it's not only about complex things - one of the strengths of XProc is that it makes it equally easy to do simple tasks: adding attributes here and there, replacing a subtree in the document, renaming elements, etc. Add to that the modular nature of XProc (XProc is a joy to extend/customize/maintain) and you end up with a very powerful XML application architecture indeed.


Filter Blog

By date: