• See XML Pipeline Frameworks
• See also XML Pipeline And Cocoon

Summary

Declarative syntax used to create pipeline documents. These documents describe the processing required to generate a resource(s). A pipeline processor reads these documents to discover the processing required to generate that resource.

The processes are considered to operate on infosets, at least as a logical abstraction. In practice is acknowledges that custom object models, SAX events, or DOM trees may be the vehicle of exchanging this data.

A single process can generate multiple output resources from multiple input resources. Each resource is defined by a unique URIs. Resources that pass through any sub-process are considered to be consumed: a new unique URI is required to define the results. Enables the processor to identify what resources are available (i.e. has step X completed?)

For each resource there can only be a single way to create it. This allows the controller to determine how to build an out-of-date resource. A resource is out-of-date if it doesn't exist, or if at least one of the resources it depends on is newer than it (this should be applied recursively to the entire graph)

The dependency tree is a DAG.

A process can ignore errors, and return error documents instead. This seems slightly unnecessary -- how do we define useful "error documents"

Additional elements and attributes from other namespaces can be added in certain places, but these should be ignorable. i.e. they should not influence the basic behaviour. Note that the foreign elements themselves cannot contain pipeline elements.

Scope

Doesn't support:

• processing of meta-models
• wildcards of input/output?
• nothing to say about APIS

Syntax

Processdef

How a process is defined is implementation specific. For example a Java pipeline processor might interpret the definition as the name of a Java class. A processdef can contain foreign markup, so in theory it could contain parameters for a process, or potentially even a complete XSLT stylesheet.

A pipeline can have several processdefs defined with the same name. So it ought to be possible to include multiple implementations in different languages?

Process

Must be defined. Can have inputs, outputs, errors, and params

....

Comments

Comments that the use cases demonstrate that no fixed order of processing can be mandated, and that "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."

This seems a typical black-and-white engineering decision. We can't define a single processing order, therefore we must adopt a solution that allows for an infinite range of alternatives. However it seems likely that for particular application areas certain order of processing make more sense that others. Can some of these be defined?

(One might also ponder whether, should one or more of these be identified, if alternative processing descriptions might be more useful. i.e. if certain steps have a fixed order then some higher level abstractions could be useful)

The Note does acknowledge that for an individual application a total, or partial order of operations is significant.