There are a lot of similarities between XML Pipeline and Cocoon. As they are both XML Pipeline Frameworks their pipeline definition formats have a lot of structures in common.

Defining a Pipeline

The XML Pipeline pipeline document is broadly equivalent to the Cocoon sitemap

Defining Processing Steps

XML Pipeline calls these processdefs. Each processdef is uniquely named, and is associated with a definition in an implementation defined manner. i.e. a particular XML Pipeline implementation defines how it interprets a definition. The aim here is to be implementation independent, and therefore multiple definitions of the same processdef can be added to a single pipeline document.

For Java implementations the definition is likely to be a fully-specified classname of the process implementation.

This structure is directly equivalent to the Cocoon component definitions. The main difference that Cocoon provides separate elements for declaring different types of component. However there is a common syntax structure for these declarations, which means that they are equivalent to each other in almost every other way.

Cocoon component definitions give components a name, and define their implementing class.

In XML Pipeline processdef elements can have additional elements from arbitrary namespaces. It can likewise contain additional elements in other namespaces. Therefore additional initialisation parameters could potentially be passed to the component, although this isn't specifically mentioned in the spec. (These additional elements just cannot change the interpretation of the pipeline elements).

Cocoon component declarations can also be parameterised, either by adding additional attributes, or elements to the sitemap.

The constructs are therefore almost identical, other than the explicit Java binding of Cocoon. One could specify a transformation from an XML Pipeline processdef to a Cocoon component declaration by annotating the elements with:

• an attribute to indicate the type of Cocoon component, e.g. a generator
• additional attributes to add the additional parameters

Defining Pipelines

XML Pipeline has a more granular notion of pipeline processing than Cocoon.

Whereas Cocoon defines a complete end-to-end processing pipeline, beginning with generation (input) of XML content and ending with the serialization of some arbitrary output, XML Pipeline instead defines individual stages, each having defined inputs and outputs and dependencies. The tree of dependencies between these stages defines the total pipeline.

XML Pipeline steps have multiple inputs and multiple outputs. A Cocoon pipeline generally has only a single explicit input and a single explicit output. Aggregation, XIncludes, and parameterised component references can be considered as additional inputs. Transformers (and Actions?) can write out additional outputs.

XML Pipeline has nothing to say about what is done with inputs/outputs. Indeed they're only need to define the 'glue' between process steps.

Cocoon has an explicit request/response cycle. An output is always returned to the user-agent. Inputs can vary.

XML Pipelines only generate infosets, they don't actually serialise the results...?

Inputs and outputs for both systems are generally defined as URIs.

One could define a mapping from an XML Pipeline to a Cocoon pipeline by using an XSLT transform that ties together all possible processing steps based on the input/output parameters (Note: using internal pipelines and/or map:resources, and the cocoon:// protocol might actually make this simpler). The xml:base attribute would be used to qualify attributes where required.

Executing the Pipeline

The exact pipeline executed by an XML Pipeline processor will depend on it's inputs, and the requested output.

The pipeline executed by Cocoon will depend on how the request is matched to a pipeline.

The notion of a default output in an XML Pipeline could be simulated using a matcher based on "" or "/" in the Cocoon sitemap equivalent.

Because XML Pipeline does not support wildcards, the mapping to matchers should be straightforward.

Others

In a conversion, the XML Pipeline document element could be mapped to additional outputs, e.g. static documents, XSP pages, config files, etc. This potentially makes an XML Pipeline document completely self-contained, but will be very difficult to manage.

No concept of errors defined in Cocoon, other than the handle-errors element. One might possibly generate a pipeline to read an error document.

Cocoon has param elements similar to XML Pipeline. Cocoon specific details could be stored in the XML Pipeline document as additional annotations in a separate namespace.