XProc: An XML Pipeline Language

2.1 Steps

[Definition: A step is the basic computational unit of a pipeline.] All steps have a name; if the pipeline author does not provide a name for a step, a default name is manufactured automatically.

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, and has no internal subpipeline.] Atomic steps carry out fundamental XML operations and can perform arbitrary amounts of computation, but they are indivisible. 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.

There are many types of atomic steps. The standard library of atomic steps is described in Section 7, “Standard Step Library”, but implementations may provide others as well. What additional step types, if any, are provided is implementation defined. Each use, or instance, of an atomic step invokes the processing defined by that type of step. A pipeline may contain instances of many types of steps and many instances of the same type of step.

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 one or more subpipelines. 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 one or more subpipelines. [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.]

This simple distinction between atomic and compound steps is occasionally stretched. The immediate children of some compound steps, e.g. p:choose and p:try, are special. In the case of p:choose, the p:when and p:otherwise elements serve as wrappers around different pipelines at most one of which will be processed. In the case of p:try, the p:catch element is a wrapper around a subpipeline that will only be processed if the initial p:group fails. Acknowledging this slight irregularity, we nevertheless treat all compound steps as if they directly contained one or more subpipelines.

[Definition: The steps (and the connections between them) within a compound step form a subpipeline.] [Definition: The last step in a subpipeline is the last step in document order within its container. ]

subpipeline = (p:for-each|p:viewport|p:choose|p:group|p:try|pfx:other-step|p:documentation|ipfx:ignored)*

A compound step can contain one or more subpipelines and it determines how and which of its subpipelines are evaluated.

Steps have “ports” into which inputs and outputs are connected or “bound”. Each step has a number of input ports and a number of output ports; a step can have zero input ports and/or zero output ports. (All steps have an implicit output port for reporting errors that must not be declared.) The names of all ports on each step must be unique on that step (you can't have two input ports named “source”, nor can you have an input port named “schema” and an output port named “schema”).

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

Steps have parameter input ports, on which parameters can be passed. The parameters passed on a particular parameter input port must be uniquely named. If multiple parameters with the same name are used, only one of the values will actually be available to the step. A step can have zero parameter input ports, and each parameter port can have zero parameters passed on it.

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 (err:XD0001) 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 to a URI—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.

The common case is that each step has one or more inputs and one or more outputs. Figure 3, “An atomic step” illustrates symbolically an atomic step with two inputs and one output.

Figure 3. An atomic step

All atomic steps are defined by a p:declare-step. The declaration of an atomic step defines the input ports, output ports, and options of all steps of that type. For example, every p:xslt step has two inputs, named “source” and “stylesheet”, and one output named “result” and the same set of options.

The situation is slightly more complicated for compound steps because they don't have separate declarations; each instance of a compound step serves as its own declaration. Compound steps don't have declared inputs, but they do have declared outputs, and unlike atomic steps, on compound steps, the number and names of the outputs can be different on each instance of the step.

Figure 4, “A compound step” illustrates symbolically a compound step with one output. As you can see from the diagram, the output from the compound step comes from one of the outputs of the subpipeline within the step.

Figure 4. A compound step

[Definition: The input ports declared on a step are its declared inputs.] [Definition: The output ports declared on a step are its declared outputs.] When a step is used in a pipeline, it is connected to other steps through its inputs and outputs.

When a step is used, all of the declared inputs of the step must be connected. Each input can be connected to:

When an input accepts a sequence of documents, the documents can come from any combination of these locations.

The declared outputs of a step may be connected to:

The primary output port of a step must be connected, but other outputs can remain unconnected. Any documents produced on an unconnected output port are discarded.

Output ports on compound steps have a dual nature: from the perspective of the compound step's siblings, its outputs are just ordinary outputs and must be connected as described above. From the perspective of the compound step itself, they are inputs into which something must be connected.

Within a compound step, the declared outputs of the step can be connected to:

Each input and output is declared to accept or produce either a single document or a sequence of documents. It is not an 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, an error if the former step actually produces more than one document at run time.

[Definition: The signature of a step is the set of inputs, outputs, and options 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 implicit signature.

[Definition: A step matches its signature if and only if it specifies an input for each declared input, it specifies no inputs that are not declared, it specifies an option for each option that is declared to be required, and it specifies no options that are not declared.] In other words, every input and required option must be specified and only inputs and options that are declared may be specified. Options that aren't required do not have to be specified.

Steps may also produce error, warning, and informative messages. These messages appear on a special “error output” port. The error output port is only bound to an input in the catch clause of a try/catch. Outside of a try/catch, the disposition of error messages is implementation-dependent.

2.3 Primary Inputs and Outputs

As a convenience for pipeline authors, each step may have one input port designated as the primary input port and one output port designated as the primary output port.

[Definition: If a step has a document input port which is explicitly marked “primary='true'”, or if it has exactly one document input port and that port is not explicitly marked “primary='false'”, then that input port is the primary input port of the step.] If a step has a single input port and that port is explicitly marked “primary='false'”, or if a step has more than one input port and none is explicitly marked as the primary, then the primary input port of that step is undefined.

[Definition: If a step has a document output port which is explicitly marked “primary='true'”, or if it has exactly one document output port and that port is not explicitly marked “primary='false'”, then that output port is the primary output port of the step.] If a step has a single output port and that port is explicitly marked “primary='false'”, or if a step has more than one output port and none is explicitly marked as the primary, then the primary output port of that step is undefined.

The special significance of primary input and output ports is that they are connected automatically by the processor if no explicit binding is given. Generally speaking, if two steps appear sequentially in a subpipeline, then the primary output of the first step will automatically be connected to the primary input of the second.

Additionally, if a p:pipeline has no declared inputs and the first step in its subpipeline has an unbound primary input, then an implicit primary input port (named “source”) will be added to the p:pipeline (and consequently bound to the first step's primary input port). If a compound step has no declared outputs and the last step in its subpipeline has an unbound primary output, then an implicit primary output port (named “result”) will be added to the compound step (and consequently the last step's primary output will be bound to it).

The practical consequence of these rules is that straightforward, linear pipelines are much simpler to read, write, and understand. The following pipeline has a single input which is transformed by the XSLT step; the result of that XSLT step is the result of the pipeline:

<p:pipeline xmlns:p="http://www.w3.org/2007/03/xproc">
<p:xslt>
  <p:input port="stylesheet">
    <p:document href="docbook.xsl"/>
  </p:input>
</p:xslt>
</p:pipeline>

It is semantically equivalent to this pipeline:

<p:pipeline name="main" xmlns:p="http://www.w3.org/2007/03/xproc">
<p:input port="source"/>
<p:input port="parameters" kind="parameter"/>
<p:output port="result">
  <p:pipe step="transform" port="result"/>
</p:output>

<p:xslt name="transform">
  <p:input port="source">
    <p:pipe step="main" port="source"/>
  </p:input>
  <p:input port="stylesheet">
    <p:document href="docbook.xsl"/>
  </p:input>
  <p:input port="parameters">
    <p:pipe step="main" port="parameters"/>
  </p:input>
</p:xslt>

</p:pipeline>

(Parameter input ports are a special case discussed in Section 2.5, “Parameters”.)

2.4 Options

Some steps accept options. Options are name/value pairs.

[Definition: An option is a name/value pair where the name is an expanded name and the value 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 options declared on a step are its declared options.] All of the options specified on an atomic step must have been declared. Option names are always expressed as literal values, pipelines cannot construct option names dynamically.

[Definition: The options on a step which have specified values, either because a p:option element specifies a value or because the declaration included a default value, are its specified options.]

2.5 Parameters

Some steps accept parameters. Parameters are name/value pairs.

[Definition: A parameter is a name/value pair where the name is an expanded name and the value 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.

Unlike options, which have names known in advance to the pipeline, parameters are not declared and their names may be unknown to the pipeline author. Pipelines can dynamically construct sets of parameters. Steps can read dynamically constructed sets on parameter input ports.

[Definition: A parameter input port is a distinguished kind of input port which accepts (only) dynamically constructed parameter name/value pairs.] See Section 5.1.2, “Parameter Inputs”.

Analogous to primary input ports, steps that have parameter inputs may designate at most one parameter input port as a primary parameter input port.

[Definition: If a step has a parameter input port which is explicitly marked “primary='true'”, or if it has exactly one parameter input port and that port is not explicitly marked “primary='false'”, then that parameter input port is the primary parameter input port of the step.] If a step has a single parameter input port and that port is explicitly marked “primary='false'”, or if a step has more than one parameter input port and none is explicitly marked as the primary, then the primary parameter input port of that step is undefined.

Additionally, if a p:pipeline does not declare any parameter input ports, but contains a step which has a primary parameter input port, then an implicit primary parameter input port (named “parameters”) will be added to the pipeline. (If the pipeline declares an ordinary input named “parameters”, the implicit primary parameter input port will be named “parameters1”. If that's not available, then “parameters2”, etc. until an available name is found.)

How an implementation maps parameters specified to the application, or through some API, to parameters accepted by the p:pipeline is implementation-defined.

2.6 Connections

Steps are connected together by their input ports and output ports. It is a static error (err:XS0001) 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.7 Environment

[Definition: The environment of a step is the static information available to each instance of a step in a pipeline.]

The environment consists of:

[Definition: The empty environment contains no readable ports, no in-scope options, and an undefined default readable port. ]

Unless otherwise specified, the environment of a contained step is its inherited environment. [Definition: The inherited environment of a contained step is an environment that is the same as the environment of its container with the standard modifications. ]

The standard modifications made to an inherited environment are:

A step with no parent inherits the empty environment.

2.8 XPath Context

XProc uses [XPath 1.0] as an expression language. XPath expressions can occur in several places: on compound steps, in the expressions used to compute option and parameter values, and in values passed to atomic steps.

Broadly, these can be divided into two classes: expressions evaluated by the XProc processor and expressions evaluated by the implementations of individual steps.

This distinction can be seen in the following example:

<p:option name="home" value="http://example.com/docs"/>

<p:load name="read-from-home">
  <p:option name="href" select="concat($home,'/document.xml')"/>
</p:load>

<p:split-sequence name="select-chapters">
  <p:input port="source" select="//section"/>
  <p:option name="test" value="@role='chapter'"/>
</p:split-sequence>

The href option of the p:load step step is evaluated by the XProc processor. The actual href option received by the step is simply the string literal “http://example.com/docs/document.xml”. (The selection on the source input of the select-chapters step is also evaluated by the XProc processor.)

Conversely, the XPath expression “@role='chapter'” is passed literally to the test option on the p:split-sequence step. That's because the nature of the p:split-sequence is that it evaluates the expression. Only some options on some steps expect XPath expressions.

The XProc processor evaluates all of the XPath expressions in select attributes on steps, options, parameters, and inputs and in test attributes on p:when steps. (XPath expressions in value attributes are passed literally to the step for evaluation.)

3.1 XProc Namespaces

The XML syntax for XProc uses three namespaces:

3.2 Scoping of Names

The scope of the names of the step types is the union of all the pipelines and pipeline libraries available directly or via p:import.

Step types are:

All the step types in a pipeline must have unique names: it is a static error (err:XS0036) if any step type name is built-in and/or declared or defined more than once in the same scope.

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 the named steps in the same scope must have unique names: it is a static error (err:XS0002) 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 option names is the step on which they occur and the descendants of that step. The names of all of the options specified on a step must be unique. If a step specifies a value for an option with the same name as some option specified on one of its ancestors, the new value shadows the previous value on the current step and its descendants.

Parameter names are not scoped; they are distinct on each step.

3.3 Global Attributes

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

3.4 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 four ways: by source, by URI, by providing an inline document, or by making it explicitly empty. Each of these mechanisms is allowed on the p:input, p:output, p:xpath-context, p:iteration-source, and p:viewport-source elements.

Note that a 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 in the same order as the bindings.

3.5 Documentation

Pipeline authors may add documentation to their pipeline documents with the p:documentation element. Except when it appears as a descendant of p:inline, the p:documentation element is completely ignored by pipeline processors, it exists simply for documentation purposes. (If a p:documentation is provided as a descendant of p:inline, it has no special semantics, it is treated literally as part of the document to be provided on that port.)

Pipeline processors that inspect the contents of p:documentation elements and behave differently on the basis of what they find are not conformant. Processor extensions must be specified with extension elements.

3.6 Ignored namespaces

In order to facilitate extension elements, the processor can be instructed to ignore elements from selected namespaces. [Definition: Any element in an ignored namespace is an ignorable element.]

If a processor encounters an ignorable element as the child of a p:pipeline or p:pipeline-library then it behaves in an implementation-defined manner if it recognizes the element, otherwise it must behave as if the element (and its content) had not been present.

Syntactically, a pipeline author can specify the set of ignored namespaces with the ignore-prefixes attribute. This attribute can appear on the p:pipeline and p:pipeline-library elements.

The value of the 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 (err:XS0005) if any token specified in the prefix list is not the prefix of an in-scope namespace.

Ignored namespaces specified on a p:pipeline-library are inherited by pipelines that occur within that library.

It is a static error (err:XS0015) to specify as an ignored namespace the XProc namespace, the namespace of any imported p:pipeline, or any namespace in which an atomic step is declared.

3.7 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. Such an attribute is called an extension attribute.] Extension attributes are always allowed and do not have to be declared with ignored namespaces.

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.

3.8 Extension elements

[Definition: An extension element is any element that is not in the XProc namespace and is not a step.] 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.

An element is only an extension element if it is an ignorable element that occurs as a direct child of a p:pipeline or p:pipeline-library.

In other words, elements in a subpipeline are interpreted as follows:

3.9 Syntax Summaries

The description of each element in the pipeline namespace is accompanied by a syntactic summary that provides a quick overview of the element's syntax:

<p:some-element
  some-attribute? = some-type>
    (some |
     elements |
     allowed)*,
    other-elements?
</p:some-element>

For clarity of exposition, some attributes and elements are elided from the summaries:

[Definition: In the context of XProc, a QName is almost always a QName in the Namespaces in XML sense. Note, however, that p:option and p:parameter values can get their namespace declarations in a non-standard way (with p:namespaces) and QNames that have no prefix are always in no-namespace, irrespective of the default namespace.]

A number of errors apply generally:

If an XProc processor can determine statically that a dynamic error will always occur, it may report that error statically.

4.1 p:pipeline

A pipeline is specified by the p:pipeline element. It encapsulates the behavior of a subpipeline. Its children declare the inputs, outputs, and options that the pipeline exposes and identify the steps in its subpipeline.

A pipeline can declare additional steps (e.g., ones that are provided by a particular implementation or in some implementation-defined way) and import other pipelines. If a pipeline has been imported, it may be invoked as a step within the pipeline that imported it.

<p:pipeline
  name? = NCName
  type? = QName
  ignore-prefixes? = prefix list>
    (p:input |
     p:output |
     p:option |
     p:import |
     p:declare-step |
     p:log |
     p:serialization)*,
    subpipeline
</p:pipeline>

Viewed from the outside, a p: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.

The environment inherited by the contained steps of a p:pipeline is the empty environment with these modifications:

If the p:pipeline has a primary output port and that port has no binding, then it is bound to the primary output port of the last step in the subpipeline. It is a static error (err:XS0006) if the primary output port has no binding and the last step in the subpipeline does not have a primary output port.

There are two additional constraints on pipelines:

If the pipeline initially invoked by the processor has inputs or outputs, those ports are bound to documents outside of the pipeline in an implementation-defined manner.

If a pipeline has a type then that type may be used as the name of a step to invoke the pipeline. This most often occurs when the it has been imported into another pipeline, but pipelines may also invoke themselves recursively. If it does not have a type, then its name is used to invoke it as a step.

For pipelines that are part of a p:pipeline-library, see Section 5.9, “p:pipeline-library Element” for more details on how p:pipeline names are used to compute step names.

<p:pipeline name="pipeline" xmlns:p="http://www.w3.org/2007/03/xproc">
<p:input port="document" primary="true"/>
<p:input port="stylesheet"/>
<p:output port="result" primary="true"/>

<p:xinclude/>

<p:validate-xml-schema>
  <p:input port="schema">
    <p:document href="http://example.com/path/to/schema.xsd"/>
  </p:input>
</p:validate-xml-schema>

<p:xslt>
  <p:input port="stylesheet">
    <p:pipe step="pipeline" port="stylesheet"/>
  </p:input>
</p:xslt>

</p:pipeline>

4.2 p:for-each

A for-each is specified by the p:for-each element. It processes a sequence of documents, applying its subpipeline to each document in turn.

<p:for-each
  name? = NCName>
    (p:iteration-source?,
     (p:output |
      p:option |
      p:log)*,
     subpipeline)
</p:for-each>

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

The result of the p:for-each is a sequence of documents produced by processing each individual document in the input sequence. If the p:for-each has one or more output ports, what appears on each of those ports is the sequence of documents that is the concatenation of the sequence produced by each iteration of the loop on the port to which it is connected.

The p:iteration-source is an anonymous input: its binding provides a sequence of documents to the p:for-each step. If no iteration sequence is explicitly provided, then the iteration source is read from the default readable 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 inherited by the contained steps of a p:for-each is the inherited environment with these modifications:

If the p:for-each has a primary output port and that port has no binding, then it is bound to the primary output port of the last step in the subpipeline. It is a static error (err:XS0006) if the primary output port has no binding and the last step in the subpipeline does not have a primary output port.

<p:for-each name="chapters">
  <p:iteration-source select="//chapter"/>
  <p:output port="html-results">
    <p:pipe step="make-html" port="result"/>
  </p:output>
  <p:output port="fo-results">
    <p:pipe step="make-fo" port="result"/>
  </p:output>

  <p:xslt name="make-html">
    <p:input port="stylesheet">
      <p:document href="http://example.com/xsl/html.xsl"/>
    </p:input>
  </p:xslt>

  <p:xslt name="make-fo">
    <p:input port="source">
      <p:pipe step="chapters" port="current"/>
    </p:input>
    <p:input port="stylesheet">
      <p:document href="http://example.com/xsl/fo.xsl"/>
    </p:input>
  </p:xslt>
</p:for-each>

4.3 p:viewport

A viewport is specified by the p:viewport element. It processes a single document, applying its subpipeline to one or more subsections of the document.

<p:viewport
  name? = NCName
  match = XSLT Match pattern>
    ((p:viewport-source?,
      p:output?,
      p:log?,
      p:option*),
     subpipeline)
</p:viewport>

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

The p:viewport-source is an anonymous input: its binding provides a single document to the p:viewport step. If no document is explicitly provided, then the viewport source is read from the default readable 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.

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 (err:XD0003) if the viewport source does not provide exactly one document.

The environment inherited by the contained steps of a p:viewport is the inherited environment with these modifications:

If the p:viewport has a primary output port and that port has no binding, then it is bound to the primary output port of the last step in the subpipeline. It is a static error (err:XS0006) if the primary output port has no binding and the last step in the subpipeline does not have a primary output port.

<p:viewport match="h:div[@class='chapter']"
            xmlns:h="http://www.w3.org/1999/xhtml">
  <p:insert at-start="true">
    <p:input port="insertion">
      <p:inline>
        <hr xmlns="http://www.w3.org/1999/xhtml"/>
      </p:inline>
    </p:input>
  </p:insert>
</p:viewport>

</p:pipeline>

4.4 p:choose

A choose is specified by the p:choose element. It selects exactly one of a list of alternative subpipelines based on the evaluation of [XPath 1.0] expressions.

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

A p: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 guarded by an XPath expression, followed optionally by a single default subpipeline.

The p: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 p:choose is the result of the selected subpipeline.

In order to ensure that the result of the p:choose is consistent irrespective of the subpipeline chosen, each subpipeline must declare the same number of outputs with the same names. If any of the subpipelines specifies a primary output port, each subpipeline must specify exactly the same output as primary. It is a static error (err:XS0007) if two subpipelines in a p:choose declare different outputs.

It is a dynamic error (err:XD0004) if no subpipeline is selected by the p:choose and no default is provided.

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 p:xpath-context. If no binding is provided, the default p:xpath-context is the document on the default readable port.

Each conditional subpipeline is represented by a p:when element. The default branch is represented by a p:otherwise element.

<p:choose name="version">
  <p:when test="/*[@version = 2]">
    <p:validate-xml-schema>
      <p:input port="schema">
	<p:document href="v2schema.xsd"/>
      </p:input>
    </p:validate-xml-schema>
  </p:when>

  <p:when test="/*[@version = 1]">
    <p:validate-xml-schema>
      <p:input port="schema">
	<p:document href="v1schema.xsd"/>
      </p:input>
    </p:validate-xml-schema>
  </p:when>

  <p:when test="/*[@version]">
    <p:identity/>
  </p:when>

  <p:otherwise>
    <p:output port="result">
      <!-- this output is necessary so that all the branches have
           the same outputs; it'll never really matter because
	   we're just about to raise an error. -->
      <p:inline>
	<nop/>
      </p:inline>
    </p:output>
    <p:error code="NOVERSION"
	     description="Required version attribute missing."/>
  </p:otherwise>
</p:choose>

4.5 p:group

A group is specified by the p:group element. It encapsulates the behavior of its subpipeline.

<p:group
  name? = NCName>
    ((p:output |
      p:option |
      p:log)*,
     subpipeline)
</p:group>

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

<p:group>
  <p:option name="db-key" value="some-long-string-of-nearly-random-characters"/>

  <p:choose>
    <p:when test="/config/output = 'fo'">
      <p:xslt>
	<p:parameter name="key" select="$db-key"/>
	<p:input port="stylesheet">
	  <p:document href="fo.xsl"/>
	</p:input>
      </p:xslt>
    </p:when>
    <p:when test="/config/output = 'svg'">
      <p:xslt>
	<p:parameter name="key" select="$db-key"/>
	<p:input port="stylesheet">
	  <p:document href="svg.xsl"/>
	</p:input>
      </p:xslt>
    </p:when>
    <p:otherwise>
      <p:xslt>
	<p:parameter name="key" select="$db-key"/>
	<p:input port="stylesheet">
	  <p:document href="html.xsl"/>
	</p:input>
      </p:xslt>
    </p:otherwise>
  </p:choose>
</p:group>

4.6 p:try/p:catch

A try/catch is specified by the p:try element. It isolates a subpipeline, preventing any dynamic errors that arise within it from being exposed to the rest of the pipeline.

<p:try
  name? = NCName>
    (p:group,
     p:catch)
</p:try>

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

The p: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 p:try step. If the recovery subpipeline is evaluated and a step within that subpipeline fails, the p:try fails.

A pipeline author can cause an error to occur with the p:error step.

In order to ensure that the result of the p: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. If either of the subpipelines specifies a primary output port, both subpipelines must specify exactly the same output as primary. It is a static error (err:XS0009) if the p:group and p:catch subpipelines declare different outputs.

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

<p:catch
  name? = NCName>
    ((p:output |
      p:option |
      p:log)*,
     subpipeline)
</p:catch>

The environment inherited by the contained steps of the p:catch is the inherited environment with this modification:

What appears on the error port is an error document. The error document may contain messages generated by steps that were part of the initial subpipeline. Not all messages that appear are indicative of errors; for example, it is common for all xsl:message output from the XSLT component to appear on the error port. It is possible that the component which fails may not produce any messages at all. It is also possible that the failure of one component may cause others to fail so that there may be multiple failure messages in the document.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="1.0">

<xsl:template match="/">
  <xsl:message terminate="yes">
    <xsl:text>This stylesheet is </xsl:text>
    <emph>pointless</emph>
    <xsl:text>.</xsl:text>
  </xsl:message>
</xsl:template>

</xsl:stylesheet>

<c:errors xmlns:c="http://www.w3.org/2007/03/xproc-step">
  <c:error name="xform" type="p:xslt"
             href="style.xsl" line="6">This stylesheet is <emph>pointless</emph>.</c:error>
</c:errors>

<p:try>
  <p:group>
    <p:http-request>
      <p:input port="source">
	<p:inline>
	  <c:http-request method="post" href="http://example.com/form-action">
	    <c:entity-body content-type="application/x-www-form-urlencoded">
	      <c:body>name=W3C&amp;spec=XProc</c:body>
	    </c:entity-body>
	  </c:http-request>
	</p:inline>
      </p:input>
    </p:http-request>
  </p:group>
  <p:catch>
    <p:identity>
      <p:input port="source">
	<p:inline>
	  <c:error>HTTP Request Failed</c:error>
	</p:inline>
      </p:input>
    </p:identity>
  </p:catch>
</p:try>

4.7 Other Steps

Other steps are specified by elements that occur as contained steps and are not in any of the the ignored namespaces. For example, other atomic steps:

<pfx:other-atomic-step
  name? = NCName>
    (p:input |
     p:option |
     p:parameter |
     p:log)*
</pfx:other-atomic-step>

Each atomic step must be the name of a p:pipeline type or must have been declared with a p:declare-step that appears in the pipeline, or an imported library, before it is used. Pipelines can refer to themselves (recursion is allowed), to pipelines defined in imported libraries, and to other pipelines in the same library if they are in a library.

If the step element name is the same as the type of a step declared with p:declare-step, then that step invokes the declared step.

If the step element name is the same as the type or name of a p:pipeline, then that step runs the pipeline identified by that type or name.

The presence of other compound steps is implementation defined; XProc provides no standard mechanism for defining them or describing what they can contain.

It is a static error (err:XS0010) if a pipeline contains a step whose specified inputs, outputs, and options do not match the signature for steps of that type.

It is a dynamic error (err:XD0017) if the running pipeline attempts to invoke a step which the processor does not know how to perform.

<ex:stepType>
  <p:option name="option-name" value="5"/>
</ex:stepType>

<ex:stepType option-name="5"/>

5.1 p:input Element

A p:input identifies an input port for a step. In some contexts, p:input declares that a port with the specified name exists and identifies the properties of that port. In other contexts, it provides a binding for a port with a specified name (in which case it must have been declared elsewhere). In some contexts, it does both. The semantics of p:input are complicated further by the fact that there are two kinds of inputs, ordinary “document” inputs and “parameter” inputs.

On a p:declare-step, the p:input element is only a declaration. On a p:pipeline, it is both a declaration and a binding. In other contexts, it is only a binding.

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

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

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

<p:pipeline name="main"
	    xmlns:p="http://www.w3.org/2007/03/xproc"
	    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<p:input port="source"/>
<p:input port="parameters" kind="parameter"/>
<p:output port="result"/>

<p:xslt>
  <p:input port="source">
    <p:pipe step="main" port="source"/>
  </p:input>
  <p:input port="stylesheet">
    <p:document href="http://example.com/stylesheets/doc.xsl"/>
  </p:input>
  <p:parameter name="output-type" value="html"/>
  <p:input port="parameters">
    <p:pipe step="main" port="parameters"/>
  </p:input>
</p:xslt>

</p:pipeline>

5.2 p:iteration-source Element

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

<p:iteration-source
  select? = XPath expression>
    (p:empty |
     (p:pipe |
      p:document |
      p:inline)+)?
</p:iteration-source>

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

5.3 p:viewport-source Element

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

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

Only one binding is allowed and it works the same way that bindings work on a p:input. It is a dynamic error (err:XD0006) unless exactly one document appears on the p:viewport-source. No select expression is allowed.

5.4 p:output Element

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

<p:output
  port = NCName
  sequence? = boolean
  primary? = boolean />

The port attribute defines the name of the port. It is a static error (err:XS0011) to identify two ports with the same name on the same step. It is a static error (err:XS0013) 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 “true”, then a sequence is allowed. If sequence is not specified on p:output, or has the value “false”, then it is a dynamic error (err:XD0007) if the step does not produce exactly one document on the declared port.

The primary attribute is used to identify the primary output port. An output port is a primary output port if primary is specified with the value “true” or if the step has only a single output port and primary is not specified. It is a static error (err:XS0014) to identify more than one output port as primary.

On compound steps, the declaration may be accompanied by a binding for the output.

<p:output
  port = NCName
  sequence? = boolean
  primary? = boolean>
    (p:empty |
     (p:pipe |
      p:document |
      p:inline)+)?
</p:output>

It is a static error (err:XS0029) to specify a binding for a p:output inside a p:declare-step.

If a binding is provided for a p:output, documents are read from that binding and those documents form the output that is written to the output port. In other words, placing a p:document inside a p:output causes the processor to read that document and provide it on the output port. It does not cause the processor to write the output to that document.

5.5 p:log Element

A p:log element is a debugging aid. It associates a URI with a specific output port on a step:

<p:log
  port = NCName
  href? = anyURI />

The semantics of p:log are that it writes to the specified URI whatever document or documents appear on the specified port. How a sequence of documents is represented in a p:log implementation-defined.

It is a static error (err:XS0026) if the port specified on the p:log is not the name of an output port on the step in which it appears or if more than one p:log element is applied to the same port.

Implementations may, at user option, ignore all p:log elements.

5.6 p:serialization Element

The p:serialization element allows the user to request serialization properties on a p:pipeline output.

<p:serialization
  port = NCName
  byte-order-mark? = boolean
  cdata-section-elements? = NMTOKENS
  doctype-public? = string
  doctype-system? = string
  encoding? = string
  escape-uri-attributes? = boolean
  include-content-type? = boolean
  indent? = boolean
  media-type? = string
  method? = QName
  normalization-form? = NFC|NFD|NFKC|NFKD|fully-normalized|none
  omit-xml-declaration? = boolean
  standalone? = true|false|omit
  undeclare-prefixes? = boolean
  version? = string />

If the pipeline processor serializes the output on the specified port, it must use the serialization options specified. If the processor is not serializing (if, for example, the pipeline has been called from another pipeline), then the p:serialization must be ignored. The processor may reject statically a pipeline that requests serialization options that it cannot provide.

The default value of any unspecified serialization option is implementation defined.

The semantics of the attributes on a p:serialization are described in Section 7.3, “Serialization Options”.

It is a static error (err:XS0039) if the port specified on the p:serialization is not the name of an output port on the pipeline in which it appears or if more than one p:serialization element is applied to the same port.

5.7 Options and Parameters

Options and parameters are both name/value pairs. What distinguishes them is whether or not the pipeline author is expected to know their names in advance. Option names are always known and specified by name. Parameter names may be known, in which case they can be specified by name just like options, or they may be computed dynamically by the pipeline.

<p:delete>
  <p:option name="match" value="html:div"
	    xmlns:html="http://www.w3.org/1999/xhtml"/>
</p:delete>

<p:pipeline type="ex:delete-in-div"
	    xmlns:p="http://www.w3.org/2007/03/xproc"
	    xmlns:ex="http://example.org/ns/ex"
	    xmlns:h="http://www.w3.org/1999/xhtml">
<p:option name="divchild" required="true"/>

<p:delete>
  <p:option name="match" select="concat('h:div/',$divchild)"/>
</p:delete>

</p:pipeline>

<ex:delete-in-div>
  <p:option name="divchild" select="html:p[@class='delete']"
	    xmlns:html="http://www.w3.org/1999/xhtml"/>
</ex:delete-in-div>

<p:pipeline type="ex:delete-in-div"
	    xmlns:p="http://www.w3.org/2007/03/xproc"
	    xmlns:ex="http://example.org/ns/ex"
	    xmlns:h="http://www.w3.org/1999/xhtml">
<p:option name="divchild" required="true"/>

<p:delete>
  <p:option name="match" select="concat('h:div/',$divchild)">
    <p:namespaces xmlns:h="http://www.w3.org/1999/xhtml"
		  xmlns:html="http://www.w3.org/1999/xhtml"/>
  </p:option>
</p:delete>

</p:pipeline>

<p:pipeline type="ex:delete-in-div"
	    name="main"
	    xmlns:p="http://www.w3.org/2007/03/xproc"
	    xmlns:ex="http://example.org/ns/ex"
	    xmlns:h="http://www.w3.org/1999/xhtml">
<p:option name="divchild" required="true"/>

<p:delete>
  <p:option name="match" select="concat('h:div/',$divchild)">
    <p:namespaces option="divchild"/>
    <p:namespaces xmlns:h="http://www.w3.org/1999/xhtml"/>
  </p:option>
</p:delete>

</p:pipeline>

5.8 p:declare-step Element

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

<p:declare-step
  name? = NCName
  type = QName>
    (p:input |
     p:output |
     p:option)*
</p:declare-step>

Implementations may use extension attributes to provide implementation-dependent information about a declared step. For example, such an attribute might identify the code which implements steps of this type.

The value of the type can be from any namespace provided that the expanded-QName of the value has a non-null namespace URI. It is a static error (err:XS0025) if the expanded-QName value of the type attribute is in no namespace. If the namespace URI of the type is the XProc namespace, then the declaration must be exactly as defined in this specification. Neither users nor implementers may define additional steps in the XProc namespace.

5.9 p:pipeline-library Element

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

<p:pipeline-library
  namespace? = anyURI
  name? = NCName
  ignore-prefixes? = prefix list>
    (p:import |
     p:declare-step |
     p:pipeline)*
</p:pipeline-library>

Libraries can import pipelines and/or other libraries. It is a static error (err:XS0021) if the import references in a pipeline or pipeline library are circular.

If the p:pipeline-library specifies a namespace with the namespace attribute, then all of the untyped pipelines that occur in the library are in that namespace.

For example, given the following pipeline library:

<p:pipeline-library xmlns:p="http://www.w3.org/2007/03/xproc"
		    namespace="http://example.com/ns/pipelines">

<p:import href="ancillary-library.xml"/>
<p:import href="other-pipeline.xml"/>

<p:pipeline name="validate">
  <!-- definition of validate pipeline -->
</p:pipeline>

<p:pipeline name="format" type="my:format"
	    xmlns:my="http://example.com/vanity/mine">
  <!-- definition of format pipeline -->
</p:pipeline>

</p:pipeline-library>

The pipeline named “validate” is in the namespace http://example.com/ns/pipelines. That means that it must be invoked from the importing pipeline with a qualified name of the form:

<ex:validate>
  …
</ex:validate>

(Assuming that the “ex” prefix is bound to http://example.com/ns/pipelines.)

The pipeline named “format” has an explicit type so it must be invoked with a qualified name of the form:

<my:format>
  …
</my:format>

(Assuming that the “my” prefix is bound to http://example.com/vanity/mine.)

The pipeline library namespace applies only to pipelines that are defined directly in the library; it does not apply to pipeline libraries that are imported or pipelines that are directly imported.

[Definition: The expanded pipeline name of a pipeline is the expanded name denoted by its type, if it has one, otherwise the expanded name specified by the namespace of its containing pipeline-library and its name.]

5.10 p:import Element

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

<p:import
  href = anyURI />

An import statement loads the specified URI and makes any pipelines declared within it available to the current pipeline. An imported pipeline has an implicit signature that consists of the inputs, outputs, and options declared on it.

It is a dynamic error (err:XD0009) if the URI of a p:import cannot be retrieved or if, once retrieved, it does not point to a p:pipeline-library or p:pipeline. It is a dynamic error (err:XD0010) to import a single pipeline if that pipeline does not have a name or a type. It is a dynamic error (err:XD0012) to import more than one pipeline with the same expanded pipeline name (either directly or within a library).

5.11 p:pipe Element

A p:pipe connects an input to a port on another step.

<p:pipe
  step = NCName
  port = NCName />

The p:pipe element connects to a readable port of another step. It identifies the readable port to which it connects with the name of the step in the step attribute and the name of the port on that step in the port attribute.

In all cases except the p:output of a compound step, it is a static error (err:XS0022) if the port identified by a p:pipe is not in the readable ports of the step that contains the p:pipe.

A p:pipe that is a binding for an p:output of a compound step may connect to one of the readable ports of the compound step or to an output port on one of the compound step's contained steps. In other words, the output of a compound step can simply be a copy of one of the available inputs or it can be the output of one of its children.

5.12 p:inline Element

A p:inline provides a document 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 (err:XS0024) if the content of the p:inline element does not consist of exactly one element, optionally preceded and/or followed by any number of processing instructions, comments or whitespace characters.

5.13 p:document Element

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

<p:document
  href = anyURI />

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

It is a dynamic error (err:XD0011) if the document referenced by a p:document element 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 to Namespaces in XML. It must not perform validation. It must not perform any other processing, such as expanding XIncludes.

Use the p:load step if you need to perform DTD-based validation or wish to perform other processing on the document before it is used by a step.

5.14 p:empty Element

A p:empty binds to an empty sequence of documents.

<p:empty />

5.15 p:documentation Element

A p:documentation contains human-readable documentation.

<p:documentation>
    any-well-formed-content*
</p:documentation>

There are no constraints on the content of the p:documentation element. Documentation is ignored by pipeline processors.

6.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.

Static Errors

err:XS0001

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.

See: Connections

err:XS0002

All the named steps in the same scope must have unique names: it is a static error if two steps with the same name appear in the same scope.

See: Scoping of Names

err:XS0003

It is a static error if the port specified by a p:pipe is not in the readable ports of the environment.

See: Associating Documents with Ports

err:XS0004

It is a static error to specify two or more options or parameters on the same step with the same name.

See: p:option Element

err:XS0005

It is a static error if any token specified in the prefix list is not the prefix of an in-scope namespace.

See: Ignored namespaces, Option and Parameter Namespaces

err:XS0006

It is a static error if the primary output port has no binding and the last step in the subpipeline does not have a primary output port.

See: p:pipeline, p:for-each, p:viewport

err:XS0007

It is a static error if two subpipelines in a p:choose declare different outputs.

See: p:choose

err:XS0008

It is a static error if any element in the XProc namespace has attributes not defined by this specification unless they are extension attributes.

See: Syntax Summaries

err:XS0009

It is a static error if the p:group and p:catch subpipelines declare different outputs.

See: p:try/p:catch

err:XS0010

It is a static error if a pipeline contains a step whose specified inputs, outputs, and options do not match the signature for steps of that type.

See: Other Steps

err:XS0011

It is a static error to identify two ports with the same name on the same step.

See: Document Inputs, Parameter Inputs, p:output Element

err:XS0012

it is a static error if the port given does not match the name of an input port specified in the step's declaration.

See: Document Inputs

err:XS0013

It is a static error if the port given does not match the name of an output port specified in the step's declaration.

See: p:output Element

err:XS0014

It is a static error to identify more than one output port as primary.

See: p:output Element

err:XS0015

It is a static error to specify as an ignored namespace the XProc namespace, the namespace of any imported p:pipeline, or any namespace in which an atomic step is declared.

See: Ignored namespaces

err:XS0016

It is a static error if the value is not specified with either select or value, or if both are specified, or if value is specified with a binding.

See: Assigning Values to Options, p:parameter Element

err:XS0017

It is a static error to specify that an option is both required and has a default value.

See: Declaring Options

err:XS0018

If an option is required, it is a static error to invoke the step without specifying a value for that option.

See: Declaring Options

err:XS0019

It is a static error if the variable reference uses a QName that is not the name of an in-scope option.

See: Assigning Values to Options, p:parameter Element

err:XS0021

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

See: p:pipeline-library Element

err:XS0022

In all cases except the p:output of a compound step, it is a static error if the port identified by a p:pipe is not in the readable ports of the step that contains the p:pipe.

See: p:pipe Element

err:XS0024

It is a static error if the content of the p:inline element does not consist of exactly one element, optionally preceded and/or followed by any number of processing instructions, comments or whitespace characters.

See: p:inline Element

err:XS0025

It is a static error if the expanded-QName value of the type attribute is in no namespace.

See: p:declare-step Element

err:XS0026

It is a static error if the port specified on the p:log is not the name of an output port on the step in which it appears or if more than one p:log element is applied to the same port.

See: p:log Element

err:XS0027

It is a static error if a compound step has no contained steps.

See: Steps, Syntactic Shortcut for Option Values

err:XS0028

It is a static error to declare an option in the XProc namespace.

See: Declaring Options

err:XS0029

It is a static error to specify a binding for a p:output inside a p:declare-step.

See: p:output Element

err:XS0030

It is a static error to specify that more than one input port is the primary.

See: Document Inputs, Parameter Inputs

err:XS0031

It is a static error to use an option on an atomic step that is not declared on steps of that type.

See: Syntactic Shortcut for Option Values, Using Options

err:XS0032

It is a static error if no binding is provided and the default readable port is undefined.

See: Document Inputs, Assigning Values to Options, p:parameter Element

err:XS0033

It is a static error to specify any kind of input other than “document” or “parameter”.

See: Parameter Inputs

err:XS0034

It is a static error if the specified port is not a parameter input port or if no port is specified and the step does not have a primary parameter input port.

See: p:parameter Element

err:XS0035

It is a static error if the declaration of a parameter input port contains a binding; parameter input port declarations must be empty.

See: Parameter Inputs, Parameter Inputs

err:XS0036

All the step types in a pipeline must have unique names: it is a static error if any step type name is built-in and/or declared or defined more than once in the same scope.

See: Scoping of Names

err:XS0037

It is a static error if any step contains text nodes that do not consist entirely of whitespace.

See: Syntax Summaries

err:XS0038

It is a static error if any required attribute is not provided.

See: Syntax Summaries

err:XS0039

It is a static error if the port specified on the p:serialization is not the name of an output port on the pipeline in which it appears or if more than one p:serialization element is applied to the same port.

See: p:serialization Element

err:XS0040

It is a static error to specify any value other than “true”.

See: Parameter Inputs

err:XS0041

It is a static error to specify both option and element on the same p:namespaces element.

See: Option and Parameter Namespaces

err:XS0042

It is a static error if the declaration of a document input port inside a p:declare-step.

See: Document Inputs

err:XS0043

It is a static error if any attribute value does not satisfy the type required for that attribute.

See: Syntax Summaries

err:XS0044

It is a static error if any element in the XProc namespace or any step has element children other than those specified for it by this specification.

See: Syntax Summaries

err:XS0045

It is a static error if any string that must be interpreted as a QName uses a prefix for which there is not a namespace binding.

See: Syntax Summaries

6.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 p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

Dynamic Errors

err:XD0001

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

See: Inputs and Outputs

err:XD0002

It is a dynamic error if the processor attempts to retrieve the URI specified on a p:document and fails.

See: Associating Documents with Ports

err:XD0003

It is a dynamic error if the viewport source does not provide exactly one document.

See: p:viewport

err:XD0004

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

See: p:choose

err:XD0005

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

See: p:xpath-context

err:XD0006

If sequence is not specified, or has the value “false”, then it is a dynamic error unless exactly one document appears on the declared port.

See: Document Inputs, p:viewport-source Element

err:XD0007

If sequence is not specified on p:output, or has the value “false”, then it is a dynamic error if the step does not produce exactly one document on the declared port.

See: p:output Element

err:XD0008

It is a dynamic error if a document sequence appears where a document to be used as the context node is expected.

See: Processor XPath Context, Assigning Values to Options, p:parameter Element

err:XD0009

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

See: p:import Element

err:XD0010

It is a dynamic error to import a single pipeline if that pipeline does not have a name or a type.

See: p:import Element

err:XD0011

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

See: p:document Element

err:XD0012

It is a dynamic error to import more than one pipeline with the same expanded pipeline name (either directly or within a library).

See: p:import Element

err:XD0013

It is a dynamic error if the specified namespace bindings are inconsistent; that is, if the same prefix is bound to two different namespace names.

See: Option and Parameter Namespaces

err:XD0014

It is a dynamic error for any unqualified attribute names other than “name”, “namespace”, or “value” to appear on a c:parameter element.

See: The c:parameter element, The c:parameter-set element

err:XD0016

It is a dynamic error if the select expression on a p:input returns anything other than a possibly empty set of nodes.

See: Document Inputs

err:XD0017

It is a dynamic error if the running pipeline attempts to invoke a step which the processor does not know how to perform.

See: Other Steps

err:XD0018

It is a dynamic error if the parameter list contains any elements other than c:parameter.

See: The c:parameter-set element

err:XD0019

It is a dynamic error if any option value does not satisfy the type required for that option.

See: Syntax Summaries

err:XD0020

It is a dynamic error if the value of the test attribute is not a valid XPath expression.

See: p:when

6.3 Step Errors

Several of the steps in the standard and option step library can generate dynamic errors.

Step Errors

err:XC0001

It is a dynamic error if the requested method is not supported.

See: Serialization Options

err:XC0003

It is a dynamic error if the requested auth-method isn't supported or the authentication challenge contains an authentication method that isn't supported.

See: HTTP Request

err:XC0004

It is a dynamic error if the status-only attribute has a value of “true” and the detailed attribute does not value of “true”.

See: HTTP Request

err:XC0005

It is a dynamic error if the request contains a c:body or c:multipart but the method does not allow an entity body being sent with the request.

See: c:http-request

err:XC0006

It is a dynamic error if an existing xml:id value conflicts with a previously generated value.

See: Label Elements

err:XC0007

It is a dynamic error if the scheme of the URI is not supported.

See: Load

err:XC0008

It is a dynamic error if the pattern does not match an element or attribute.

See: Make Absolute URIs

err:XC0009

It is a dynamic error if the specified new-name is not a valid QName.

See: Rename

err:XC0010

it is a dynamic error if the encoding is not supported by the implementation.

See: Unescape Markup

err:XC0011

It is a dynamic error dynamic error if the step is not allowed to load document from the location.

See: Load, XInclude

err:XC0012

Itname is a dynamic error if the contents of the directory path are not availablecorresponds to the step due to access restrictions in the environment in which the pipeline is run.

See: Directory List

err:XC0013

Itare is a dynamic error ifagainst the match pattern does not match anelement element.

See: Add Attribute

err:XC0014

It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is used in either the >From or to options.

See: Namespace Rename

err:XC0015

It is a dynamic error if the renaming would introduce a syntactic error into the document (i.e., if it would create two attributes with the same name on the same element).

See: Rename

err:XC0016

It is a dynamic error if the value supplied for any option specified for any step in this section is not of the type mandated in the step description, with phrases such as "The value of the xxx-name option must be a QName" or "the value of the yyy-flag option must be a boolean".

See: Standard Step Library

err:XC0017

It is a dynamic error if the absolute path does not identifyhas a directory.

See: Directory List

err:XC0018

It is a dynamic error(e.g. if the directory path's scheme is not supported.

See: Directory List

err:XC0019

the output. It is a dynamic error if the documents arepath is not equal, and the value ofstep due to restrictions in environment in which the fail-if-not-equalpipeline option isrun. Any “true”.

See: Equal

7.1 Required Steps

This section describes standard steps that must be supported by any conforming processor.

<p:error name="bad-document" xmlns:my="http://www.example.org/error">name="bad-document">
   <p:option name="code" value="my:unk12">
   <p:option name="description" value="The document element is unknown."/>
</p:error>

<c:errors xmlns:c="http://www.w3.org/ns/xproc-step"
          xmlns:p="http://www.w3.org/ns/xproc"
          xmlns:my="http://www.example.org/error">
 name="bad-document" type="p:error">
<c:error name="bad-document"
          type="p:error" code="my:unk12">Thecode="err:unk12">
The document element is unknown</c:error>
</c:error>
</c:errors>

<description>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>This is a chunk of XHTML.</p>
</div>
</description>

<description>
&lt;div xmlns="http://www.w3.org/1999/xhtml">
&lt;p>This is a chunk of XHTML.&lt;/p>
&lt;/div>
</description>

<c:http-request method="POST" href="http://example.com/someservice">
<c:body xmlns:c="http://www.w3.org/2007/03/xproc-step" content-type="application/xml">
<doc>
<title>My document</title>
</doc>
</c:body>
</c:http-request>

<c:http-request method="POST" href="http://www.example.com/form-action" xmlns:c="http://www.w3.org/2007/03/xproc-step">
<c:body content-type="application/x-www-form-urlencoded">
name=W3C&spec=XProc
</c:body>
</c:http-request>

<c:http-response status="200" xmlns:c="http://www.w3.org/2007/03/xproc-step">
<c:header name="Date" value=" Wed, 09 May 2007 23:12:24 GMT"/>
<c:header name="Server" value="Apache/1.3.37 (Unix) PHP/4.4.5"/>
<c:header name="Vary" value="negotiate,accept"/>
<c:header name="TCN" value="choice"/>
<c:header name="P3P" value="policyref=&quot;http://www.w3.org/2001/05/P3P/p3p.xml&quot;"/>
<c:header name="Cache-Control" value="max-age=600"/>
<c:header name="Expires" value="Wed, 09 May 2007 23:22:24 GMT"/>
<c:header name="Last-Modified" value="Tue, 08 May 2007 16:10:49 GMT"/>
<c:header name="ETag" value="&quot;4640a109;42380ddc&quot;"/>
<c:header name="Accept-Ranges" value="bytes"/>
<c:header name="Keep-Alive" value="timeout=2, max=100"/>
<c:header name="Connection" value="Keep-Alive"/>
<c:body content-type="application/xhtml+xml">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>OK</title></head>
<body><p>OK!</p></body>
</html>
</c:body>
</c:http-response>

<description>
&lt;p>This is a chunk.&lt;/p>
&lt;p>This is a another chunk.&lt;/p>
</description>

<description>
<p xmlns="http://www.w3.org/1999/xhtml">This is a chunk.</p>
<p xmlns="http://www.w3.org/1999/xhtml">This is a another chunk.</p>
</description>

7.2 Optional Steps

The following steps are optional. If they are supported by a processor, they must conform to the semantics outlined here, but a conformant processor is not required to support all (or any) of these steps.