XProc: An XML Pipeline Language

2.1 Steps

[Definition: A step is the basic computational unit of a pipeline. Steps are either atomic or compound.] [Definition: An atomic step is a step that performs a unit of XML processing, such as XInclude or transformation.] Atomic steps can perform arbitrary amounts of computation but they are indivisible. Atomic steps carry out fundamental XML operations. An XSLT step, for example, performs XSLT processing; an XML Schema Validation step validates one input with respect to some set of XML Schemas, etc.

Compound steps, on the other hand, control and organize the flow of documents through a pipeline, reconstructing familiar programming language functionality such as conditionals, iterators and exception handling. They contain other steps, whose evaluation they control.

[Definition: A compound step is a step that contains additional steps. That is, a compound step differs from an atomic step in that its semantics are at least partially determined by the steps that it contains.]

Every compound step contains zero or more steps. [Definition: The steps that occur directly inside a compound step are called contained steps.] [Definition: A compound step which immediately contains another step is called its container.]

[Definition: The steps (and the connections between them) within a container form a subpipeline.] A compound step can contain one or more subpipelines and it determines how, and which, if any, of its subpipelines are evaluated.

Steps have “ports” into which inputs and outputs are connected. Each step has a number of input ports and a number of output ports, all with unique names. A step can have zero input ports and/or zero output ports. (All steps have an implicit standard output port for reporting errors that must not be declared.)

Steps have any number of parameters, all with unique names. A step can have zero parameters.

2.2 Inputs and Outputs

Although some steps can read and write non-XML resources, what flows between steps through input ports and output ports are exclusively XML documents or sequences of XML documents. Each XML document (or document in a sequence) must conceptually be an [Infoset] with a Document Information Item at its root. The inputs and outputs can be implemented as sequences of characters, events, or object models, or any other representation the implementation chooses.

It is a dynamic error if a non-XML resource is produced on a step output or arrives on a step input.

An implementation may make it possible for a step to produce non-XML output (through channels other than a named output port)—for example, writing a PDF document—but that output cannot flow through the pipeline. Similarly, one can imagine a step that takes no pipeline inputs, reads a non-XML file from a URI, and produces an XML output. But the non-XML file cannot arrive on an input port to a step or pipeline.

Each step declares its input and output ports. [Definition: The input ports declared on a step are its declared inputs.] [Definition: The output ports declared on a step are its declared outputs.]

All of the declared inputs of a step must be connected. Inputs may be connected to:

If the connection for an input port is not specified then it is connected to the default input port in its environment. It is a static error if a step has an input port which is not connected and the environment does not have a defined default input port.

The declared outputs of a step can be connected to:

Unconnected output ports are allowed; any documents produced on those ports are simply discarded.

[Definition: The signature of a step is the set of inputs, outputs, and parameters that it is declared to accept.] Each atomic step (e.g. XSLT or XInclude) has a fixed signature, declared globally or built-in, which all its instances share, whereas each compound step has its own signature declared locally.

[Definition: A step matches its signature if and only if it specifies an input for each declared input and it specifies no inputs that are not declared; it specifies a parameter for each parameter that is declared to be required; and it specifies no parameters that are not declared.] In other words, every input and required parameter must be specified and only inputs, outputs, and parameters that are declared may be specified. Outputs and optional parameters do not have to be specified.

Each input and output is declared to accept or produce either a single document or a sequence of documents. It is not a static error to connect a port that is declared to produce a sequence of documents to a port that is declared to accept only a single document. It is, however, a dynamic error if the former step actually produces more than a single document at run time.

Steps may also produce error, warning, and informative messages. These messages appear on a special “error output” port defined (only) in the catch clause of a try/catch.

2.3 Parameters

[Definition: A parameter is a name/value pair.] The name of a parameter must be an expanded name. The value of a parameter must be a string. If a document, node, or other value is given, its [XPath 1.0] string value is computed and that string is used.

[Definition: The parameters declared on a step are its declared parameters.]

2.4 Connections

Steps are connected together by their input ports and output ports. It is a static error if there are any loops in the connections between steps: no step can be connected to itself nor can there be any sequence of connections through other steps that leads back to itself.

2.5 Environment

[Definition: The environment of a step is the static information available to that step.]

The environment consists of:

[Definition: The empty environment contains no readable ports, no in-scope parameters, an undefined default input port, and a set of ignored namespaces that consists only of the XHTML namespace, http://www.w3.org/1999/xhtml.]

3.1 Pipeline

A pipeline encapsulates the behavior of a subpipeline.

Viewed from the outside, a pipeline is a black box which performs some calculation on its inputs and produces its outputs. From the pipeline author's perspective, the computation performed by the pipeline is described in terms of contained steps which read the pipeline's inputs and produce the pipeline's outputs.

For example, a pipeline might accept a document and a stylesheet as input; perform XInclude, validation, and transformation; and produce a sequence of formatted documents as its output.

There is one additional constraint imposed on pipelines: a pipeline must not itself be a contained step.

3.2 For-Each

A for-each step processes a sequence of documents, applying its subpipeline to each document in turn.

A for-each has a single input port through which it receives the document or sequence of documents over which iteration is performed.

When a pipeline needs to process a sequence of documents using a step that only accepts a single document, the for-each construct can be used as a wrapper around the step that accepts only a single document. The for-each will apply that step to each document in the sequence in turn.

The result of the for-each is a sequence of documents produced by processing each individual document in the input sequence. If the subpipeline is connected to one or more output ports on the for-each, what appears on each of those ports is the sequence of documents produced by each iteration of the loop.

For example, a for-each might accept a sequence of DocBook chapters as its input, process each chapter in turn with XSLT, a step that accepts only a single input document, and produce a sequence of formatted chapters as its output.

3.3 Viewport

A viewport step processes a single document, applying its subpipeline to one or more subsections of the document.

A viewport has a single input port over which it receives a single document.

The result of the viewport is a copy of the original document with the selected subsections replaced by the results of applying the subpipeline to them.

For example, a viewport might accept an XHTML document as its input, apply encryption to selected div elements within that document, and return an XHTML document that is the same as the original except that each selected div has been replaced by its encrypted result.

3.4 Choose

A choose step selects exactly one of a list of alternative subpipelines based on the evaluation of [XPath 1.0] expressions.

A choose has no inputs. It contains an arbitrary number of alternative subpipelines, exactly one of which will be evaluated.

The list of alternative subpipelines consists of zero or more subpipelines, each guarded by an XPath expression (with an associated context), followed optionally by a single default subpipeline.

The choose considers each subpipeline in turn and selects the first (and only the first) subpipeline for which the guard expression evaluates to true in its context. If there are no subpipelines for which the expression evaluates to true, the default subpipeline, if it was specified, is selected.

After a subpipeline is selected, it is evaluated as if only it had been present.

The result of the choose is the result of the selected subpipeline.

For example, a choose might test a schema and apply XML Schema validation to an input document if the schema is an XML Schema document, apply RELAX NG validation if the schema is a RELAX NG grammar, or perform no validation otherwise.

In order to ensure that the result of the choose is consistent irrespective of the subpipeline chosen, each subpipeline must declare the same number outputs with the same names. It is a static error if two subpipelines in a choose declare different outputs.

It is a dynamic error if no subpipeline is selected by the choose and no default is provided.

3.5 Group

A group step encapsulates the behavior of its subpipeline.

A group has no inputs.

A group is a convenience wrapper for a collection of steps. The result of a group is the result of its subpipeline.

3.6 Try/Catch

A try step isolates a subpipeline, preventing any errors that arise within it from being exposed to the rest of the pipeline.

A try has no inputs. It contains exactly two subpipelines: an initial subpipeline and a recovery (or “catch”) subpipeline.

The try step evaluates the initial subpipeline and, if no errors occur, the results of that pipeline are the results of the step. However, if any errors occur, it abandons the first subpipeline, discarding any output that it might have generated, and evaluates the recovery subpipeline.

If the recovery subpipeline is evaluated, the results of the recovery subpipeline are the results of the try step. If the recovery subpipeline is evaluated and a step within that subpipeline fails, the try fails.

For example, a pipeline might attempt to process a document by dispatching it to some web service. If the web service succeeds, then those results are passed to the rest of the pipeline. However, if the web service cannot be contacted or reports an error, the catch step can provide some sort of default for the rest of the pipeline.

In order to ensure that the result of the try is consistent irrespective of whether the initial subpipeline provides its output or the recovery subpipeline does, both subpipelines must declare the same number of outputs with the same names. It is a static error if the two subpipelines declare different outputs.

3.7 Other Steps

A pipeline document may contain additional types of steps. These can be implementation-defined or can be defined through some implementation-dependent extension mechanism. It is a static error if a pipeline contains a step that is not recognized by the processor.

The number of inputs, outputs, parameters, and contained steps that are possible on such a step are implementation-defined.

4.1 Scoping of Names

The scope of the names of step types is the pipeline. Each pipeline processor has some number of built in step types and may declare (directly, or by reference to an external library) additional step types.

The scope of the names of the steps themselves is determined by the environment of each step. In general, the name of a step, the names of its sibling steps, the names of any steps that it contains directly, the names of its ancestors; and the names of its ancestor's siblings are all in the same scope. All in-scope steps must have unique names: it is a static error if two steps with the same name appear in the same scope.

The scope of an input or output port name is the step on which it is defined. The names of all the ports on any step must be unique.

Taken together, these uniqueness constraints guarantee that the combination of a step name and a port name uniquely identifies exactly one port on exactly one in-scope step.

The scope of parameter names is essentially the same as the scope of step names, with the following caveat. Whereas step names must be unique, parameter names may be repeated. The declaration of a parameter on a step shadows any declaration that may already be in-scope.

4.2 Global Attributes

The following attributes may appear on any element in a pipeline:

The following attributes may appear on any step element:

4.3 Associating Documents with Ports

[Definition: A binding associates an input or output port with some data source.] A document or a sequence of documents can be bound to a port in three ways: by source, by URI, or by providing it inline. Each of these mechanisms is supported on the p:input, p:output, p:xpath-context, p:iteration-source, and p:viewport-source elements.

Note that an p:input or p:output element may contain more than one p:pipe, p:document, or p:inline element. If more than one binding is provided, then the specified sequence of documents is made available on that port.

4.4 Ignored namespaces

The element children of a compound step fall into four classes: elements that provide bindings for input and output ports, p:parameter elements that specify parameters, other elements that identify steps that are part of its subpipeline, and extension elements. Extension elements may be used for documentation or to provide additional information for a specific processor.

To determine which elements are extension elements and which are expected to identify steps, a set of ignored namespaces is maintained in the environment of each step.

The ignored namespaces are a set of namespaces which do not identify steps. They are ignored by the processor unless the processor happens to recognize one or more of them as extension elements. The initial set of ignored namespaces contains only a single namespace, the XHTML namespace, http://www.w3.org/1999/xhtml.

Syntactically, a pipeline author can add namespaces to the set of ignored namespaces with the p:ignore-prefixes attribute. This attribute can appear on any element in the pipeline namespace which identifies a step. It is a static error if the attribute appears on any element which does not identify a step.

The value of the p:ignore-prefixes attribute is a sequence of tokens, each of which must be the prefix of an in-scope namespace. It is a static error if any token specified in the ignore-prefixes attribute is not the prefix of an in-scope namespace.

Each of the namespaces identified by the specified prefix is added to the set of ignored namespaces in the environment of the step on which the attribute occurs.

4.5 Extension attributes

[Definition: An element from the XProc namespace may have any attribute not from the XProc namespace, provided that the expanded-QName of the attribute has a non-null namespace URI. These attributes are called extension attributes.] The presence of an extension attribute must not cause the connections between steps to differ from the connections that any other conformant XProc processor would produce. They must not cause the processor to fail to signal an error that a conformant processor is required to signal. This means that an extension attribute must not change the effect of any XProc element except to the extent that the effect is implementation-defined or implementation-dependent.

A processor which encounters an extension attribute that it does not recognize must behave as if the attribute was not present.

4.6 Extension elements

The presence of an extension element must not cause the connections between steps to differ from the connections that any other conformant XProc processor would produce. They must not cause the processor to fail to signal an error that a conformant processor is required to signal. This means that an extension element must not change the effect of any XProc element except to the extent that the effect is implementation-defined or implementation-dependent.

There are three contexts in which an extension element might occur:

5.1 p:pipeline Element

A p:pipeline represents a pipeline. Its children declare the inputs, outputs, and parameters that the pipeline exposes and identify the steps in its subpipeline.

<p:pipeline
  name? = QName
  p:ignore-prefixes? = prefix list>
   (p:input*,
    p:output*,
    p:parameter*,
    p:import*,
    p:declare-step*,
    subpipeline)
</p:pipeline>

If specified, the name must be unique across all available pipelines. If a p:pipeline occurs as the child of a p:pipeline-library element, it must be named.

A pipeline can declare additional steps (e.g., ones that are provided by a particular implementation or in some implementation-defined way) and import steps from libraries.

The environment of a pipeline step is the empty environment modified as follows:

The environment inherited by its contained steps is the environment of the pipeline.

If there is no binding for any of the declared outputs of the pipeline, then those outputs are bound to the default output port. It is a static error if an output is bound to the default output port and the default output port is undefined.

<p:pipeline name="buildspec">
  <p:input port="source"/>
  <p:input port="stylesheet"/>
  <p:output port="result"/>
  <p:parameter name="validate"/>
  …
</p:pipeline>

5.2 p:for-each Element

A p:for-each represents a for-each.

<p:for-each
  name = NCName
  select? = xpath expression
  p:ignore-prefixes? = prefix list>
   (p:iteration-source?,
    p:output*,
    p:parameter*,
    subpipeline)
</p:for-each>

The iteration-source is an anonymous input: its binding provides a sequence of documents to the for-each step. If no iteration sequence is explicitly provided, then the iteration source is read from the default input port.

A portion of each input document can be selected using the select attribute. If no selection is specified, the document node of each document is selected.

Each subtree selected by the p:for-each from each of the inputs that appear on the iteration source is wrapped in a document node and provided to the subpipeline.

The processor provides each document, one at a time, to the subpipeline represented by the children of the p:for-each on a port named current.

For each declared output, the processor collects all the documents that are produced for that output from all the iterations, in order, into a sequence. The result of the p:for-each on that output is that sequence of documents.

The environment of a for-each is its inherited environment modified as follows:

The environment inherited by its contained steps is the environment of the for-each modified as follows: the port named “current” is the default input port.

If there is no binding for any of the declared outputs of the for-each, then those outputs are bound to the default output port. It is a static error if an output is bound to the default output port and the default output port is undefined.

<p:for-each name="chapters" select="//chapter">
  <p:iteration-source>
    <p:document href="http://example.org/docbook.xml"/>
  </p:iteration-source>
  <p:output port="html">
    <p:pipe step="xform-to-html" port="result"/>
  </p:output>
  <p:output port="fo">
    <p:pipe step="xform-to-fo" port="result"/>
  </p:output>
  <p:xslt name="xform-to-fo">
    <p:input port="source">
      <p:pipe step="chapters" port="current"/>
    </p:input>
    <p:input port="stylesheet">
      <p:document href="fo/docbook.xsl"/>
    </p:input>
  </p:xslt>
  <p:xslt name="xform-to-html">
    <p:input port="source">
      <p:pipe step="chapters" port="current"/>
    </p:input>
    <p:input port="stylesheet">
      <p:document href="html/docbook.xsl"/>
    </p:input>
  </p:xslt>
</p:for-each>

5.3 p:viewport Element

A p:viewport represents a viewport.

<p:viewport
  name = NCName
  match = xpath expression
  p:ignore-prefixes? = prefix list>
   (p:viewport-source?,
    p:output,
    p:parameter*,
    subpipeline)
</p:viewport>

The viewport-source is an anonymous input: its binding provides a single document to the viewport step. If no document is explicitly provided, then the viewport source is read from the default input port.

The match attribute specifies an [XPath 1.0] expression that is a Pattern in [XSLT 1.0]. Each matching node in the source document is wrapped in a document node and provided to the viewport's subpipeline. After a node has been matched, its descendants are not considered for further matching. In other words, a node is passed at most once to the subpipeline.

The processor provides each document, one at a time, to the subpipeline represented by the children of the p:viewport on a port named current.

What appears on the output from the p:viewport will be a copy of the input document where each matching node is replaced by the result of applying the subpipeline to the subtree rooted at that node.

It is a dynamic error if the viewport source is a sequence of more than one document or if the output from any iteration is a sequence of more than one document.

The environment of a viewport is its inherited modified as follows:

The environment inherited by its contained steps is the environment of the viewport modified as follows: the port named “current” is the default input port.

If there is no binding for any of the declared outputs of the viewport, then those outputs are bound to the default output port. It is a static error if an output is bound to the default output port and the default output port is undefined.

<p:viewport name="encdivs" match="h:div[@class='enc']">
  <p:viewport-source>
    <p:pipe name="step" port="port"/>
  </p:viewport-source>
  <p:output port="result">
    <p:pipe name="encrypt" port="result"/>
  </p:output>
  <p:encrypt-document name="encrypt">
    <p:input port="source">
      <p:pipe name="encdivs" port="current"/>
    </p:input>
  </p:encrypt-document>
</p:viewport>

5.4 p:choose/p:when/p:otherwise Elements

A p:choose represents a choose.

<p:choose
  name = NCName
  p:ignore-prefixes? = prefix list>
   (p:xpath-context?,
    p:when*,
    p:otherwise?)
</p:choose>

The p:choose can specify the context node against which the [XPath 1.0] expressions that occur on each branch are evaluated. The context node is specified as a binding for the xpath-context. If no binding is provided, the default xpath-context is the document on the default input port.

It is a dynamic error if the xpath-context is bound to a sequence of documents.

The environment of a choose is its inherited environment modified as follows:

Each conditional subpipeline is represented by a p:when element.

<p:when
  test = expression
  p:ignore-prefixes? = prefix list>
   (p:xpath-context?,
    p:output*,
    p:parameter*,
    subpipeline)
</p:when>

Each p:when branch of the p:choose has a test attribute which must contain an [XPath 1.0] expression. That XPath expression's effective boolean value is the guard expression for the subpipeline contained within that p:when.

The p:when can specify a context node against which its test expression is to be evaluated. That context node is specified as a binding for the xpath-context. If no context is specified on the p:when, the context of the p:choose is used. It is a static error if no context is specified in either place and the default input port is undefined.

The default branch is represented by a p:otherwise element.

<p:otherwise>
   (p:output*,
    p:parameter*,
    subpipeline)
</p:otherwise>

All of the p:when branches and the p:otherwise must declare the same number of output ports with the same names. It is a static error if they do not.

The environment of the selected subpipeline is the environment of the choose modified as follows:

If there is no binding for any of the declared outputs of the selected subpipeline, then those outputs are bound to the default output port of the subpipeline. It is a static error if an output is bound to the default output port and the default output port is undefined.

<p:choose name="version">
  <p:xpath-context>
    <p:pipe step="prevstep" port="result"/>
  </p:xpath-context>

  <p:when test="/*[@version = 2]">
    <p:output port="result">
      <p:pipe step="v2valid" port="result"/>
    </p:output>

    <p:validate name="v2valid">
      <p:input port="source">
        <p:pipe step="prevstep" port="result"/>
      </p:input>
      <p:input port="schema">
        <p:document href="v2schema.xsd"/>
      </p:input>
    </p:validate>
  </p:when>

  <p:when test="/*[@version = 1]">
    <p:output port="result">
      <p:pipe step="v1valid" port="result"/>
    </p:output>

    <p:validate name="v2valid">
      <p:input port="source">
        <p:pipe step="prevstep" port="result"/>
      </p:input>
      <p:input port="schema">
        <p:document href="v1schema.xsd"/>
      </p:input>
    </p:validate>
  </p:when>

  <p:otherwise>
    <p:output port="result">
      <p:pipe step="ident" port="result"/>
    </p:output>

    <p:identity name="ident">
      <p:input port="source">
        <p:pipe step="prevstep" port="result"/>
      </p:input>
    </p:identity>
  </p:otherwise>
</p:choose>

5.5 p:group Element

A p:group is a wrapper for a subpipeline.

<p:group
  name = NCName
  p:ignore-prefixes? = prefix list>
   (p:output*,
    p:parameter*,
    subpipeline)
</p:group>

The environment of a group is its inherited modified as follows:

The environment inherited by its contained steps is the environment of the group.

If there is no binding for any of the declared outputs of the group then those outputs are bound to the default output port of the subpipeline. It is a static error if an output is bound to the default output port and the default output port is undefined.

5.6 p:try/p:catch Elements

A p:try represents a try/catch.

<p:try
  name = NCName
  p:ignore-prefixes? = prefix list>
   (p:group,
    p:catch)
</p:try>

Where the p:group represents the initial subpipeline and the recovery (or “catch”) pipeline is identified with a p:catch element.

The environment of the try is its inherited environment modified as follows:

The environment inherited by its initial subpipeline is the environment of the try modified as follows:

The recovery subpipeline of a try is identified with a p:catch:

<p:catch
  name = NCName
  p:ignore-prefixes? = prefix list>
   (p:output*,
    p:parameter*,
    subpipeline)
</p:catch>

Both the p:group and the p:catch must declare the same number of output ports with the same names. It is a static error if they do not.

The environment of the recovery subpipeline is the environment of the try modified as follows:

5.7 Other Steps

Any element in a subpipeline that is not in an ignored namespace identifies a step.

<pfx:otherComponent
  name = NCName
  p:ignore-prefixes? = prefix list>
   (p:input*,
    p:output*,
    p:import-parameter*,
    p:parameter*,
    subpipeline?)
</pfx:otherComponent>

The qualified name of the element identifies the type of step to be instantiated. It is a static error if no step of that type has been imported or declared.

It is a static error if the name is not unique in the current scope or if the specified inputs, outputs, and parameters do not match the signature for steps of that type.

The environment of a step is its inherited environment modified as follows:

6.1 p:input Element

A p:input identifies input for a step, optionally declaring it, if necessary.

<p:input
  port = QName
  sequence? = yes|no />

The port attribute defines the name of the port. It is a static error to identify two ports with the same name on the same step. It is a static error if the port given does not match the name of an input port specified in the step's declaration.

On compound steps and p:declare-step, an input declaration can indicate if a sequence of documents is allowed to appear on the port. If sequence is specified with the value “yes”, then a sequence is allowed. If sequence is not specified, or has the value “no”, then it is a dynamic error for a sequence of more than one document to appear on the declared port.

The declaration may be accompanied by a binding (or default binding) for the input:

<p:input
  port = QName
  sequence? = yes|no
  select? = xpath expression>
   (p:pipe |
    p:document |
    p:inline)*
</p:input>

If a binding is provided, a select expression may also be provided. The select expression, if specified, applies the specified [XPath 1.0] select expression to the document(s) that are read. Each node that matches is wrapped in a document and provided to the input port. After a node has been matched, its descendants are not considered for further matching; a node is passed at most once as input. In other words,

<p:input port="source">
  <p:document href="http://example.org/input.html"/>
</p:input>

provides a single document, but

<p:input port="source" select="//html:div">
  <p:document href="http://example.org/input.html"/>
</p:input>

provides a sequence of zero or more documents, one for each matching html:div (that is not itself a descendant of an html:div) in http://example.org/input.html.

A select expression can equally be applied to input read from another step. This input:

<p:input port="source" select="//html:div">
  <p:pipe step="origin" port="result"/>
</p:input>

provides a sequence of zero or more documents, one for each matching html:div in the document (or each of the documents) that is read from the portname port of the step named origin.

On a compound step, a p:pipe in a p:input can not access the readable ports of the step's contained steps.

6.2 p:iteration-source Element

A p:iteration-source identifies input to a for-each.

<p:iteration-source
  select? = xpath expression>
   (p:pipe |
    p:document |
    p:inline)*
</p:iteration-source>

The select attribute and binding elements of a p:iteration-source work the same way that they do in a p:input.

6.3 p:viewport-source Element

A p:viewport-source identifies input to a viewport.

<p:viewport-source>
   (p:pipe |
    p:document |
    p:inline)
</p:viewport-source>

Exactly one binding element is allowed and it works the same way that binding elements work in a p:input. No select expression is allowed.

6.4 p:xpath-context Element

A p:xpath-context identifies a context against which an [XPath 1.0] expression will be evaluated for a p:when.

<p:xpath-context>
   (p:pipe |
    p:document |
    p:inline)
</p:xpath-context>

Exactly one binding element is allowed and it works the same way that binding elements work in a p:input. No select expression is allowed.

6.5 p:output Element

A p:output identifies an output port, optionally declaring it, if necessary.

<p:output
  port = QName
  sequence? = yes|no
  default? = yes|no />

The port attribute defines the name of the port. It is a static error to identify two ports with the same name on the same step. It is a static error if the port given does not match the name of an output port specified in the step's declaration.

An output declaration can indicate if a sequence of documents is allowed to appear on the declared port. If sequence is specified with the value “yes”, then a sequence is allowed. If sequence is not specified, or has the value “no”, then it is a dynamic error if the step produces a sequence of more than one document on the declared port.

An output declaration can indicate if it is to be considered the default output for the step. If default is specified with the value “yes”, then the named port will be treated as the default output port. It is a static error to identify two different ports as the default. It is also a static error if the step on which this declaration appears has exactly one output and that output is marked as not being the default. In other words, if any step or step has exactly one output, that output is always the default output.

The declaration may be accompanied by a binding for the output.

<p:output
  port = QName
  sequence? = yes|no
  default? = yes|no>
   (p:pipe |
    p:document |
    p:inline)*
</p:output>

On a compound step, a p:pipe in a p:output can only access the readable ports of the step's contained steps.

6.6 p:parameter Element

The p:parameter element is used both to declare parameters and to establish values for them. When used on a p:declare-step or compound step, p:parameter declares the parameter and may associate a default value with it. Used elsewhere, p:parameter associates a value with the parameter.

6.7 p:import-parameter Element

An p:import-parameter provides a set of in-scope parameters to a step.

<p:import-parameter
  name = token />

All in-scope parameters which match the name are made available to the step as if they had been specified with individual p:parameter elements.

The name attribute must be a single asterisk (*), a QName, or a string of the form *:NCName or NCName:*.

6.8 p:declare-step Element

A p:declare-step provides the type and signature of an implementation-dependent type of step. It declares the inputs, outputs, and parameters for all steps of that type.

<p:declare-step
  type = QName>
   (p:input*,
    p:output*,
    p:parameter*)
</p:declare-step>

It is a static error to identify an unrecognized step in a subpipeline. It is not an error to declare such a step, only to use it.

Exactly one input declaration of a p:declare-step may use the name “*” to indicate that the step accepts an arbitrary number of inputs.

Exactly one output declaration of a p:declare-step may use the name “*” to indicate that the step can produce an arbitrary number of outputs.

6.9 p:pipeline-library Element

A p:pipeline-library is a collection of step declarations and/or pipeline definitions.

<p:pipeline-library>
   (p:import*,
    p:declare-step*,
    p:pipeline*)
</p:pipeline-library>

It is a static error if the import references in a pipeline or pipeline library are circular.

<p:pipeline-library>
  <p:declare-step type="my:extension-component">…</p:declare-step>
  <p:pipeline name="xinclude-and-validate">…</p:pipeline>
  <p:pipeline name="validate-and-transform">…</p:pipeline>
  …
</p:pipeline-library>

6.10 p:import Element

An p:import loads a pipeline or pipeline library, making it available in the current environment.

<p:import
  href = URI />

An import statement loads the specified URI and makes any pipelines declared within it available to the current pipeline.

It is a dynamic error if the URI cannot be retrieved or if, once retrieved, it does not point to a p:pipeline-library or p:pipeline. If it points to a p:pipeline, it is a dynamic error if the pipeline does not have a name.

6.11 p:pipe Element

A p:pipe reads from the output port of another step.

<p:pipe
  step = step-name
  port = port-name />

The p:pipe element identifies the output port of another step with the name of the step in the step attribute and the name of the port on that step in the port attribute. It is a static error if the port identified is not in the readable ports of the environment.

6.12 p:inline Element

A p:inline provides a document or a sequence of documents inline.

<p:inline>
   anyElement?
</p:inline>

The content of the p:inline element is wrapped in a document node and passed as input. The base URI of the document is the base URI of the p:inline element.

It is a static error if the content of the p:inline element is not a well-formed XML document.

6.13 p:document Element

A p:document reads an XML document from a URI.

<p:document
  href = URI />

The document identified by the URI in the href attribute is loaded and returned.

It is a dynamic error if the document does not exist, cannot be accessed, or is not a well-formed XML document.

The parser which the p:document element employs must be conformant Namespaces in XML. It must not perform validation. It must not perform any other processing, such as expanding XIncludes.

Use the load step if you need to perform DTD-based validation or if you wish to load documents that are not namespace well-formed.

7.1 Static Errors

[Definition: A static error is one which can be detected before pipeline evaluation is even attempted.] Examples of static errors include cycles, incorrect specification of inputs and outputs, and reference to unknown steps.

Static errors are fatal and must be detected before any steps are evaluated.

7.2 Dynamic Errors

A [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space).

If a step fails due to a dynamic error, failure propagates upwards until either a try is encountered or the entire pipeline fails. In other words, outside of a try, step failure causes the entire pipeline to fail.