XML Processing Model Workshop

There is a large, and growing, set of specifications that describe processes operating on XML documents. Considering how these specifications interact raises a large number of issues. Our principal concern in this position paper is interoperability.

There are several broad classes of processes that need to be considered:

This is by no means an exhastive list of the processes, nor do processes always fit cleanly into the categories, as you can see. What appears to be augmentation in one application might also be a peephole process in another or even a constructive process. All of which is compounded by the fact that processes can be hierarchical, with a transformational process performing a bit of peephole validation or extraction, for example.

The fact that documents may be augmented or transformed raises another set of issues with respect to addressing into augmented or transformed results. The [XML Linking and Style] discusses this at some length, but there are still many unresolved issues.

The use cases described in Section 3 demonstrate that no fixed order of processing can be imposed, but but the order of processing actually used is an important aspect of the semantics of the application. It follows that the ability to identify an underlying processing model and describe how processing is to proceed is an imperative precondition to developing successful, interoperable web applications.

Before we can investigate what it means to have a processing model, we need some common understanding of what constitutes a process.

For the purposes of this document, we consider any application which constructs, transforms, or augments an [Infoset] to be a processor. A process begins with zero or more Infosets and produces zero or more Infosets (it may also produce ancillary information, such as whether it succeeded or failed). Some processes (such as [Schematron] and [RELAX NG] validation) don't strictly speaking construct, transform, or augment an infoset, but we can finesse that point for the moment by imagining that they perform the identity transformation.

Actually, processes that augment an existing infoset but don't clearly produce a new one represent a special class of process because they may change the fundamental model on which some other process expects to operate.

Although some, perhaps many, applications work with concrete object models that are not identical to the Infoset, it's still useful to describe the processing model in terms of the standard Infoset.

We motivate the rest of our discussion by considering a few simple use cases.

It seems clear from the use cases that no single, fixed order of processing will satisfy all possible applications. Although it would in many ways be easier to build interoperable systems if a fixed order could be defined, any such order would impede some classes of applications.

However, the fact that no fixed order can be defined, does not imply that the order of operations is entirely independent. For any given application, it may be imperative for some operations to proceed others.

This observation offers a key insight into a possible successful processing model: for any given application, the processes that must be performed are partially ordered, but not totally ordered. In other words:

The satisfaction of dependencies between processes is already a well understood problem in software development, it forms the heart of systems like make and even more appropriately ant.

For the purposes of illustration, we consider a simple application of XInclude, XML Schema validation, and XSL Transformation.

The specific case we illustrate is as follows:

When presented with a process control document that describes this process, an "XML Process Manager" builds a dependency graph and selects a valid order in which to execute the steps. And it executes them (in series or parallel). It returns the resulting document(s).

Note that the order of the processes in the control document is insignificant. There's no reason why users should have to figure out the right order for the whole pipeline; they need only declare the dependencies.

We will shortly be making a proposal for an XML vocabulary that will allow these dependencies to be expressed so that an "XML Process Manager" can carry out the required processing.

We are encouraged to see increased awareness within W3C of the fundamental interoperability issues surrounding the use of XML. We believe that this is a fruitful area of pursuit and we would like to see it reflected in the XML Activity's next charter.

We hope, in particular, that W3C resources on the XML Activity can be augmented appropriately to address the pressing problems of infoset composition and interdependency of specifications.