The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: new, added text, changed text, and deleted text.

XProc: An XML Pipeline Language

W3C Working Draft (with revision marks) 6 July 2007

This Version:: http://www.w3.org/TR/2007/WD-xproc-20070706/
Latest Version:: http://www.w3.org/TR/xproc/
Previous versions:: http://www.w3.org/TR/2007/WD-xproc-20070405/ http://www.w3.org/TR/2006/WD-xproc-20061117/ http://www.w3.org/TR/2006/WD-xproc-20060928/
Editors:: Norman Walsh, Sun Microsystems, Inc. <Norman.Walsh@Sun.COM>; Alex Milowski, Invited expert <alex@milowski.org>

This document is also available in these non-normative formats: XML, Revision markup

Abstract

This specification describes the syntax and semantics of XProc: An XML Pipeline Language, a language for describing operations to be performed on XML documents.

An XML Pipeline specifies a sequence of operations to be performed on one or more XML documents. Pipelines generally accept one or more XML documents as inputdocuments, and producing one or more XML documents documents as output, though they are not required to do so. Some pipelines are entirely self-contained, starting with input derived inside the pipeline and producing no XML output.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document was produced by the XML Processing Model Working Group which is part of the XML Activity. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This is a public Working Draft. This draft addresses many, but not all, of the design questions that were incomplete in previous drafts. The library of standard steps, both required and optional, is still being reviewed and considered. The Working Group continues to encourage feedback from potential users. ANo useful revision marks draft, withfrom respect to the 5 April 2007 specification, has been provided, though it is not obviously of great valueavailable due to significant editorial reorganization of the material.

The most significant changes in this draft are: a new mechanism for dealing with parameters, new defaulting rules for primary input and output ports, and revisions to the standard step library.

Please send comments about this document to public-xml-processing-model-comments@w3.org (public archives are available).

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

1 Introduction

2 Pipeline Concepts

2.1 Steps

2.2 Inputs and Outputs

2.3 Primary InputsOptions and Outputs

2.4 Options

2.5 Parameters

2.6 Connections

2.7 Environment

2.8 XProc Extension Functions for XProc

2.8.1 Systeminherited Properties
2.8.2 Step Available
2.8.3 Iteration Count

3 Syntax Overview

3.1 XProc Namespaces
3.2 Scoping of Names
3.3 Global Attributes
3.4 Associating Documents with Ports
3.5 Documentation
3.6 Extension attributes
3.7 Extension elements
3.8 Ignored namespaces
3.9 Syntax Summaries

4 Steps

4.1 p:pipeline

4.2 p:for-each

4.3 p:viewport

4.4 p:choose

4.5 p:group

4.6 p:try/p:catch

4.7 Other Steps

4.7.1 Syntactic Shortcut for Option Values

5 Other pipeline elements

5.1 p:input Element

5.1.1 Document Inputs
5.1.2 Parameter Inputs

5.2 p:iteration-source Element

5.3 p:viewport-source Element

5.4 p:xpath-context Element

5.5 p:output Element

5.6 p:log Element

5.7 Options and Parameters

5.7.1 p:optionp:parameter Element
5.7.2 p:parameter Element
5.7.3 Option and Parameter Namespace BindingsElement

5.8 p:declare-step Element

5.9 p:pipeline-library Element

5.10 p:import Element

5.11 p:pipe Element

5.12 p:inline Element

5.13 p:document Element

5.14 p:empty Element

5.15 p:documentation Element

6 Errors

6.1 Static Errors
6.2 Dynamic Errors

Appendices

A Standard Step Library

A.1 Required Steps

A.1.1 Count
A.1.2 Delete
A.1.3 Equal
A.1.4 Error
A.1.5 Escape Markup
A.1.6 Identity
A.1.7 InsertJoin Sequences
A.1.8 Label Elements
A.1.9 Load
A.1.10 Namespace RenameStore
A.1.11 Parameters
A.1.12 Rename
A.1.13 Replace
A.1.14 Set AttributesXSLT
A.1.15 Sink
A.1.16 Split Sequence
A.1.17 String ReplaceSerialize
A.1.18 Store
A.1.19 Unescape MarkupParse
A.1.20 UnwrapHttp Request
A.1.21 Wrap
A.1.22 Wrap Sequence
A.1.23 XIncludeXSLT 2.0
A.1.24 XSLT

A.2 Optional Steps

A.2.1 HTTP Request

A.2.1.1 c:http-request
A.2.1.2 c:headerMicro-Operations Components
A.2.1.3 c:multipart
A.2.1.4 c:body
A.2.1.5 c:http-response
A.2.1.6 HTTP Request ExamplesRename

A.2.2 Relax NG ValidateRename

A.2.3 XMLis Schema Validate

A.2.4 XSLT 2.0Replace

A.2.5 XSL FormatterUnwrap

A.2.6 XQuery 1.0Wrap

B Conformance

C References

D Glossary

E Pipeline Language Summary

F The Error Vocabulary

F.1 err:errors
F.2 err:error
F.3 Error Example

1 Introduction

An XML Pipeline specifies a sequence of operations to be performed on a collection of XML input documents. Pipelines take zero or more XML documents as their input and produce zero or more XML documents as their output.

A pipeline consists of steps. Like pipelines, steps take zero or more XML documents as their input and produce zero or more XML documents as their output. The inputs to a step come from the web, from the pipeline document, from the inputs to the pipeline itself, or from the outputs of other steps in the pipeline. The outputs from a step are consumed by other steps, are outputs of the pipeline as a whole, or are discarded.

There are two kinds of steps: atomic steps and compound steps. Atomic steps carry out single operations and have no substructure as far as the pipeline is concerned, whereas compound steps include a subpipeline of steps within themselves.

This specification defines a standard library, Appendix A, Standard Step Library, of steps. Pipeline implementations may support additional types of steps as well.

Figure 1, “A simple, linear XInclude/Validate pipeline” is a graphical representation of a simple pipeline that performs XInclude processing and validation on a document.

Figure 1. A simple, linear XInclude/Validate pipeline

This is a pipeline that consists of two atomic steps, XInclude and Validate. The pipeline itself has two inputs, “Document” and “Schema”. How these inputs are connected to XML documents outside the pipeline is implementation-defined.implementation-defined. The XInclude step reads the pipeline input “Document” and produces a result document. The Validate step reads the pipeline input “Schema” and the output from the XInclude step and produces a result document. The result of the validation, “Result Document”, is the result of the pipeline. How pipeline outputs are connected to XML documents outside the pipeline is implementation-defined.implementation defined.

The pipeline document for this pipeline is shown in Example 1, “A simple, linear XInclude/Validate pipeline”.

Example 1. A simple, linear XInclude/Validate pipeline

<p:pipeline name="fig1" xmlns:p="http://www.w3.org/2007/03/xproc">
  <p:input port="source" primary="yes"/>
  <p:input port="schemaDoc" sequence="yes" primary="no"/>sequence="yes"/>
  <p:output port="result"/>port="result" sequence="no"/>

  <p:xinclude/><p:xinclude name="s1">
    <p:input port="source">
      <p:pipe step="fig1" port="source"/>
    </p:input>
  </p:xinclude>

  <p:validate-xml-schema><p:validate-xml-schema name="s2">
    <p:input port="schema">
      <p:pipe step="fig1" port="schemaDoc"/>
    </p:input>
  </p:validate-xml-schema>
</p:pipeline>

Figure 2, “A validate and transform pipeline” is a more complex example: it performs schema validation with an appropriate schema and then styles the validated document.

Figure 2. A validate and transform pipeline

The heart of this example is the conditional. The “choose” step evaluates an XPath expression over a test document. Based on the result of that expression, one or another branch is run. In this example, each branch consists of a single validate step.

Example 2. A validate and transform pipeline

<p:pipeline xmlns:p="http://www.w3.org/2007/03/xproc">
  <p:input port="source" sequence="no"/>
  <p:output port="result" sequence="no"/>

  <p:documentation xmlns="http://www.w3.org/1999/xhtml">
    <div>
      <p>This is documentation</p>
    </div>
  </p:documentation>

  <p:choose><p:choose name="vcheck">
    <p:when test="/*[@version &lt; 2.0]">
      <p:output port="valid"/>
      <p:validate-xml-schema name="val1">
	<p:input port="schema">
	  <p:document href="v1schema.xsd"/>
	</p:input>
      </p:validate-xml-schema>
    </p:when>

    <p:otherwise>
      <p:output port="valid"/>
      <p:validate-xml-schema name="val2">
	<p:input port="schema">
	  <p:document href="v2schema.xsd"/>
	</p:input>
      </p:validate-xml-schema>
    </p:otherwise>
  </p:choose>

  <p:xslt name="xform">
    <p:input port="stylesheet">
      <p:document href="stylesheet.xsl"/>
    </p:input>
  </p:xslt>
</p:pipeline>

2 Pipeline Concepts

[Definition: A pipeline is a set of steps connected together, steps, outputs flowing into inputs, without any loops (no step can read its own output, directly or indirectly).] A pipeline is itself a step and must satisfy the constraints on steps.

The result of evaluating a pipeline is the result of evaluating the steps that it contains, in the order determined by the connections between them. A pipeline must behave as if it evaluated each step each time it occurs. Unless otherwise indicated, implementations must not assume that steps are functional (that is, that their outputs depend only on their explicit inputs, options, and parameters) or side-effect free.

2.1 Steps

[Definition: A step is the 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, and has no internal subpipeline.transformation.] Atomic steps carry out fundamental XML operations and 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 set of XML Schemas, etc.

There are many types of atomic steps. The standard library of atomic steps is described in Appendix A, Standard Step Library, but implementations may provide others as well. 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 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 one 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 compound step form a subpipeline.] [Definition: The last step in a subpipeline is the last step in document order within its container. ]

A compound step can contain one or more subpipelines and it determines how and whichwhich, if any, of its subpipelines are evaluated.

Steps have “ports” into which inputs and outputs are connected or “bound”.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 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 options, all with unique names. A step can have zero options.

Steps may have access to 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 (err:XD0001) if a non-XML resource is produced on a step output or arrives on a step input. What about the cases where it's impractical to test for this error?

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—butdisk—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.step or pipeline.

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.

An atomic step with two inputs and one output

Figure 3. An atomic step

AllEach step declares its input and output atomicports. The steps are defined by a step are its declared p:declare-stepinputs. The output ports declared Theon a declarationstep are its declared outputs. All of anthe declared inputs of atomic step (atomic or compound) must be definesconnected. Inputs the input ports,connected to: The output ports,port of some other step. andA fixed, options of all steps of thatdocuments. A document type. For example, everyURI. p:xsltThe step has two inputs, named “source”top-level and “stylesheet”,step, and only oneon that step, may be output named “result”documents and the samepipeline by an implementation-dependent mechanism. Unconnected output ports are allowed; any set of options. those ports are simply discarded.

TheFor atomic steps, the situation is slightly more complicated for compound(with p:declare-step) steps because they don't have separate declarations; each instance of athat type has the same inputs compoundand outputs. For example, every XSLT step serveshas exactly the same inputs and outputs with the same names. The situation is slightly as its own declaration. steps. Compound steps don't typically 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.

A compound step with two inputs and one output

Figure 4. A compound step

[Definition: TheOutput ports on input ports declared on a step are its declaredthe inputs.]perspective [Definition: Theof the output ports declared on a stepoutputs are itsjust outputs and declaredthey outputs.]can Wheneither be connected up or not. a step is used in a pipeline, connections they are made to all of its inputs and outputs. connected.

When a step is used, all ofstep, the declared outputs inputsof of the step must be connected. Each input may be connected to:

The output port of some other contained step.step.
A fixed, inline document or sequence of documents.
A document read from a URI.
One of the inputs declared on the top-level p:pipeline step.port.

When an inputIf accepts a sequence of documents, it may have oneport, or more bindings toone any of those locations.

Alloutput of the declaredexplicitly outputsdesignated of a step mustdefault, be connected. Outputsoutput port may be connecteddefault to:

The inputoutput port of some other step.
One of the outputs declared on the top-level p:pipeline step.

Output ports on compound steps haveIf a dual nature: from the perspectivethan of the compound step's siblings, its outputs are just ordinary outputs and must be connected as described above. Fromdesignated 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:

Thedefault output port of some containedthat step.
A fixed, inline document or sequence of documents.
A document read from a URI.undefined.

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

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

[Definition: A step matches its signature if and only if it specifies an input for each declared input,input and it specifies no inputs that are not declared,declared; it specifies no options 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 inputsinputs, outputs, options, 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 defined (only) in the catch clause of a try/catch. Outside of a try/catch, the disposition of error messages is implementation-dependent.

2.3 Primary InputsOptions and Outputs

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

[Definition: If a step has exactly oneparameters input port, or if one of its input ports is explicitly designated as the primary, thensimply that input port is the primary inputused portby of the step.] If a step has a single input port and that port is explicitly designated as not being the primary input port, or if a step has more than one input port and none is explicitly designated the primary, then the primary input port of that step is undefined.

[Definition: If a step has exactly one output port, or if one of its output ports is explicitly designated as the primary, 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 designated as not being the primary, or if a step has more than one output port and none is explicitly designated 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 theXProc 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 ofconfigure the second.

Additionally, if a compound step has no declared inputs andstep; the first step in its subpipeline has an unboundParameters primary input, then an implicit (and unnamed) primary inputpassed port will be added to the compound step. If a compound step has nofor declared outputs and the last step in its subpipeline has an unbound primary output, then an implicit (and also unnamed) primary output port will be addeduse, to the compound step.

Theprocessor 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="result">
  <p:pipe step="transform" port="result"/>
</p:input>

<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:xslt>

</p:pipeline>

2.4 Options

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

[Definition: An option is a name/value pairpair. The name of where the name is an expanded name. andThe value of 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 pairpair. The name of where the name is an expanded name. andThe value of 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.

UnlikeThe options, which have names known in advance to thea pipeline, parametersstep 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 withparameters. parameter inputs.

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.step.]

The environment consists of:

A set of ignored namespaces. The set of ignored namespaces are the namespaces which do not identify steps.

A set of readable ports. [Definition: The readable ports are the step name/output port name pairs that are visible to the step.] Inputs and outputs can only be connected to readable ports.
A set of in-scope options. [Definition: The in-scope options are the set of options that arecan be visible to a step.] All of the in-scope options are available to the processor for computing option and parameter values.parameters. The actual options passed to a step are those that are declared for a stepwith ofp:parameter its type and that have values either provided explicitly withor p:option elements on the step or as defaults in the declaration of theactual step.
A default readable port. [Definition: The default readable port, which may be undefined, is a specific step name/port name pair from the set of readable ports.]

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

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

Thefollowing standard modifications made to an inherited environment are::

All of the specified options of the step container are added to the in-scope options. The value of any option in the environment with the same name as one of the options specified on the container is shadowed by the new value.

In other words, steps can access the most recently specified value of all of the options specified on any ancestor step.environment.
The union of all the declared outputs of all of the step's siblingthose containednamespaces steps are added to the set of readable ports.

In other words, sibling steps can see each other's outputs in addition to the outputs visible to their container. environment.
If there is a preceding sibling step element:
- If that preceding sibling has aexactly one output port, or primaryan output port, designated as the default, then that output port becomes the default readable port.
- Otherwise, the default readable port is undefined.
If there is not a preceding sibling step element, the default readable port is unchanged.unchanged from its inherited environment.

A step with no parent inherits the empty environment.

2.8 XProc Extension Functions for XProc

The XProc processor must support a few additional functions in XPath expressions evaluatedspecified, by the processor.

2.8.1 Systeminherited Properties

XPath expressions within aenvironment pipeline document can interrogate the processor for information about the current state of the pipeline. Four aspects of the processor are exposed through the p:system-propertycontained function in the pipeline namespace:

Function: String p:system-property(String property)

The property string must havesteps the form of a compound QName; the QNamestep is expanded into a name using the namespace declarations in scope for the expression.standard Theinheritance, p:system-property function returns the stringwhich representing the value of the systemcompound property identified by the QName.step, If there is no such property, the empty string must be returned.

Implementations must providewith the following system properties, which are all in the XProc namespace:modification:

p:episode: Returns a string which should be unique for each invocation of the pipeline processor.

The unique identifierunion must consist of ASCII alphanumeric characters and must start with anall alphabetic character. Thus, the string is syntactically an XML name.
p:product-name: Returns a string containing theoutputs name of the implementation, ascontained definedsteps by the implementer. This should normally remain constant from one release ofadded the product to the next. It should also be constant across platformsreadable in cases where the same source code is used to produce compatible products for multiple execution platforms.
p:product-version: Returns a string identifying the version of the implementation, as defined by the implementer. This should normally vary from one release of the product to the next, and at the discretion of the implementer it may also vary across different execution platforms.
p:vendor: Returns a string which identifies the vendor of the processor.
p:vendor-uri: Returns a URI which identifies the vendor of the processor. Often, this is the URI of the vendor's web site.
p:version: Returns the version of XProc implemented by the processor; for processors implementing the version of XProc specified by this document, the number is “1.0”.

The value will always be a stringports in the lexical space of the decimal data type defined in [W3C XML Schema: Part 2]. This allows the value to be converted to a number for the purpose of magnitude comparisons.environment.

2.8.2 Step Available

The p:step-availableother function reports whether or not asee particular type of step is understood by the processor.

Function: Boolean p:step-available(String step-type)

The step-type string must have the form of a QName; the QName is expanded into a name using the namespace declarations outputs in scope for the expression. The p:step-available function returns true ifaddition and only if the processor knows how to evaluate steps of the specified type.

2.8.3 Iteration Count

In theoutputs context of a p:for-each or a p:viewport, the p:iteration-count function reports the number of iterations that have occurred. In the context of other standard XProc compound steps, it returnstheir 1.

Function: Integer p:iteration-count()

In the context of an extension compound step, the value is implementation-defined.

3 Syntax Overview

This section describes the normative XML syntax of XProc. This syntax is sufficient to represent all the aspects of a pipeline, as set out in the preceding sections.

The namespace of the XProc XML vocabulary described by this specification is http://www.w3.org/2007/03/xproc. Elements in a pipeline document represent the pipeline, the steps it contains, the connections between those steps, the steps and connections contained within them, and so on. Each step is represented by an element; a combination of elements and attributes specify how the inputs and outputs of each step are connected and how options and parameters are passed.

Conceptually, we can speak of steps as objects that have inputs and outputs, that are connected together and which may contain additional steps. Syntactically, we need a mechanism for specifying these relationships.

Containment is represented naturally using nesting of XML elements. If a particular element identifies a compound step then the step elements that are its immediate children form its subpipeline.

The connections between steps are expressed using names and references to those names.

Six kinds of things are named in XProc:

StepSteps types,
Steps,
Input ports,
Output ports,
Options, and
Parameters

3.1 XProc Namespaces

The XML syntax for XProc uses three namespaces:

http://www.w3.org/2007/03/xproc: The namespace of the XProc XML vocabulary described by this specification; by convention, the namespace prefix “p:” is used for this namespace.
http://www.w3.org/2007/03/xproc-step: The namespace used for documents that are inputs to and outputs from several standard and optional steps described in this specification. Some steps, such as p:http-requestOptions, and p:store, have defined input or output vocabularies. We use this namespace for all of those documents. The conventional prefix “c:” is used for this namespace.
http://www.w3.org/2007/03/xproc-error: The namespace used for error reporting. When a step fails inside a p:try, it may produce error messages that can be inspected in the p:catch. The error namespace is used for those messages. The conventional prefix “err:” is used for this namespace.Parameters

3.2 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 (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 appear. The scope of parameter names is essentially the same as the scope scope of step names, with the following caveat: whereas step names names must be unique, option names may be repeated. AnThe declaration of option specified on a step shadows any specification that may already be in-scope.

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:

The attribute xml:id with the semantics outlined in [xml:id].
The attribute xml:base with the semantics outlined in [XML Base].

The following attributes may appear on any step element: The attribute p:ignore-prefixes with the semantics outlined in .

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

p:ignore-prefixes

Specified by URI

[Definition: A document is specified by URI if it is referenced with a URI.] The href attribute on the p:document element is used to refer to documents by URI.

In this example, the input to the p:identityIdentity step named “otherstep” comes from “http://example.com/input.xml”.

<p:identity name="otherstep">
  <p:input port="source">
    <p:document href="http://example.com/input.xml"/>
  </p:input>
</p:identity>

</p:pipeline>

It is a dynamic error (err:XD0002) if the processor attempts to retrieve the URI specified on a p:document and fails. (For example, if the resource does not exist or is not accessible with the user's authentication credentials.)

Specified by source

[Definition: A document is specified by source if it references a specific port on another step.] The step and port attributes on the p:pipe element are used for this purpose. (The step attribute may refer to any kind of step, either a atomic step or a step, its name notwithstanding.)

In this example, the “document” input to the p:xinclude XInclude step named “expand” comes from the “result” port of the step named “otherstep”.

<p:xinclude name="expand">
  <p:input port="source">
    <p:pipe step="otherstep" port="result"/>
  </p:input>
</p:xinclude>

</p:pipeline>

When a p:pipepipe is used, the specified port must be in the readable ports of the current environment. It is a static error (err:XS0003) if the port specified by a p:pipe is not in the readable ports of the environment.

Specified inline

[Definition: An inline document is specified directly in the body of the element that binds it.] The content of the p:inline element is used for this purpose.

In this example, the “stylesheet” input to the XSLT step named “xform” comes from the content of the p:input element itself.

<p:xslt name="xform">
  <p:input port="source">
    <p:pipe step="expand" port="result"/>
  </p:input>
  <p:input port="stylesheet">
    <p:inline>
      <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                      version="1.0">
        ...
      </xsl:stylesheet>
    </p:inline>
  </p:input>
</p:xslt>

Inline documents are considered “quoted”, they are not interpolated or available to the pipeline processor in any way except as documents flowing through the pipeline.

Specifiedmay contain more than one explicitlyp:pipe, empty

Note that an p:input or p:output element p:document, or p:inline

[Definition: An emptyelement. If more than one binding is provided, then the specified sequence of documents is specifiedmade available on with theport. p:emptyIgnored element.]

namespaces

InThe element children this example, thecompound “source”step fall into four classes: elements that provide bindings for input toand output ports, elements that provide the XSLT 2.0 step named “generate”other elements that identify is explicitlythat are empty:

<p:xslt2part name="generate">
  <p:inputof port="source">
    <p:empty/>
  </p:input>
  <p:inputits port="stylesheet">
    <p:inline>
      <xsl:stylesheetsubpipeline, xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                      version="2.0">
        ...
      </xsl:stylesheet>
    </p:inline>
  </p:input>
  <p:optionand name="template-name" value="someName"/>
</p:xslt2>Extension elements may be used for documentation or to provide additional

information for a specific processor.

IfTo determine which elements are extension elements and you omit theexpected to binding on a primaryset of input port, a binding to the defaultenvironment of each readablestep. The portignored namespaces willare a set of namespaces be assumed. Making the binding explicitly empty guarantees that the bindingprocessor unless will be happens to anrecognize one or more of them as extension emptyelements. sequenceThe initial set of documents.ignored namespaces is empty.

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.

NoteThe value of the p:ignore-prefixes thatattribute is a p:inputsequence or p:outputtokens, element mayeach contain more than one p:pipe,the p:document, orprefix p:inlineof element. If morenamespace. It than one bindingstatic error if any token specified in the p:ignore-prefixes attribute is provided,not the prefix of an in-scope namespace. Each then the specified namespaces identified by sequence of documents is madeadded to the available on that port in the same orderenvironment of the step as which the bindings.attribute occurs.

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 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.] 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.implementation-dependent.

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

3.7 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.implementation-dependent.

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

In an inline document. All elements in an inline document are considered quoted; no extension element can occur.
In a subpipeline. In a subpipeline, any element in a namespace that is in the set of ignored namespaces is an extension element. Every other element identifies a step.
In any other context, any element that is not in the pipeline namespace is an error.extension element.

3.8 Ignored namespaces

The element children of a p:pipeline can come from many different namespaces. Some of the children identify steps in the subpipeline, others may be extension elements. In order to determine which elements are extension elements and which are expected to identify steps, the pipeline may specify a set of “ignored namespaces”

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.

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. It is a static error (err:XS0004) if the ignore-prefixes attribute appears on any other element in the pipeline namespace.

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 ignore-prefixes attribute is not the prefix of an in-scope namespace.

Elements in an ignored namespace are only ignored when they appear as the direct children of the p:pipeline or p:pipeline-library which specifies the ignored namespaces.

Any ignored namespaces that are specified in a pipeline library are not inherited by pipelines either within that library or that import that library, they only apply to the elements that appear as children of the p:pipeline-library element on which they are specified.

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:

An xml:id attribute is allowed on any element. It has the semantics of [xml:id].
An xml:base attribute is allowed on any element. It has the semantics of [XML Base].
The p:documentation element is not shown, but it is allowed anywhere.
Attributes that are syntactic shortcuts for option values are not shown.

4 Steps

This section describes the core steps of XProc.

Every compound step in a pipeline has several parts: a set of inputs, a set of outputs, a set of options, a set of parameters, a set of contained steps, and an environment.

Editorial Note

In previous drafts, inputs, outputs, options, and options occurred in a fixed order. In this draft, they may appear in any order (but before the contained steps). Is that problematic?an improvement?

Except where otherwise noted, a compound step can have an arbitrary number of inputs, outputs, options, parameters, and contained steps.

It is a <