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) 1 May 2008

This Version:: http://www.w3.org/TR/2008/WD-xproc-20080501/
Latest Version:: http://www.w3.org/TR/xproc/
Previous versions:: http://www.w3.org/TR/2007/WD-xproc-20071129/
http://www.w3.org/TR/2007/WD-xproc-20070920/
http://www.w3.org/TR/2007/WD-xproc-20070706/
http://www.w3.org/TR/2007/WD-xproc-20070405/
Editors:: Norman Walsh, Sun Microsystems, Inc. <Norman.Walsh@Sun.COM>; Alex Milowski, Invited expert <alex@milowski.org>; Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>

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 zero or more XML documents. Pipelines generally accept zero or more XML documents as input and produce zero or more XML documents as output. Pipelines are made up of simple steps which perform atomic operations on XML documents and constructs similar to conditionals, iteration, and exception handlers which control which steps are executed.→

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.

←Since the last public working draft, the Working Group has considered severalGroup hundred commentsdecided in nearly 150 threads. We've responded to many of these by changing the specification. Some of the significant changes insupport XPath this draft1.0 are:→

←Removedas implicit pipeline inputs and outputs. See Section 2.3, “Primary Inputs and Outputs”. →
←Supportrelaxed either XPaththe two 1.0 or XPath 2.0 as the pipeline expression language. step.→
←SupportThe Working Group has not both XSLT 1.0 and XSLTthe outstanding 2.0 on a single p:xsltdraft step. →
←Addedbut p:hash,feels p:uuid, p:www-form-urldecode,that and p:www-form-urlencode.XPath →
←Addedchange in Section 2.10, “Security Considerations”. →
←Addedparticular a p:languagesuch system property. →
←Addedpervasive fixup-xml-baseimpact and fixup-xml-lang optionsthe to p:xinclude.that →
←Renamedit c:http-requesthas and c:http-responsedecided to simply c:requestpublish and c:response. →
←Addednew psvi-requireddraft attribute to pipelines. →
←Fairlyin substantial syntax changes.expose this A p:pipelineUser is now justimplementor syntactic sugar for a particular p:declare-step.be most valuable.→

The
←Changedfollowing definition of p:errorreflected to better addressthis localization issues. draft:→
←SignificantlyAttempt to reworkedsupport both the syntax and semanticsXPath 2.0; of variables, options, andbe done, parameters. Added p:variable. Support both Imposed a syntactic distinction betweenXSLT declaration (p:option)in and use (p:with-option/p:with-paramp:xslt) of options and parameters.step. →
←Clarified the scope of variables and options. .→
←Removed value attribute from p:variable, p:option, p:with-option, and p:with-param. →
←Removed automatic declaration of parameter input ports.on p:input. →
←Added p:base-uri and p:resolve-uri. functionsAdded to supportp:language (XPath 1.0) pipelines that need access to the base URI of documents. property.→
←RemovedAdded fixup-xml-base ignored namespaces,fixup-xml-lang options added p:pipeinfo. →
←RedefinedRenamed c:http-request the p:label-elements stepand c:http-response to use a step-local variable in the XPath context. c:response.→

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.1.1 Step names

2.2 Inputs and Outputs

2.2.1 External Documents

2.3 Primary Inputs and Outputs

2.4 Connections

2.4.1 Namespace Fixup on Outputs

2.5 Environment

2.6 XPaths in XProc

2.6.1 Processor XPath Context
2.6.2 Step XPath Context
2.6.3 XPath Extension Functions

2.7 Variables

2.8 Options

2.9 Parameters

2.10 Security Considerations

2.11 Versioning Considerations

3 Syntax Overview

3.1 XProc Namespaces
3.2 Scoping of Names
3.3 Base URIs and xml:base
3.4 Unique identifiers
3.5 Associating Documents with Ports
3.6 Documentation
3.7 Processor annotations
3.8 Extension attributes
3.9 Syntax Summaries

4 Steps

4.1 p:pipeline

4.2 p:for-each

4.2.1 XPath Context

4.3 p:viewport

4.3.1 XPath Context

4.4 p:choose

4.4.1 p:xpath-context
4.4.2 p:when
4.4.3 p:otherwise

4.5 p:group

4.6 p:try

4.6.1 The Error Vocabulary

4.7 Atomic Steps

4.8 ExtensionPipelines Steps

4.8.1 Syntactic Shortcut for Option Values

5 Other pipeline elements

5.1 p:input

5.1.1 Documentdeclaration and a binding. In other contexts, it is only Inputs
5.1.2 Parameter Inputs

5.2 p:iteration-source

5.3 p:viewport-source

5.4 p:output

5.5 p:log

5.6 p:serialization

5.7 Variables, Options,Options and Parameters

5.7.1 p:variable
5.7.2 p:optionDeclaring Options
5.7.3 p:with-option
5.7.4 p:with-param
5.7.5 Namespaces on variables, options, and parametersNamespaces

5.8 p:declare-step

5.8.1 Declaringuntyped atomic steps
5.8.2 Declaring pipelines

5.9 p:library

5.10 p:import

5.11 p:pipe

5.12 p:inline

5.13 p:document

5.14 p:empty

5.15 p:documentation

5.16 p:pipeinfo

6 Errors

6.1 Static Errors
6.2 Dynamic Errors
6.3 Step Errors

7 Standard Step Library

7.1 Required Steps

7.1.1 p:add-attribute
7.1.2 p:add-xml-base
7.1.3 p:compare
7.1.4 p:count
7.1.5 p:delete
7.1.6 p:directory-list
7.1.7 p:error
7.1.8 p:escape-markup
7.1.9 p:http-request
7.1.10 p:identity
7.1.11 p:insert
7.1.12 p:label-elements
7.1.13 p:load
7.1.14 p:make-absolute-uris
7.1.15 p:namespace-rename
7.1.16 p:pack
7.1.17 p:parameters
7.1.18 p:rename
7.1.19 p:replace
7.1.20 p:set-attributes
7.1.21 p:sink
7.1.22 p:split-sequence
7.1.23 p:store
7.1.24 p:string-replace
7.1.25 p:unescape-markup
7.1.26 p:unwrap
7.1.27 p:wrap
7.1.28 p:wrap-sequence
7.1.29 p:xinclude
7.1.30 p:xslt

7.2 Optional Steps

7.2.1 p:exec
7.2.2 p:hash
7.2.3 p:uuid
7.2.4 p:validate-with-relax-ng
7.2.5 p:validate-with-schematron
7.2.6 p:validate-with-xml-schema
7.2.7 p:www-form-urldecode
7.2.8 p:www-form-urlencode
7.2.9 p:xquery
7.2.10 p:xsl-formatter

7.3 Serialization Options

Appendices

A Conformance

A.1 Implementation-defined features
A.2 Implementation-dependent features
A.3 Infoset Conformance

B References

C Glossary

D Pipeline Language Summary

E Guidance on Namespace Fixup (Non-Normative)

F Handling Circular and Re-entrant Library Imports (Non-Normative)

G Sequential steps, parallelism, and side-effects

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 inputs and produce zero or more XML documents as their outputs. The inputs of 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 control the execution of other steps, which they include in the form of one or more subpipelines.

This specification defines a standard library, Section 7, “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 and Validate with XML Schema.Validate. The pipeline itself has two inputs, “source” (a source document) document) and “schemas” (a sequence of W3C XML Schemas). How inputs are connected to XML documents outside the pipeline is implementation-defined. The XInclude step reads the pipeline input “source” and produces a result document. The Validate with XML Schema step reads the pipeline input “schemas” and the the result of the XInclude step and produces its own a result document. The result of the validation, “result”, is the result of the pipeline. (For consistency across the step vocabulary, the standard input is usually named “source” and and the standard output is usually named “result”.) →

←The pipeline document determines how the steps are connected together inside the pipeline. How inputs are connected to XML documents outside the pipeline is implementation-defined. How pipeline outputs are connected to XML documents outside the pipeline is is 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:declare-step xmlns:p="http://www.w3.org/ns/xproc"
           name="xinclude-and-validate">
  <p:input port="source" primary="true"/>
  <p:input port="schemas" sequence="true"/>
  <p:output port="result">
    <p:pipe step="validated" port="result"/>
  </p:output>

  <p:xinclude name="included">
    <p:input port="source">
      <p:pipe step="xinclude-and-validate" port="source"/>
    </p:input>
  </p:xinclude>

  <p:validate-with-xml-schema name="validated">
    <p:input port="source">
      <p:pipe step="included" port="result"/>
    </p:input>
    <p:input port="schema">
      <p:pipe step="xinclude-and-validate" port="schemas"/>
    </p:input>
  </p:validate-with-xml-schema>
</p:declare-step>

←The example in Example 1, “A simple, linear XInclude/Validate pipeline” is very verbose. It makes all of the connections seen in the figure explicit. In practice, pipelines do not have to be this verbose. XProc supports defaults for many common cases:→

←If you use p:pipeline instead of p:declare-step, the “source” input port and “result” output port are implicitly declared for you.→
←Where inputs and outputs are connected between sequential sibling steps, they do not have to be madecases. explicit.→

←The same pipeline, using XProc defaults, is shown in Example 2, “A simple, linear XInclude/Validate pipeline (simplified)”.→

Example 2. A simple, linear XInclude/Validate pipeline (simplified)

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
         name="xinclude-and-validate">name="pipeline" xmlns:p="http://www.w3.org/ns/xproc">
  <p:input port="source" primary="true"/>
  <p:input port="schemas" sequence="true"/>
  <p:output port="result"/>

  <p:xinclude/>

  <p:validate-with-xml-schema>
    <p:input port="schema">
      <p:pipe step="xinclude-and-validate" port="schemas"/>
    </p:input>
  </p:validate-with-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 3. A validate and transform pipeline

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

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

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

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

This example, like the preceding, relies on XProc defaults for simplicity. It is always valid to write the fully explicit form if you prefer.

←The media type for pipeline documents is application/xml. Often, pipeline documents are identified by the extension .xpl.→

2 Pipeline Concepts

←[Definition: A pipeline is a set of connected steps, with outputs of one step flowing into into inputs of another.] A pipeline is itself a step and must satisfy the constraints on steps. Connections between steps occur where the input of one step is bound to the output of another. →

←The result of evaluating a pipeline (or subpipeline) is the result of evaluating the steps that it contains, in an order consistent with 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 inputs, explicit inputs, options, and parameters) or side-effect free.→

←The pattern of connections between steps will not always completely determine their order of evaluation. The evaluation order of steps not connected to one another is implementation-dependent. →

2.1 Steps

←[Definition: A step is the basic computational unit of a pipeline.] A typical step has zero or more inputs, from which it receives XML documents to process, zeroa or morea default outputs, to which it sends XML document results, andmanufactured can have options and/or parameters.automatically.→

←There are three kinds of steps: atomic, compound,or and multi-container.→

←[Definition: An atomic step is a step that performs a unit of XML processing, such as XInclude or transformation, and has no internal subpipeline. 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; a Validate with 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 a subpipelineone or more subpipelines.] That is, a compound step step differs from an atomic step in that its semantics are at least partially determined by the steps that it contains.→

←Finally, Every compound step contains one or more subpipelines. The steps there are two “multi-container steps”: p:choosecompound step are and p:trycontained steps. [Definition: A multi-containercompound step which immediately is a step that contains several alternateits subpipelinescontainer. ] The steps Each subpipelinethe connections is identified by a non-stepcompound step wrapper element:a subpipeline. p:whenThe andlast p:otherwisestep in a subpipeline is the caselast step in document order within of container. subpipeline = (p:for-each|p:viewport|p:choose, |p:group and |p:catch in the case of |pfx:other-step|p:try.|ipfx:ignored)* →

←The runtimesimple distinction between atomic semantics of a multi-containeris occasionally step are that it behaveschildren as if it evaluatedsteps, e.g. exactlyp:choose one ofp:try, its subpiplines. In this sense, they functionp:choose, like compound steps. →

←[Definition: Ap:when compound stepp:otherwise or multi-container step is a containerdifferent pipelines for the stepsmost directly within it or within non-step wrappers directly within it.]of [Definition: Thep:try, steps thatp:catch occur directly within, ora within non-step wrappersa subpipeline directly within, a step are called that step's containedp:group fails. steps.Acknowledging In other words, “container” and “contained steps” are inverse relationships.] [Definition: The ancestorsas of a step are its container,or the containersubpipelines. A ofp:pipeline, its container, andit all other containers above it.]→

←[Definition: Siblingcan steps (and thecalled connections between them) form a subpipeline.] [Definition: Thesomewhat lastdual stepnature in awith subpipeline isto the its last step in document order.]→

←Notecompound step. When it that user-defined pipelines, pfx:user-pipeline, areby atomic; although a pipeline declaration,pipeline, containsits invocation a subpipeline, aatomic step. The “type” which invokes a user-defined pipeline doesdetermined by the p:pipeline that defines not.→

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 may have any number of options, options, all with unique names. A step can have zero options.→

←Steps may 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 A step can have zero, one, or many parameter input ports, and each parameter port can have zero or more parameters passed on it. →

←All of the different instances of steps (atomic or compound) in a pipeline can be distinguished from one another by name. If the pipeline author does not provide a name for a step, a default name is manufactured automatically.→

2.1.1 Step names

The name attribute on any step can be used to give it a name. The name must be unique within its scope, see Section 3.2, “Scoping of Names”.

←If the pipeline author does not provide an explicit name, the processor manufactures a default name. All default names are of the form “!1.m.n…” where “mn” is the position of the step's highest ancestor within the pipeline documentwhere or library which contains it, “n” is the positionordinal number of the next-highest ancestor, andconsidering all so on, including both steps and non-step wrappers. For example, consider the pipeline in Example 3, “A validate and transform pipeline”. The p:pipeline step has no name, so it gets the default name “!1”; the p:choose gets the name “!1.2”; the first p:when gets the name “!1.2.1”, etc. If the p:choose had had a name, it would not have received a default name, but it would still have been counted and its first p:when would still have been “!1.2.1”.→

Providing every step in the pipeline with an interoperable name has several benefits:

←It provides a simple mechanism for identifying all steps from outside the pipeline, see . It allows implementors to refer to all steps in an interoperable fashion, for example, in error messages.→
Pragmatically, we say that readable ports are identified by a step name/port name pair. By manufacturing names for otherwise anonymous steps, we include implicit bindings without changing our model.

In a valid pipeline that runs successfully to completion, the manufactured names aren't visible (except perhaps in debugging or logging output).

Note

The format for defaulted names does not conform to the requirements of an NCName. This is an explicit design decision; it prevents pipelines from using the defaulted names on p:pipe elements. If an explicit connection is required, the pipeline author must provide an explicit name for the step.

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.

For the purposes of this specification, an XML document is an [Infoset]. Implementations are free to transmit infosets as sequences of characters, sequences of events, object models, or any other representation that preserves the necessary infoset properties (see Section A.3, “Infoset Conformance”).

Most steps in this specification manipulate XML documents, or portions of XML documents. In these cases, we speak of changing elements, attributes, or nodes without prejudice to the actual representation used by an implementation.

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 data cannot arrive on an input port to a step.

It is a dynamic error (err:XD0001) if a non-XML resource is produced on a step output or arrives on a step input.

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

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

←Like atomic steps, top level, user-defined pipelines also have declarations. The situation is slightly more complicated for the other compound steps because they don't have separate declarations; each instance of the compound step serves as its own declaration. OnCompound steps don't have declared inputs, but they do have declared outputs, and unlike these steps, on compound steps, the number and names of the outputs can be different different on each instance of the step.→

Figure 4, “A compound step” illustrates symbolically a compound step with one subpipeline and 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: 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:

The output port of some other step.
A fixed, inline document or sequence of documents.
A document read from a URI.
←One of the inputs declared on one of its ancestors.ancestors.→
A special port provided by an ancestor compound step, for example, “current” in a p:for-each or p:viewport.

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 input port of some other step.
One of the outputs declared on its container.

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 subpipeline inside 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:

The output port of some contained step.
A fixed, inline document or sequence of documents.
A document read from a URI.

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.

←It is also not an error to connect a port that is declared to produce a single document to a port that is declared to accept a sequence. A single document is the same as a sequence of one document.→

←An output port may be connected to more than one input port. At runtime this will result in distinct copies of the output.→

←[Definition: The signature of a step is the set of inputs, outputs, and options that it is declared to accept.] Each Theatomic step declaration for a step provides a fixed signaturesignature, declared globally or built-in, which all its instances share, whereas each instancescompound step has its own implicit share.→

[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 informative messages. These messages areappear on a special captured and provided on the erroroutput port insideis only bound to an input in the catch clause of a p:catchtry/catch. Outside of a try/catch, the disposition of error messages is implementation-dependent. →

2.2.1 External Documents

It's common for some of the documents used in processing a pipeline to be read from URIs. Sometimes this occurs directly, for example with a p:document element. Sometimes it occurs indirectly, for example if an implementation allows the URI of a pipeline input to be specified on the command line or if an p:xslt step encounters an xsl:import in the stylesheet that it is processing. It's also common for some of the documents produced in processing a pipeline to be written to locations which have, or at least could have, a URI.

The process of dereferencing a URI to retrieve a document is often more interesting than it seems at first. On the web, it may involve caches, proxies, and various forms of indirection. Resolving a URI locally may involve resolvers of various sorts and possibly appeal to implementation-dependent mechanisms such as catalog files.

In XProc, the situation is made even more interesting by the fact that many intermediate results produced by steps in the pipeline have base URIs. Whether or not (and when and how) the intermediate results that pass between steps are ever written to a filesystem is implementation-dependent.

In Version 1.0 of XProc, how (or if) implementers provide local resolution mechanisms and how (or if) they provide access to intermediate results by URI is implementation-defined.

←Version 1.0 of XProc does not require implementations to guarantee that multiple attempts to dereference the same URI always produce consistent results.→

Note

On the one hand, this is a somewhat unsatisfying state of affairs because it leaves room for interoperability problems. On the other, it is not expected to cause such problems very often in practice.

If these problems arise in practice, implementers are encouraged to use the existing extension mechanisms to give users the control needed to circumvent them. Should such mechanisms become widespread, a standard mechanism could be added in some future version of the language.

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. A step can have at most one primary input port.→

←[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. A step can have at most one primary output port.→

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 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). This implicitrule does not apply to p:pipeline steps; all of the inputs and outputs of a p:pipeline must be explicitly declared. Options Some steps accept options. Options are name/value pairs. 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 string value is computed and that string is used. 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. 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. Parameters Some steps accept parameters. Parameters are name/value pairs. 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 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. A parameter input port is a distinguished kind of input port which accepts (only) dynamically constructed parameter name/value pairs. See . Analogous to primary input ports, steps that have parameter inputs may designate at most one parameter input port as a primary parameter input port. If a step has a parameter output port which is explicitly marked “primary='true'”, or if it has noexactly one parameter input port and that port is not explicitly marked “primary='false'”, then that parameter input port is the primary name. It inheritsport 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 sequencethe primary, then the primary parameter input property 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 boundwill 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 it.parameters accepted by the p:pipeline is implementation-defined.→

2.4 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.4.1 Namespace Fixup on Outputs

XProc processors are expected, and sometimes required, to perform namespace fixup. Unless the semantics of a step explicitly says otherwise:

The in-scope namespaces associated with a node (even those that are inherited from namespace bindings that appear among its ancestors in the document in which it appears initially) are assumed to travel with it.
Changes to one part of a tree (wrapping or unwrapping a node or renaming an element, for exam