The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this specification are to be interpreted as described in .

Applications, for example many web services, can be implemented by integrating business processing and standard XML processing. Business processes vary greatly among different applications and environments, but XML processing is often mostly a matter of composing the individual operations described by separate specifications (validation, transformation, and so on) in a useful order.

provides use cases that demonstrate that no fixed order of processing can be imposed. 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 order of processing actually used in any one application is an important aspect of the semantics of the application, in that it might be imperative that some operations precede others; if some other order is applied, the results might be incorrect. It follows that the ability to identify an underlying processing model and describe how processing is to proceed is an imperative precondition to developing interoperable applications.

Note that for any given application, the processes might require a partial order, and not necessarily a total order. 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 .

This specification describes a declarative XML vocabulary that addresses this need in a way that is tuned for XML processing.

The focus of this specification is intentionally quite narrow, in order to provide a working solution for the most pressing needs first. It is clear that a number of useful extensions could be made to support processing meta-models, wildcards in process inputs and outputs, and so on. These features might be developed over time, but they are not critical to solving the most immediate problems.

It is clear that addressing the whole problem will ultimately require APIs that allow a process manager to initiate individual processes as necessary. This specification does not attempt to address this issue. However, the software development community has already begun to do so with the development of SAX, TRaX, and other APIs.

The identification of a processing model itself could be performed entirely at the programming API level, but this approach seems to set the bar too high. True interoperability will be achieved only when it is possible for end-users working with stock XML tools to build processing models for themselves. Thus, this specification proposes an XML vocabulary rather than an API.

The following process classification provides a framework in which to discuss the operations of applications in general terms:

It is important to note that the classes are not mutually exclusive, as shown, for example, by the fact that some schemas can cause a process to perform construction, augmentation, and extraction. In addition, processes can be hierarchical, with a constructive process performing a bit of validation or extraction, for example.

The fact that documents can be augmented or transformed raises another set of issues with respect to addressing into augmented or transformed results. discusses this at some length.

An individual process produces one or more result resources from some set of input resources. The Pipeline language uses URIs to identify resources (both inputs and results). A pipeline controller uses these URIs to keep track of the resources that it has available. In the context of a pipeline, every resource is identified by exactly one URI. Two resources are the same if they have the same URI. Two URIs are the same if they are lexically equivalent.

To indicate that an inspection process (a process that does not modify an input infoset) has succeeded, the Pipeline forces the process to produce a result with a new URI. The resulting information set will be identical to the input information set, but its new label allows the pipeline controller to keep track of its status.

Note that the processing of URIs in pipeline documents depends on processing.

The resources operated on by a pipeline controller are considered to consist of XML information sets.

Processing begins with an initial set of zero or more information sets, the name of some target that is the desired result, and a pipeline document that describes how documents are related to each other. Every relationship has three parts: a set of input information sets, a process, and a set of result information sets. For example, the result R.xml might be related to a set of inputs, S.xml and T.xsl, by an XSLT transformation. Informally, we say that the process identified by a relationship can produce the results from its inputs.

Processing begins with the pipeline document and the URI of the desired target.

Note that the order of the processes specified in the pipeline document is insignificant. Users need not figure out the right order for the whole pipeline; they need only declare the dependencies. Naturally, dependencies can be made linear, forcing a fixed order if that is what is desired.

We consider a simple application of , validation, and in which the following order is required:

The following example shows what the corresponding pipeline document might look like.

Assume that initially, the pipeline controller is handed this pipeline document along with myfile.xml, mystyle.xsl, and someschema.xsd (all with the base URI http://example.org/). For the purpose of this example, assume that no other documents exist when processing begins. The pipeline controller proceeds along the following lines:

In this example, there is only one order of processing that can satisfy all of the dependencies: xinclude.p then validate.p then transform.p. In a more complex pipeline, multiple or even parallel orders are possible. For example, in , all of the *.ex targets are independent.

The following sections define the rules for pipeline documents and the required semantics of elements in the Pipeline language.