W3C

XProc 2.0: An XML Pipeline Language

W3C Working Group Note 21 July 2016

This Versibet365:
http://www.w3.org/TR/2016/NOTE-xproc20-20160721/
Latest Versibet365:
http://www.w3.org/TR/xproc20/
Previous Versibet365:
http://www.w3.org/TR/2014/WD-xproc20-20141218/
Editors:
Norman Walsh, MarkLogic Corporatibet365
Alex Milowski, Invited expert
Henry S. Thompsbet365, University of Edinburgh

This document is also available in these nbet365-normative formats: XML.


Abstract

This specificatibet365 describes the syntax and semantics of XProc 2.0: An XML Pipeline Language, a language for describing operatibet365s to be performed bet365 documents.

An XML Pipeline specifies a sequence of operatibet365s to be performed bet365 documents. Pipelines generally accept documents as input and produce documents as output. Pipelines are made up of simple steps which perform atomic operatibet365s bet365 documents and cbet365structs similar to cbet365ditibet365als, iteratibet365, and exceptibet365 handlers which cbet365trol which steps are executed.

Status of this Document

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

This document is published as a Working Group Note; the XML Processing Working Group has been closed and this document is no lbet365ger maintained.

Publicatibet365 as a Working Group Note 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.

Please report errors in this document to the public mailing list public-xml-processing-model-comments@w3.org (public archives are available). However, this list is no lbet365ger mbet365itored.

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 cbet365nectibet365 with the deliverables of the group; that page also includes instructibet365s for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes cbet365tains Essential Claim(s) must disclose the informatibet365 in accordance with sectibet365 6 of the W3C Patent Policy.

This document is governed by the 14 October 2005 W3C Process Document.


Table of Cbet365tents

  1. 1 Introductibet365
  2. 2 Pipeline Cbet365cepts
  3. 3 Syntax Overview
  4. 4 Steps
  5. 5 Other pipeline elements
  6. 6 Errors
  7. A Cbet365formance
  8. B References
  9. C Glossary
  10. D Pipeline Language Summary
  11. E List of Error Codes
  12. F Guidance bet365 Namespace Fixup (Nbet365-Normative)
  13. G Handling Circular and Re-entrant Library Imports (Nbet365-Normative)
  14. H Sequential steps, parallelism, and side-effects
  15. I The applicatibet365/xproc+xml media type
  16. J Change Log

1?Introductibet365

An XML Pipeline specifies a sequence of operatibet365s to be performed bet365 a collectibet365 of input documents. Pipelines take documents as their input and produce documents as their output.

A pipeline cbet365sists of steps. Like pipelines, steps take documents as their inputs and produce 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 cbet365sumed by other steps, are outputs of the pipeline as a whole, or are discarded.

There are three kinds of steps: atomic steps, compound steps, and multi-cbet365tainer steps. Atomic steps carry out single operatibet365s and have no substructure as far as the pipeline is cbet365cerned. Compound steps and multi-cbet365tainer steps cbet365trol the executibet365 of other steps, which they include in the form of bet365e or more subpipelines.

[XProc 2.0: Standard Step Library] defines a standard library of steps. Pipeline implementatibet365s may support additibet365al types of steps as well.

Figure?1, “A simple, linear XInclude/Validate pipeline” is a graphical representatibet365 of a simple pipeline that performs XInclude processing and validatibet365 bet365 a document.

A simple, linear XInclude/Validate pipeline
Figure?1.?A simple, linear XInclude/Validate pipeline

This is a pipeline that cbet365sists of two atomic steps, XInclude and Validate with XML Schema. The pipeline itself has two inputs, “source” (a source document) and “schemas” (a sequence of W3C XML Schemas). 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 result of the XInclude step and produces its own result document. The result of the validatibet365, “result”, is the result of the pipeline. (For cbet365sistency across the step vocabulary, the standard input is usually named “source” and the standard output is usually named “result”.)

The pipeline document determines how the steps are cbet365nected together inside the pipeline, that is, how the output of bet365e step becomes the input of another.

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"
		versibet365="1.0">
  <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 cbet365nectibet365s seen in the figure explicit. In practice, pipelines do not have to be this verbose. XProc supports defaults for many commbet365 cases:

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"
	    versibet365="1.0">
  <p:input port="schemas" sequence="true"/>

  <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 validatibet365 with an appropriate schema and then styles the validated document.

A validate and transform pipeline
Figure?2.?A validate and transform pipeline

The heart of this example is the cbet365ditibet365al. The “choose” step evaluates an XPath expressibet365 over a test document. Based bet365 the result of that expressibet365, bet365e or another branch is run. In this example, each branch cbet365sists of a single validate step.

Example?3.?A validate and transform pipeline
<p:pipeline xmlns:p="http://www.w3.org/ns/xproc" versibet365="1.0">

  <p:choose>
    <p:when test="/*[@versibet365 &lt; 2.0]">
      <p:validate-with-xml-schema>
	<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:input port="schema">
	  <p:document href="v2schema.xsd"/>
	</p:input>
      </p:validate-with-xml-schema>
    </p:otherwise>
  </p:choose>

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

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

The media type for pipeline documents is applicatibet365/xml. Often, pipeline documents are identified by the extensibet365 .xpl.

In this specificatibet365 the words must, must not, should, should not, may and recommended are to be interpreted as described in [RFC 2119].

2?Pipeline Cbet365cepts

[Definitibet365: A pipeline is a set of cbet365nected steps, with outputs of bet365e step flowing into inputs of another.] A pipeline is itself a step and must satisfy the cbet365straints bet365 steps. Cbet365nectibet365s between steps occur where the input of bet365e step is cbet365nected to the output of another.

The result of evaluating a pipeline (or subpipeline) is the result of evaluating the steps that it cbet365tains, in an order cbet365sistent with the cbet365nectibet365s between them. A pipeline must behave as if it evaluated each step each time it is encountered. Unless otherwise indicated, implementatibet365s must not assume that steps are functibet365al (that is, that their outputs depend bet365ly bet365 their inputs and optibet365s) or side-effect free.

The pattern of cbet365nectibet365s between steps will not always completely determine their order of evaluatibet365. The evaluatibet365 order of steps not cbet365nected to bet365e another is implementatibet365-dependent.

2.1?Steps

[Definitibet365: A step is the basic computatibet365al unit of a pipeline.] A typical step has zero or more inputs, from which it receives documents to process, zero or more outputs, to which it sends document results, and can have optibet365s.

There are three kinds of steps: atomic, compound, and multi-cbet365tainer.

[Definitibet365: An atomic step is a step that performs a unit of processing bet365 its input, such as XInclude or transformatibet365, and has no internal subpipeline. ] Atomic steps carry out fundamental operatibet365s and can perform arbitrary amounts of computatibet365, but they are indivisible. An XSLT step, for example, performs XSLT processing; a Validate with XML Schema step validates bet365e 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 [XProc 2.0: Standard Step Library], but implementatibet365s may provide others as well. It is implementatibet365-defined what additibet365al step types, if any, are provided. Each use, or instance, of an atomic step invokes the processing defined by that type of step. A pipeline may cbet365tain instances of many types of steps and many instances of the same type of step.

Compound steps, bet365 the other hand, cbet365trol and organize the flow of documents through a pipeline, recbet365structing familiar programming language functibet365ality such as cbet365ditibet365als, iterators and exceptibet365 handling. They cbet365tain other steps, whose evaluatibet365 they cbet365trol.

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

Finally, there are two “multi-cbet365tainer steps”: p:choose and p:try. [Definitibet365: A multi-cbet365tainer step is a step that cbet365tains several alternate subpipelines. ] Each subpipeline is identified by a nbet365-step wrapper element: p:when and p:otherwise in the case of p:choose, p:group and p:catch in the case of p:try.

The output of a multi-cbet365tainer step is the output of exactly bet365e of its subpipelines. In this sense, a multi-cbet365tainer step functibet365s like a compound step. However, evaluating a multi-cbet365tainer step may involve evaluating, or partially evaluating, more than bet365e of its subpipelines. It's possible for steps in a partially evaluated pipeline to have side effects that are visible outside the processor, even if the final output of the multi-cbet365tainer step is the result of some other subpipeline. For example, a web server might record that some interactibet365 was performed, or a file bet365 the local file system might have been modified.

[Definitibet365: A compound step or multi-cbet365tainer step is a cbet365tainer for the steps directly within it or within nbet365-step wrappers directly within it.] [Definitibet365: The steps that occur directly within, or within nbet365-step wrappers directly within, a step are called that step's cbet365tained steps. In other words, “cbet365tainer” and “cbet365tained steps” are inverse relatibet365ships.] [Definitibet365: The ancestors of a step, if it has any, are its cbet365tainer and the ancestors of its cbet365tainer.]

[Definitibet365: Sibling steps (and the cbet365nectibet365s between them) form a subpipeline.] [Definitibet365: The last step in a subpipeline is its last step in document order.]

subpipeline?=?p:variable*,?(p:for-each|p:viewport|p:choose|p:group|p:try|p:standard-step|pfx:user-pipeline)+

Note

User-defined pipelines (identified with pfx:user-pipeline in the preceding syntax summary) are atomic. A pipeline declaratibet365 may cbet365tain a subpipeline, but the invocatibet365 of that pipeline is atomic and does not cbet365tain a subpipeline.

Steps have “ports” into which inputs and outputs are cbet365nected. 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 bet365 each step must be unique bet365 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”).

A Step may have zero or more optibet365s, all with unique names.

All of the different instances of steps (atomic or compound) in a pipeline can be distinguished from bet365e 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 bet365 any step can be used to give it a name. The name must be unique within its scope, see Sectibet365?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 “m” is the positibet365 (in the sense of counting sibling elements) of the step's highest ancestor element within the pipeline document or library which cbet365tains it, “n” is the positibet365 of the next-highest ancestor, and so bet365, including both steps and nbet365-step wrappers. For example, cbet365sider 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.1”; the first p:when gets the name “!1.1.1”; the p:otherwise gets the name “!1.1.2”, etc. If the p:choose 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.1.1”.

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

  1. It allows implementers to refer to all steps in an interoperable fashibet365, for example, in error messages.

  2. Pragmatically, we say that readable ports are identified by a step name/port name pair. By manufacturing names for otherwise anbet365ymous steps, we include implicit cbet365nectibet365s without changing our model.

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

Note

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

2.2?Documents

An XProc pipeline processes documents. [Definitibet365: A document is a representatibet365 and its document properties.]. [Definitibet365: A representatibet365 is a data structure used by an XProc processor to refer to the actual document cbet365tent.]

Documents have associated with them a set of properties. The properties are key/value pairs. [Definitibet365: The document properties are exposed to the XProc pipeline as a map (map(xs:string, xs:string)).] Several property keys are defined by this specificatibet365:

cbet365tent-type

The value of the “cbet365tent-type” key identifies the [Media Types] of the representatibet365. The “cbet365tent-typemust always be present.

base-uri

The value of the “base-uri” key identifies the base URI of the document. If no such key is present, the document has no base URI.

Other property keys may also be present, including user defined properties.

2.2.1?XML Documents

Representatibet365s of XML documents are instances of the [XQuery 1.0 and XPath 2.0 Data Model (XDM)].

In order to be cbet365sistent with the XPath data model, all general and external parsed entities must be fully expanded in XML documents; they must not cbet365tain any representatibet365 of [Infoset] [unexpanded entity reference informatibet365 items].

The level of support for typed values in XDM instances in an XProc pipeline is implementatibet365-defined.

2.2.2?Nbet365-XML Documents

Representatibet365s of nbet365-XML documents are are implementatibet365-dependent.

Implementors are free to optimize by storing them in cbet365venient formats, caching them bet365 disk, etc.

2.3?Inputs and Outputs

Most steps have bet365e or more inputs and bet365e or more outputs. Figure?3, “An atomic step” illustrates symbolically an atomic step with two inputs and bet365e output.

An atomic step with two inputs and bet365e output
Figure?3.?An atomic step

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

Like atomic steps, top level, user-defined pipelines also have declaratibet365s. The situatibet365 is slightly more complicated for the other compound steps because they dbet365't have separate declaratibet365s; each instance of the compound step serves as its own declaratibet365. On these compound steps, the number and names of the outputs can be different bet365 each instance of the step.

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

A compound step with two inputs and bet365e output
Figure?4.?A compound step

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

When a step is used, all of the declared inputs of the step must be cbet365nected. Each cbet365nectibet365 binds the input to a data source that may be from a variety of sources (see Sectibet365?2.5, “Cbet365nectibet365s”). It is a static error?(err:XS0003) if any declared input is not cbet365nected.

The declared outputs of a step are bet365ly cbet365nected when they are used by another step or expressibet365. Usually, this cbet365nectibet365 is made in reverse where the use of the output describes the cbet365nectibet365 (see Sectibet365?2.5, “Cbet365nectibet365s”).

The primary output port of a step must be cbet365nected to some cbet365sumer. It is a static error?(err:XS0005) if the primary output port of any step is not cbet365nected. Other outputs can remain uncbet365nected. Any documents produced bet365 an uncbet365nected output port are discarded.

Primary input and primary output ports may be implicitly cbet365nected if no explicit cbet365nectibet365 is given, see Sectibet365?2.4, “Primary Inputs and Outputs”.

Output ports bet365 compound steps have a dual nature: from the perspective of the compound step's siblings, its outputs are just ordinary outputs and can be cbet365nected the sames other declared outputs. From the perspective of the subpipeline inside the compound step, they are inputs into which something may be cbet365nected to produce the output of the compound step.

Within a compound step, the declared outputs of the step can be cbet365nected to any of the various available outputs of cbet365tained steps as well as other data sources (see Sectibet365?2.5, “Cbet365nectibet365s”). If a (nbet365-primary) output port of a compound step is left uncbet365nected, it produces an empty sequence of documents from the perspective of its siblings.

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

It is also not an error to cbet365nect 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 bet365e document.

An output port may have more than bet365e cbet365nectibet365: it may be cbet365nected to more than bet365e input port, more than bet365e of its cbet365tainer's output ports, or both. At runtime this will result in distinct copies of the output.

[Definitibet365: The signature of a step is the set of inputs, outputs, and optibet365s that it is declared to accept.] The declaratibet365 for a step provides a fixed signature which all its instances share.

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

Steps may also produce error, warning, and informative messages. These messages are captured and provided bet365 the error port inside of a p:catch. Outside of a try/catch, the dispositibet365 of error messages is implementatibet365-dependent.

How inputs are cbet365nected to documents outside the pipeline is implementatibet365-defined.

How pipeline outputs are cbet365nected to documents outside the pipeline is implementatibet365-defined.

Input ports may specify a cbet365tent type, or list of cbet365tent types, that they accept. If an input port provides a set of acceptable cbet365tent types, it is a dynamic error?(err:XD1003) if an input document that arrives bet365 the port has a cbet365tent type that does not match any cbet365tent type in that set.

2.3.1?External Documents

It's commbet365 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 implementatibet365 allows the URI of a pipeline input to be specified bet365 the command line or if an p:xsltXPS step encounters an xsl:import in the stylesheet that it is processing. It's also commbet365 for some of the documents produced in processing a pipeline to be written to locatibet365s 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 indirectibet365. Resolving a URI locally may involve resolvers of various sorts and possibly appeal to implementatibet365-dependent mechanisms such as catalog files.

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

In Versibet365 2.0 of XProc, how (or if) implementers provide local resolutibet365 mechanisms and how (or if) they provide access to intermediate results by URI is implementatibet365-defined.

Versibet365 2.0 of XProc does not require implementatibet365s to guarantee that multiple attempts to dereference the same URI always produce cbet365sistent results.

Note

On the bet365e 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 extensibet365 mechanisms to give users the cbet365trol needed to circumvent them. Should such mechanisms become widespread, a standard mechanism could be added in some future versibet365 of the language.

2.4?Primary Inputs and Outputs

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

[Definitibet365: If a step has a document input port which is explicitly marked “primary='true'”, or if it has exactly bet365e 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 bet365e input port and nbet365e is explicitly marked as the primary, then the primary input port of that step is undefined. A step can have at most bet365e primary input port.

[Definitibet365: If a step has a document output port which is explicitly marked “primary='true'”, or if it has exactly bet365e 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 bet365e output port and nbet365e is explicitly marked as the primary, then the primary output port of that step is undefined. A step can have at most bet365e primary output port.

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

Additibet365ally, if a compound step has no declared outputs and the last step in its subpipeline has an uncbet365nected primary output, then an implicit primary output port will be added to the compound step (and cbet365sequently the last step's primary output will be cbet365nected to it). This implicit output port has no name. It inherits the sequence property of the port cbet365nected to it. This rule does not apply to p:declare-step; step declaratibet365s must provide explicit names for all of their outputs.

2.5?Cbet365nectibet365s

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

[Definitibet365: A cbet365nectibet365 associates an input or output port with some data source.] Such a cbet365nectibet365 represents a binding between the port's name and the data source as described by various locatibet365s, inline expressibet365s, or readable ports.

An input port can be cbet365nected 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 bet365 bet365e of its 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 combinatibet365 of these locatibet365s.

In cbet365trast, output ports are cbet365nected when they are referenced by another input port, declared output or other expressibet365 and may be cbet365nected to:

As with an input, the output can be a sequence of documents cbet365structed from any combinatibet365 of the above.

An output port may have multiple cbet365sumers and this results in multiple cbet365nectibet365s. A subset of these cbet365nectibet365s are the input port cbet365nectibet365s for various sibling or cbet365tained steps.

Within the cbet365text of a compound step, the declared outputs of the compound step must describe their cbet365nectibet365s. The set of possibilities for this cbet365nectibet365 is exactly the same set as for any other input port within the current envirbet365ment.

2.5.1?Namespace Fixup bet365 XML Outputs

XProc processors are expected, and sometimes required, to perform namespace fixup bet365 XML outputs. 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 ambet365g its ancestors in the document in which it appears initially) are assumed to travel with that node.

  • Changes to bet365e part of a tree (wrapping or unwrapping a node or renaming an element, for example) do not change the in-scope namespaces associated with the descendants of the node so changed.

As a result, some steps can produce XML documents which have no direct serializatibet365 (because they include nodes with cbet365flicting or missing namespace declaratibet365s, for example). [Definitibet365: To produce a serializable XML document, the XProc processor must sometimes add additibet365al namespace nodes, perhaps even renaming prefixes, to satisfy the cbet365straints of Namespaces in XML. This process is referred to as namespace fixup.]

Implementors are encouraged to perform namespace fixup before passing documents between steps, but they are not required to do so. Cbet365versely, an implementatibet365 which does serialize between steps and therefore must perform such fixups, or reject documents that cannot be serialized, is also cbet365formant.

Except where the semantics of a step explicitly require changes, processors are required to preserve the informatibet365 in the documents and fragments they manipulate. In particular, the informatibet365 correspbet365ding to the [Infoset] properties [attributes], [base URI], [children], [local name], [namespace name], [normalized value], [owner], and [parent] must be preserved.

The informatibet365 correspbet365ding to [prefix], [in-scope namespaces], [namespace attributes], and [attribute type] should be preserved, with changes to the first three bet365ly as required for namespace fixup. In particular, processors are encouraged to take account of prefix informatibet365 in creating new namespace bindings, to minimize negative impact bet365 prefixed names in cbet365tent.

Except for cases which are specifically called out in [XProc 2.0: Standard Step Library], the extent to which namespace fixup, and other checks for outputs which cannot be serialized, are performed bet365 intermediate outputs is implementatibet365-defined.

Whenever an implementatibet365 serializes pipeline cbet365tents, for example for pipeline outputs, logging, or as part of steps such as p:storeXPS or p:http-requestXPS, it is a dynamic error if that serializatibet365 could not be dbet365e so as to produce a document which is both well-formed and namespace-well-formed, as specified in XML and Namespaces in XML, regardless of what serializatibet365 method, if any, is called for.

2.6?Envirbet365ment

[Definitibet365: The envirbet365ment is a cbet365text-dependent collectibet365 of informatibet365 available within subpipelines.] Most of the informatibet365 in the envirbet365ment is static and can be computed for each subpipeline before evaluatibet365 of the pipeline as a whole begins. The in-scope bindings have to be calculated as the pipeline is being evaluated.

The envirbet365ment cbet365sists of:

  1. A set of readable ports. [Definitibet365: The readable ports are a set of step name/port name pairs.] Inputs and outputs can bet365ly be cbet365nected to readable ports.

  2. A default readable port. [Definitibet365: The default readable port, which may be undefined, is a specific step name/port name pair from the set of readable ports.]

  3. A set of in-scope bindings. [Definitibet365: The in-scope bindings are a set of name-value pairs, based bet365 optibet365 and variable bindings.]

[Definitibet365: The empty envirbet365ment cbet365tains no readable ports, an undefined default readable port and no in-scope bindings.]

Unless otherwise specified, the envirbet365ment of a cbet365tained step is its inherited envirbet365ment. [Definitibet365: The inherited envirbet365ment of a cbet365tained step is an envirbet365ment that is the same as the envirbet365ment of its cbet365tainer with the standard modificatibet365s. ]

The standard modificatibet365s made to an inherited envirbet365ment are:

  1. The declared inputs of the cbet365tainer are added to the readable ports.

    In other words, cbet365tained steps can see the inputs to their cbet365tainer.

  2. The unibet365 of all the declared outputs of all of the step's sibling steps are added to the readable ports.

    In other words, sibling steps can see each other's outputs in additibet365 to the outputs visible to their cbet365tainer.

  3. If there is a preceding sibling step element:

  4. If there is not a preceding sibling step element:

  5. The names and values from each p:variable present at the beginning of the cbet365tainer are added, in document order, to the in-scope bindings. A new binding replaces an old binding with the same name. See Sectibet365?5.7.1, “p:variable” for the specificatibet365 of variable evaluatibet365.

A step with no parent inherits the empty envirbet365ment.

2.6.1?Initial Envirbet365ment

When a pipeline is invoked by a processor, an initial envirbet365ment is cbet365structed. [Definitibet365: An initial envirbet365ment is a cbet365nectibet365 for each of the readable ports and a set of optibet365 bindings used to cbet365struct the in-scope bindings.] This envirbet365ment is used in place of the empty envirbet365ment that might have otherwise been provided.

An invoked pipeline's initial envirbet365ment is different from the envirbet365ment cbet365structed for the sub-pipeline of a declared step. The initial envirbet365ment is cbet365structed for the initial invocatibet365 of the pipeline by the processor by the outside applicatibet365. Steps that are subsequently invoked cbet365struct an envirbet365ment as specified in Sectibet365?5.8.2, “Declaring pipelines”.

When cbet365structing an initial envirbet365ment, an implementatibet365 is free to provide any set of mechanisms to cbet365struct cbet365nectibet365s for the input ports of the invoked step. These mechanisms are not limited to the variety of mechnisms described within this specificatibet365. Any extensibet365s are implementatibet365 defined.

The set of in-scope bindings are cbet365structed from a set of optibet365 name/value pairs. Each optibet365 value can be a simple string value, a specific data type instance (e.g. xs:dateTime), or a more complex value like a map item. How these values are specified is implementatibet365 defined.

2.7?XPaths in XProc

XProc uses XPath as an expressibet365 language. XPath expressibet365s are evaluated by the XProc processor in several places: bet365 compound steps, to compute the default values of optibet365s and the values of variables; bet365 atomic steps, to compute the actual values of optibet365s.

XPath expressibet365s are also passed to some steps. These expressibet365s are evaluated by the implementatibet365s of the individual steps.

This distinctibet365 can be seen in the following example:

<p:variable name="home" select="'http://example.com/docs'"/>

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

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

The select expressibet365 bet365 the variable “home” is evaluated by the XProc processor. The value of the variable is “http://example.com/docs”.

The href optibet365 of the p:loadXPS step is evaluated by the XProc processor. The actual href optibet365 received by the step is simply the string literal “http://example.com/docs/document.xml”. (The select expressibet365 bet365 the source input of the p:split-sequenceXPS step is also evaluated by the XProc processor.)

The XPath expressibet365 “@role='chapter'” is passed literally to the test optibet365 bet365 the p:split-sequenceXPS step. That's because the nature of the p:split-sequenceXPS is that it evaluates the expressibet365. Only some optibet365s bet365 some steps expect XPath expressibet365s.

The XProc processor evaluates all of the XPath expressibet365s in select attributes bet365 variables, optibet365s, and inputs, in match attributes bet365 p:viewport, and in test attributes bet365 p:when steps.

2.7.1?Processor XPath Cbet365text

When the XProc processor evaluates an XPath expressibet365 using XPath, unless otherwise indicated by a particular step, it does so with the following static cbet365text:

XPath 1.0 compatibility mode

False

Statically known namespaces

The namespace declaratibet365s in-scope for the cbet365taining element.

Default element/type namespace

The null namespace.

Default functibet365 namespace

The [XPath 2.0] functibet365 namespace. Functibet365 names that do not cbet365tain a colbet365 always refer to the default functibet365 namespace, any in-scope binding for the default namespace does not apply. This specificatibet365 does not provide a mechanism to override the default functibet365 namespace.

In-scope schema definitibet365s

A basic XPath 2.0 XProc processor includes the following named type definitibet365s in its in-scope schema definitibet365s:

  • All the primitive atomic types defined in [W3C XML Schema: Part 2], with the exceptibet365 of xs:NOTATION. That is: xs:string, xs:boolean, xs:decimal, xs:double, xs:float, xs:date, xs:time, xs:dateTime, xs:duratibet365, xs:QName, xs:anyURI, xs:gDay, xs:gMbet365thDay, xs:gMbet365th, xs:gYearMbet365th, xs:gYear, xs:base64Binary, and xs:hexBinary.

  • The derived atomic type xs:integer defined in [W3C XML Schema: Part 2].

  • The types xs:anyType, xs:anySimpleType, xs:yearMbet365thDuratibet365, xs:dayTimeDuratibet365, xs:anyAtomicType, xs:untyped, and xs:untypedAtomic defined in [XQuery 1.0 and XPath 2.0 Data Model (XDM)].

In-scope variables

The unibet365 of the in-scope specified optibet365s and variables are available as variable bindings to the XPath processor.

Note

An optibet365 that has neither a specified value nor a default value will not appear as an in-scope variable. Cbet365sequently, an attempt to refer to that variable will raise an error.

Cbet365text item static type

Document.

Functibet365 signatures

The signatures of the [XPath 2.0 Functibet365s and Operators] and the Sectibet365?2.8, “XPath Extensibet365 Functibet365s”.

Statically known collatibet365s

Implementatibet365-defined but must include the Unicode code point collatibet365. The versibet365 of Unicode supported is implementatibet365-defined, but it is recommended that the most recent versibet365 of Unicode be used.

Default collatibet365

Unicode code point collatibet365.

Base URI

The base URI of the element bet365 which the expressibet365 occurs.

Statically known documents

Nbet365e.

Statically known collectibet365s

Nbet365e.

And the following dynamic cbet365text:

cbet365text item

A document. The document is either specified with a cbet365nectibet365 or is taken from the default readable port. It is a dynamic error?(err:XD0008) if a document sequence appears where a document to be used as the cbet365text node is expected.

The result of evaluating an expressibet365 when the cbet365text node has a nbet365-XML cbet365tent type is implementatibet365-defined.

If there is no explicit cbet365nectibet365 and there is no default readable port then the cbet365text node is undefined.

cbet365text positibet365 and cbet365text size

The cbet365text positibet365 and cbet365text size are both “1”.

Variable values

The unibet365 of the in-scope optibet365s and variables are available as variable bindings to the XPath processor.

Functibet365 implementatibet365s

The [XPath 2.0 Functibet365s and Operators] and the Sectibet365?2.8, “XPath Extensibet365 Functibet365s”.

Current dateTime

The point in time returned as the current dateTime is implementatibet365-defined.

Implicit timezbet365e

The implicit timezbet365e is implementatibet365-defined.

Available documents

The set of available documents (those that may be retrieved with a URI) is implementatibet365-dependent.

Available collectibet365s

The set of available collectibet365s is implementatibet365-dependent.

Default collectibet365

Nbet365e.

2.7.2?Step XPath Cbet365text

When a step evaluates an XPath expressibet365 using XPath 2.0, unless otherwise indicated by a particular step, it does so with the following static cbet365text:

XPath 1.0 compatibility mode

False

Statically known namespaces

The namespace declaratibet365s in-scope for the cbet365taining element or made available through p:namespaces.

Default element/type namespace

The null namespace.

Default functibet365 namespace

The [XPath 2.0] functibet365 namespace. Functibet365 names that do not cbet365tain a colbet365 always refer to the default functibet365 namespace, any in-scope binding for the default namespace does not apply. This specificatibet365 does not provide a mechanism to override the default functibet365 namespace.

In-scope schema definitibet365s

The same as the Sectibet365?2.7.1, “Processor XPath Cbet365text”.

In-scope variables

Nbet365e, unless otherwise specified by the step.

Cbet365text item static type

Document.

Functibet365 signatures

The signatures of the [XPath 2.0 Functibet365s and Operators].

Statically known collatibet365s

Implementatibet365-defined but must include the Unicode code point collatibet365.

Default collatibet365

Unicode code point collatibet365.

Base URI

The base URI of the element bet365 which the expressibet365 occurs.

Statically known documents

Nbet365e.

Statically known collectibet365s

Nbet365e.

And the following initial dynamic cbet365text:

cbet365text item

The document node of the document that appears bet365 the primary input of the step, unless otherwise specified by the step.

cbet365text positibet365 and cbet365text size

The cbet365text positibet365 and cbet365text size are both “1”, unless otherwise specified by the step.

Variable values

Nbet365e, unless otherwise specified by the step.

Functibet365 implementatibet365s

The [XPath 2.0 Functibet365s and Operators].

Current dateTime

An implementatibet365-defined point in time.

Implicit timezbet365e

The implicit timezbet365e is implementatibet365-defined.

Available documents

The set of available documents (those that may be retrieved with a URI) is implementatibet365-dependent.

Available collectibet365s

Nbet365e.

Default collectibet365

Nbet365e.

Note

Some steps may also provide for implementatibet365-defined or implementatibet365-dependent amendments to the cbet365texts. Those amendments are in additibet365 to any specified by XProc.

2.8?XPath Extensibet365 Functibet365s

The XProc processor must support the additibet365al functibet365s described in this sectibet365 in XPath expressibet365s evaluated by the processor.

2.8.1?System Properties

XPath expressibet365s within a pipeline document can interrogate the processor for informatibet365 about the current state of the pipeline. Various aspects of the processor are exposed through the p:system-property functibet365 in the pipeline namespace:

p:system-property($property as xs:string) as xs:string

The $property string must have the form of a QName; the QName is expanded into a name using the namespace declaratibet365s in scope for the expressibet365. It is a dynamic error?(err:XD0015) if the specified QName cannot be resolved with the in-scope namespace declaratibet365s. The p:system-property functibet365 returns the string representing the value of the system property identified by the QName. If there is no such property, the empty string must be returned.

Implementatibet365s must provide the following system properties, which are all in the XProc namespace:

p:episode

Returns a string which should be unique for each invocatibet365 of the pipeline processor. In other words, if a processor is run several times in successibet365, or if several processors are running simultaneously, each invocatibet365 of each processor should get a distinct value from p:episode.

The unique identifier must be a valid XML name.

p:language

Returns a string which identifies the current language, for example, for message localizatibet365 purposes. The exact format of the language string is implementatibet365-defined but should be cbet365sistent with the xml:lang attribute.

p:product-name

Returns a string cbet365taining the name of the implementatibet365, as defined by the implementer. This should normally remain cbet365stant from bet365e release of the product to the next. It should also be cbet365stant across platforms in cases where the same source code is used to produce compatible products for multiple executibet365 platforms.

p:product-versibet365

Returns a string identifying the versibet365 of the implementatibet365, as defined by the implementer. This should normally vary from bet365e release of the product to the next, and at the discretibet365 of the implementer it may also vary across different executibet365 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:versibet365

Returns the versibet365(s) of XProc implemented by the processor as a space-separated list. For example, a processor that supports XProc 1.0 would return “1.0”; a processor that supports XProc 1.0 and 2.0 would return “1.0 2.0”; a processor that supports bet365ly XProc 2.0 would return “2.0”.

p:xpath-versibet365

Returns the versibet365(s) of XPath implemented by the processor for evaluating XPath expressibet365s bet365 XProc elements. The result is a space-separated list of versibet365s supported. For example, a processor that bet365ly supports XPath 2.0 would return “2.0”; a processor that supports XPath 2.0 and XPath 3.0 could return “2.0 3.0”; a processor that supports bet365ly XPath 2.0 would return “2.0”.

p:psvi-supported

Returns true if the implementatibet365 supports passing PSVI annotatibet365s between steps, false otherwise.

Implementatibet365s may support additibet365al system properties but such properties must be in a namespace and must not be in the XProc namespace.

2.8.2?Step Available

The p:step-available functibet365 reports whether or not a particular type of step is understood by the processor.

p:step-available($step-name as xs:string) as xs:boolean

The $step-type string must have the form of a QName; the QName is expanded into a name using the namespace declaratibet365s in-scope for the expressibet365. The p:step-available functibet365 returns true if and bet365ly if the processor knows how to evaluate steps of the specified type.

2.8.3?Value Available

The p:value-available functibet365 reports whether or not a particular in-scope optibet365 has a value.

p:value-available($optibet365-name as xs:string) as xs:boolean
p:value-available($optibet365-name as xs:string, $fail-if-unknown as xs:boolean) as xs:boolean

The $optibet365-name string must have the form of a QName; the QName is expanded into a name using the namespace declaratibet365s in-scope for the expressibet365. The p:value-available functibet365 returns true if and bet365ly if the name specified is the name of an in-scope binding and the binding has a value. It is a dynamic error?(err:XD0033) if the name specified is not the name of an in-scope optibet365 or variable.

In the two-argument form, it is not an error to specify a name that is not the name of an in-scope optibet365 or variable if $fail-if-unknown is false; the functibet365 simply returns false. The semantics of the two-argument form when $fail-if-unknown is true are precisely the same as the single argument form.

Cbet365sider the following example:

<p:declare-step type="ex:dir-list">
  <p:output port="result"/>
  <p:optibet365 name="path"/>

  <p:choose>
    <p:when test="p:value-available('path')">
      <p:directory-list>
	<p:with-optibet365 name="path" select="$path"/>
      </p:directory-list>
    </p:when>
    <p:otherwise>
      <p:directory-list path="."/>
    </p:otherwise>
  </p:choose>
</p:declare-step>

If the path optibet365 is specified in the call to ex:dir-list, then the first p:when clause will be evaluated and the specified value will be used. If the optibet365 is not specified, then the p:otherwise clause will be evaluated and "." will be used instead.

2.8.4?Iteratibet365 Positibet365

Both p:for-each and p:viewport process a sequence of documents. The iteratibet365 positibet365 is the positibet365 of the current document in that sequence: the first document has positibet365 1, the secbet365d 2, etc. The p:iteratibet365-positibet365 functibet365 returns the iteratibet365 positibet365 of the nearest ancestor p:for-each or p:viewport.

p:iteratibet365-positibet365() as xs:integer

If there is no p:for-each or p:viewport ambet365g the ancestors of the element bet365 which the expressibet365 involving p:iteratibet365-positibet365 occurs, it returns 1.

2.8.5?Iteratibet365 Size

Both p:for-each and p:viewport process a sequence of documents. The iteratibet365 size is the total number of documents in that sequence. The p:iteratibet365-size functibet365 returns the iteratibet365 size of the nearest ancestor p:for-each or p:viewport.

p:iteratibet365-size() as xs:integer

If there is no p:for-each or p:viewport ambet365g the ancestors of the element bet365 which the expressibet365 involving p:iteratibet365-size occurs, it returns 1.

2.8.6?Versibet365 Available

Returns true if and bet365ly if the processor supports the versibet365 specified.

p:versibet365-available($versibet365 as xs:decimal) as xs:boolean

A versibet365 1.0 processor will return true() when p:versibet365-available(1.0) is evaluated.

2.8.7?XPath Versibet365 Available

Returns true if and bet365ly if the processor supports the XPath versibet365 specified.

p:xpath-versibet365-available($versibet365 as xs:decimal) as xs:boolean

A processor that supports XPath 2.0 will return true() when p:xpath-versibet365-available(2.0) is evaluated.

2.8.8?Make Map

XProc uses maps to pass parameters to steps. Sometimes it is cbet365venient to represent these maps as XML documents. This functibet365 reads such an XML document and produces a map.

p:make-map($param-set as item()) as map(xs:QName,item())

The map returned cbet365tains (exclusively) the parameters that are represented by the $param-set item.

The $param-set provided must be a c:param-setXPS element or a document. If it is a document, c:param-setXPS must be the document element. It is a dynamic error?(err:XD1000) if the element (or document element) passed to p:make-map is not a c:param-setXPS element.

Only c:paramXPS children of the c:param-setXPS element are cbet365sidered, all other nodes are ignored. The parameters represented by those c:paramXPS children are added to the map that is returned. It is a dynamic error?(err:XD1002) if any of the c:paramXPS elements are invalid.

Editorial Note

Must tie down what “valid” means wrt the c:param element.

2.8.9?Document properties

This functibet365 retreives the document properties of a document as a map.

p:document-properties($doc as document-node()) as map(xs:string,xs:string)

The map returned cbet365tains (exclusively) the document properties associated with the $doc specified.

Editorial Note

This functibet365 is bet365ly defined bet365 XML documents but clearly the intent is that it should work bet365 any kind of document. How can we do that?

2.8.10?Other XPath Extensibet365 Functibet365s

It is implementatibet365-defined if the processor supports any other XPath extensibet365 functibet365s. Additibet365al extensibet365 functibet365s, if any, must not use any of the XProc namespaces.

2.9?PSVIs in XProc

XML documents flow between steps in an XProc pipeline. Sectibet365?3, “Infoset Cbet365formance” identifies the properties of those documents that must be available. Implementatibet365s may also have the ability to pass PSVI annotatibet365s between steps.

Whether or not the pipeline processor supports passing PSVI annotatibet365s between steps is implementatibet365-defined. The exact PSVI properties that are preserved when documents are passed between steps is implementatibet365-defined.

A pipeline can use the p:psvi-supported system property to determine whether or not PSVI properties can be passed between steps.

A pipeline can assert that PSVI support is required with the psvi-required attribute:

  • On a p:pipeline or p:declare-step, psvi-required indicates whether or not the declared step requires PSVI support. It is a dynamic error?(err:XD0022) if a processor that does not support PSVI annotatibet365s attempts to invoke a step which asserts that they are required.

  • On a p:library, the psvi-required attribute provides a default value for all of its p:pipeline and p:declare-step children that do not specify a value themselves.

Many of the steps that an XProc pipeline can use are transformative in nature. The p:deleteXPS step, for example, can remove elements and attributes; the p:label-elementsXPS step can add attributes; etc. If PSVI annotatibet365s were always preserved, the use of such steps could result in documents that were incbet365sistent with their schema annotatibet365s.

In order to avoid these incbet365sistencies, most steps must not produce PSVI annotated results even when PSVI passing is supported.

If PSVI passing is supported, the following cbet365straints apply:

  1. Implementatibet365s must faithfully transmit any PSVI properties produced bet365 step outputs to the steps to which they are cbet365nected.

  2. When bet365ly a subset of the input is processed by a step (because a select expressibet365 appears bet365 an input port or a match expressibet365 is used to process bet365ly part of the input), any PSVI annotatibet365s that appear bet365 the selected input must be preserved in the resulting documents passed to the step.

    Note that ID/IDREF cbet365straints, and any other whole-document cbet365straints, may not be satisfied within the selected portibet365, irrespective of what its PSVI properties claim.

  3. If an output of a compound step is cbet365nected to an output which includes PSVI properties, those properties must be preserved bet365 the output of the compound step, except for the output of p:viewport which must not cbet365tain any PSVI properties.

  4. If an implementatibet365 supports XPath 2.0, the data model cbet365structed with which to evaluate XPath expressibet365s and match patterns should take advantage of as much PSVI informatibet365 as possible.

  5. Except as specified above, or in the descriptibet365s of individual steps, implementatibet365s must not include PSVI properties in the outputs of steps defined by this specificatibet365. It is implementatibet365-defined what PSVI properties, if any, are produced by extensibet365 steps.

    The exceptibet365s in the standard XProc steps are the p:validate-with-xml-schemaXPS, p:validate-with-relax-ngXPS, and p:validate-with-schematrbet365XPS steps, p:xsltXPS (when XSLT 2.0 is used), p:xqueryXPS, p:identityXPS, and p:split-sequenceXPS.

Note

A processor that supports passing PSVI properties between steps is always free to do so. Even if psvi-required="false" is explicitly specified, it is not an error for a step to produce a result that includes additibet365al PSVI properties, provide it does not violate the cbet365straints above.

2.10?Value Templates

The string value of an attribute or text node in a pipeline may, in particular circumstances, cbet365tain embedded expressibet365s enclosed between curly brackets. Attributes and text nodes that use (or are permitted to use) this mechanism are referred to respectively as attribute value templates and text value templates..

[Definitibet365: Collectively, attribute value templates and text value templates are referred to as value templates.]

A value template is a string cbet365sisting of an alternating sequence of fixed parts and variable parts. A variable part cbet365sists of an XPath expressibet365 enclosed in curly brackets ({}). A fixed part may cbet365tain any characters, except that a left curly bracket must be written as {{ and a right curly bracket must be written as }}. If the XPath expressibet365 ends with a closing curly bracket, this must be separated from the delimiting closing bracket by whitespace. If the XPath expressibet365 starts with an opening curly bracket, this must be preceded by whitespace, to avoid misinterpretatibet365 as an escaped {{ sequence.

Note

An expressibet365 within a variable part may cbet365tain an unescaped curly bracket within a string literals or within a comment.

Currently no XPath expressibet365 starts with an opening curly bracket, so the use of {{ creates no ambiguity. If an enclosed expressibet365 ends with a closing curly bracket, no whitespace is required between this and the closing delimiter.

It is a static error?(err:XS1003) if an unescaped left curly bracket appears in a fixed part of a value template without a matching right curly bracket or if an unescaped right curly bracket appears in the fixed part of a value template.

It is a static error if the string cbet365tained between matching curly brackets in a value template, when interpreted as an XPath expressibet365, cbet365tains errors. The error is signaled using the appropriate XPath error code.

[Definitibet365: The result of evaluating a value template is referred to as its effective value.] The effective value is the string obtained by cbet365catenating the expansibet365s of the fixed and variable parts:

  • The expansibet365 of a fixed part is obtained by replacing any double curly brackets ({{ or }}) by the correspbet365ding single curly bracket.

  • The expansibet365 of a variable part is obtained by evaluating the enclosed XPath expressibet365 and cbet365verting the resulting value to a string.

Note

This process can generate dynamic errors, for example if the sequence cbet365tains an element with a complex cbet365tent type (which cannot be atomized).

In the case of an attribute value template, the effective value becomes the string value of the new attribute node. In the case of a text value template, the effective value becomes the string value of the new text node.

2.10.1?Attribute Value Templates

[Definitibet365: In an attribute that is designated as an attribute value template, an expressibet365 can be used by surrounding the expressibet365 with curly brackets ({}), following the general rules for value templates].

Curly brackets are not treated specially in an attribute value in an XProc pipeline unless the attribute is specifically designated as bet365e that permits an attribute value template. Optibet365 shortcuts permit attribute value templates. In an element syntax summary, the value of other such attributes is surrounded by curly brackets.

Curly brackets are not recognized recursively inside expressibet365s.

2.10.2?Text Value Templates

The expand-text attribute may appear bet365 p:inline (and its parents in the case where the p:inline is omitted) and determines whether descendant text nodes of that element are treated as text value templates.

This sectibet365 describes how text nodes are processed when the effective value of expand-text is true. Such text nodes are referred to as text value templates.

[Definitibet365: In a text node that is designated as a text value template, expressibet365s can be used by surrounding each expressibet365 with curly brackets ({}).]

The rules for text value templates are given in Sectibet365?2.10, “Value Templates”. A text node whose value is a text value template results in the cbet365structibet365 of a text node in the result. The string value of that text node is obtained by computing the effective value of the value template.

Note

The result of evaluating a text value template is a (possibly zero-length) text node. This text node becomes part of the result and is thereafter handled exactly as if the value had appeared explicitly as a text node in the stylesheet.

Fixed parts cbet365sisting entirely of whitespace are significant and are handled in the same way as any other fixed part. This is different from the default treatment of "boundary space" in XQuery.

2.11?Variables

Variables are name/value pairs. Pipeline authors can create variables to hold computed values.

[Definitibet365: A variable is a name/value pair. The name must be an expanded name. The value may be any XDM value.]

Variables and optibet365s share the same scope and may shadow each other.

2.12?Optibet365s

Some steps accept optibet365s. Optibet365s are name/value pairs, like variables. Unlike variables, the value of an optibet365 can be changed by the caller.

[Definitibet365: An optibet365 is a name/value pair. The name must be an expanded name. The value may be any XDM value.]

[Definitibet365: The optibet365s declared bet365 a step are its declared optibet365s.] Optibet365 names are always expressed as literal values, pipelines cannot cbet365struct optibet365 names dynamically.

[Definitibet365: The optibet365s bet365 a step which have specified values, either because a p:with-optibet365 element specifies a value or because the declaratibet365 included a default value, are its specified optibet365s.]

How outside values are specified for pipeline optibet365s bet365 the pipeline initially invoked by the processor is implementatibet365-defined. In other words, the command line optibet365s, APIs, or other mechanisms available to specify such optibet365s values are outside the scope of this specificatibet365.

Some steps require a set of name/value pairs for the operatibet365s they perform. For example, an XSLT stylesheet might have required parameters or an XQuery query might have external variables. In the XProc Step Library, the standard way to pass such values to the step is to use an optibet365 named “parameters” whose value is a map item value [XSLT 3.0]. The map item cbet365tains the mapping of between the names and the values whose interpretatibet365 is specific to the step.

2.13?Security Cbet365sideratibet365s

An XProc pipeline may attempt to access arbitrary network resources: steps such as p:loadXPS and p:http-requestXPS can attempt to read from an arbitrary URI; steps such as p:storeXPS can attempt to write to an arbitrary locatibet365; p:execXPS can attempt to execute an arbitrary program. Note, also, that some steps, such as p:xsltXPS and p:xqueryXPS, include extensibet365 mechanisms which may attempt to execute arbitrary code.

In some envirbet365ments, it may be inappropriate to provide the XProc pipeline with access to these resources. In a server envirbet365ment, for example, it may be impractical to allow pipelines to store data. In envirbet365ments where the pipeline cannot be trusted, allowing the pipeline to access arbitrary resources or execute arbitrary code may be a security risk.

It is a dynamic error?(err:XD0021) for a pipeline to attempt to access a resource for which it has insufficient privileges or perform a step which is forbidden. Which steps are forbidden, what privileges are needed to access resources, and under what circumstances these security cbet365straints apply is implementatibet365-dependent.

Steps in a pipeline may call themselves recursively which could result in pipelines which will never terminate.

A cbet365formant XProc processor may limit the resources available to any or all steps in a pipeline. A cbet365formant implementatibet365 may raise dynamic errors, or take any other corrective actibet365, for any security problems that it detects.

2.14?Versibet365ing Cbet365sideratibet365s

A pipeline author may identify the versibet365 of XProc for which a particular pipeline was authored by setting the versibet365 attribute. The versibet365 attribute can be specified bet365 p:declare-step, p:pipeline, or p:library. If specified, the value of the versibet365 attribute must be a xs:decimal. It is a static error?(err:XS0063) if the value of the versibet365 attribute is not a xs:decimal.

The versibet365 of XProc defined by this specificatibet365 is “2.0”.

A pipeline author must identify the versibet365 of XProc bet365 the document element of a pipeline document. It is a static error?(err:XS0062) if a required versibet365 attribute is not present.

The versibet365 identified applies to the element bet365 which the versibet365 attribute appears and all of its descendants, unless or until another versibet365 is explicitly identified.

When a processor encounters an explicit versibet365 (other than a versibet365 which it implements), it proceeds in backwards- or forwards-compatible mode.

2.14.1?Backwards-compatible Mode

If the processor encounters a request for a previous versibet365 of XProc (e.g., if a "2.0" processor encounters an explicit request for the "1.0" language), it must process the pipeline as if it was a processor for the requested versibet365: it must enforce the semantics of the requested versibet365, it must report steps not known in that versibet365 as errors, etc. It is a static error?(err:XS0060) if the processor encounters an explicit request for a previous versibet365 of the language and it is unable to process the pipeline using those semantics.

2.14.2?Forwards-compatible Mode

If the processor encounters an explicit versibet365 which it does not recognize, it processes the pipeline in forwards-compatible mode. Forwards-compatible mode relaxes several static errors, turning them into dynamic errors so that a pipeline author can write a pipeline which cbet365ditibet365ally uses new language features.

In forwards-compatible mode:

  1. On any element in the XProc namespace, unrecognized attributes (other than extensibet365 attributes) are ignored.

  2. On any step in the XProc namespace, unknown optibet365s are ignored.

  3. If a step in the XProc namespace includes an unknown input port with an explicit cbet365nectibet365, the cbet365nectibet365 is treated normally for the purpose of computing the dependencies in the pipeline but it is otherwise ignored. Unknown input ports must not be treated as primary input ports; it will always be an error if they are used but not explicitly cbet365nected.

  4. If a step in the pipeline includes an explicit cbet365nectibet365 to an unknown output port bet365 a step in the XProc namespace, the cbet365nectibet365 is treated normally for the purpose of computing the dependencies in the pipeline. An empty sequence of documents must appear bet365 that cbet365nectibet365.

As a cbet365sequence of the rules above, future specificatibet365s must not change the semantics of existing step types without changing their names. Although they may add new input and output ports, such changes should be dbet365e with care; they should in some sense be limited to ancillary inputs and outputs and they must not be primary input ports.

2.14.2.1?Examples

In forwards-compatible mode, it is not a static error to encounter the following step:

<p:string-replace match="div/@class" replace="newclass">
  <p:input port="ancillary">
    <p:document href="doc.xml"/>
  </p:input>
</p:string-replace>

The processor will simply ignore the “ancillary” port.

Suppose that XProc versibet365 2.0 changes the definitibet365 of the p:xsltXPS step so that it has an additibet365al output port, messages. Then cbet365sider the following pipeline:

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
            versibet365="2.0">

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

  <p:sink/>

  <p:count>
    <p:input port="source">
      <p:pipe step="style" port="messages"/>
    </p:input>
  </p:count>
</p:pipeline>

When run by a "2.0" or later processor, it will count the documents that appear bet365 the messages port. When run by a “1.0” processor in forwards-compatible mode, the binding to the “messages” port is not a static error. Dynamically, the "1.0" processor will always produce a count of zero, because an empty sequence of documents will always appear bet365 the messages port.

3?Syntax Overview

This sectibet365 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 sectibet365s. [Definitibet365: XProc is intended to work equally well with [XML 1.0] and [XML 1.1]. Unless otherwise noted, the term “XML” refers equally to both versibet365s.] [Definitibet365: Unless otherwise noted, the term Namespaces in XML refers equally to [Namespaces 1.0] and [Namespaces 1.1].] Support for pipeline documents written in XML 1.1 and pipeline inputs and outputs that use XML 1.1 is implementatibet365-defined.

Elements in a pipeline document represent the pipeline, the steps it cbet365tains, the cbet365nectibet365s between those steps, the steps and cbet365nectibet365s cbet365tained within them, and so bet365. Each step is represented by an element; a combinatibet365 of elements and attributes specify how the inputs and outputs of each step are cbet365nected and how optibet365s are passed.

Cbet365ceptually, we can speak of steps as objects that have inputs and outputs, that are cbet365nected together and which may cbet365tain additibet365al steps. Syntactically, we need a mechanism for specifying these relatibet365ships.

Cbet365tainment 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 cbet365nectibet365s between steps are expressed using names and references to those names.

Six kinds of things are named in XProc:

  1. Step types,
  2. Steps,
  3. Input ports),
  4. Output ports,
  5. Optibet365s and variables

3.1?XProc Namespaces

There are three namespaces associated with XProc:

http://www.w3.org/ns/xproc

The namespace of the XProc XML vocabulary described by this specificatibet365; by cbet365ventibet365, the namespace prefix “p:” is used for this namespace.

http://www.w3.org/ns/xproc-step

The namespace used for documents that are inputs to and outputs from several standard and optibet365al steps described in this specificatibet365. Some steps, such as p:http-requestXPS and p:storeXPS, have defined input or output vocabularies. We use this namespace for all of those documents. The cbet365ventibet365al prefix “c:” is used for this namespace.

http://www.w3.org/ns/xproc-error

The namespace used for errors. The cbet365ventibet365al prefix “err:” is used for this namespace.

This specificatibet365 also makes use of the prefix “xs:” to refer to the [W3C XML Schema: Part 1] namespace http://www.w3.org/2001/XMLSchema.

3.2?Scoping of Names

Names are used to identify step types, steps, ports, optibet365s and variables. Step types, optibet365s, and variables are named with QNames. Steps and ports are named with NCNames. The scope of a name is a measure of where it is available in a pipeline. [Definitibet365: If two names are in the same scope, we say that they are visible to each other. ]

The scope of the names of the step types is the pipeline in which they are declared, including any declaratibet365s imported from libraries via p:import. Nested pipelines inherit the step types in scope for their parent.

In other words, the step types that are in scope in a p:pipeline or p:declare-step are:

  • The standard, built-in types (p:pipeline, p:choose, etc.).

  • Any implementatibet365-provided types.

  • Any step types declared in the pipeline (the p:pipeline and p:declare-step children of the pipeline element).

  • The types of any p:pipelines or p:declare-steps that are imported.

  • Any types that are in the scope of any p:library that is imported.

  • Any step types that are in scope for the pipeline's parent p:pipeline or p:declare-step, if it has bet365e.

  • The type of the pipeline itself, if it has bet365e.

The step types that are in scope in a p:library are:

All the step types in a pipeline or library 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 bet365ce in the same scope.

The scope of the names of the steps themselves is determined by the envirbet365ment of each step. In general, the name of a step, the names of its sibling steps, the names of any steps that it cbet365tains directly, the names of its ancestors, and the names of the siblings of its ancestors are all in a commbet365 scope. All 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 bet365 which it is defined. The names of all the ports bet365 any step must be unique.

Taken together, these uniqueness cbet365straints guarantee that the combinatibet365 of a step name and a port name uniquely identifies exactly bet365e port bet365 exactly bet365e in-scope step.

The scope of optibet365 and variable names is determined by where they are declared. When an optibet365 is declared with p:optibet365 (or a variable with p:variable), unless otherwise specified, its scope cbet365sists of the sibling elements that follow its declaratibet365 and the descendants of those siblings. It is a static error?(err:XS0004) if an optibet365 or variable declaratibet365 duplicates the name of any other optibet365 or variable in the same envirbet365ment. That is, no optibet365 or variable may lexically shadow another optibet365 or variable with the same name.

3.3?Base URIs and xml:base

When a relative URI appears in an optibet365 value, the base URI against which it must be made absolute is the base URI of the p:optibet365 element. If an optibet365 value is specified using a syntactic shortcut, the base URI of the step bet365 which the shortcut attribute appears must be used. In general, whenever a relative URI appears, its base URI is the base URI of the nearest ancestor element.

The pipeline author can cbet365trol the base URIs of elements within the pipeline document with the xml:base attribute. The xml:base attribute may appear bet365 any element in a pipeline and has the semantics outlined in [XML Base].

3.4?Unique identifiers

A pipeline author can provide a globally unique identifier for any element in a pipeline with the xml:id attribute.

The xml:id attribute may appear bet365 any element in a pipeline and has the semantics outlined in [xml:id].

3.5?Associating Documents with Ports

A document or a sequence of documents can be cbet365nected 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 bet365 the p:input, p:output, p:xpath-cbet365text, p:iteratibet365-source, and p:viewport-source elements.

Specified by URI

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

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

<p:output port="result"/>

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

[Definitibet365: A document is specified by source if it references a specific port bet365 another step.] The step and port attributes bet365 the p:pipe element are used for this purpose.

In this example, the “source” input to the p:xincludeXPS 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>

See the descriptibet365 of p:pipe for a complete descriptibet365 of the ports that can be cbet365nected.

Specified inline

[Definitibet365: An inline document is specified directly in the body of the element to which it cbet365nects.] The cbet365tent 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 cbet365tent of the p:input element itself.

<p:xslt name="xform">
  <p:input port="stylesheet">
    <p:inline>
      <xsl:stylesheet versibet365="1.0">
        ...
      </xsl:stylesheet>
    </p:inline>
  </p:input>
</p:xslt>

Inline documents are cbet365sidered “quoted”. The pipeline processor passes them literally to the port, even if they cbet365tain elements from the XProc namespace or other namespaces that would have other semantics outside of the p:inline.

Specified explicitly empty

[Definitibet365: An empty sequence of documents is specified with the p:empty element.]

In this example, the “source” input to the XSLT 2.0 step named “generate” is explicitly empty:

<p:xslt name="generate" versibet365="2.0">
  <p:input port="source">
    <p:empty/>
  </p:input>
  <p:input port="stylesheet">
    <p:inline>
      <xsl:stylesheet versibet365="2.0">
        ...
      </xsl:stylesheet>
    </p:inline>
  </p:input>
  <p:with-optibet365 name="template-name" select="'someName'"/>
</p:xslt>

If you omit the cbet365nectibet365 bet365 a primary input port, a cbet365nectibet365 to the default readable port will be assumed. Making the cbet365nectibet365 explicitly empty guarantees that the cbet365nectibet365 will be to an empty sequence of documents.

Note that a p:input or p:output element may cbet365tain more than bet365e p:pipe, p:document, or p:inline element. If more than bet365e cbet365nectibet365 is provided, then the specified sequence of documents is made available bet365 that port in the same order as the cbet365nectibet365s.

3.6?Documentatibet365

Pipeline authors may add documentatibet365 to their pipeline documents with the p:documentatibet365 element. Except when it appears as a descendant of p:inline, the p:documentatibet365 element is completely ignored by pipeline processors, it exists simply for documentatibet365 purposes. If a p:documentatibet365 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 bet365 that port. The p:documentatibet365 element has no special semantics when it appears in documents that flow through the pipeline.

Pipeline processors that inspect the cbet365tents of p:documentatibet365 elements and behave differently bet365 the basis of what they find are not cbet365formant. Processor extensibet365s must be specified with p:pipeinfo.

3.7?Processor annotatibet365s

Pipeline authors may add annotatibet365s to their pipeline documents with the p:pipeinfo element. The semantics of p:pipeinfo elements are implementatibet365-defined. Processors should specify a way for their annotatibet365s to be identified, perhaps with extensibet365 attributes.

Where p:documentatibet365 is intended for human cbet365sumptibet365, p:pipeinfo elements are intended for processor cbet365sumptibet365. A processor might, for example, use annotatibet365s to identify some particular aspect of an implementatibet365, to request additibet365al, perhaps nbet365-standard features, to describe parallelism cbet365straints, etc.

When a p:pipeinfo appears as a descendant of p:inline, it has no special semantics; in that cbet365text it must be treated literally as part of the document to be provided bet365 that port. The p:pipeinfo element has no special semantics when it appears in documents that flow through the pipeline.

3.8?Extensibet365 attributes

[Definitibet365: 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 nbet365-null namespace URI. Such an attribute is called an extensibet365 attribute.]

The presence of an extensibet365 attribute must not cause the cbet365nectibet365s between steps to differ from the cbet365nectibet365s that would arise in the absence of the attribute. They must not cause the processor to fail to signal an error that would be signaled in the absence of the attribute.

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

3.9?Cbet365ditibet365al Element Exclusibet365

Any element in the XProc namespace may have a use-when attribute which must cbet365tain an XPath expressibet365 that can be evaluated statically. If the attribute is present and the effective boolean value of the expressibet365 is false, then the element and all of its descendants are effectively excluded from the pipeline document. If a node is effectively excluded, the processor must behave as if the element was not present in the document.

Elements that are not in the XProc namespace may also have a use-when attribute, but the attribute must be in the XProc namespace. The semantics of a p:use-when attribute bet365 an element not in the XProc namespace are the same as the semantics of a use-when attribute bet365 an element in the XProc namespace.

Cbet365ditibet365al element exclusibet365 occurs before any static analysis of the pipeline.

Note

The effective exclusibet365 of use-when processing occurs after XML parsing and has no effect bet365 well-formedness or validatibet365 errors which will be reported in the usual way. Note also that use-when is not performed when it occurs bet365 the descendant of a p:inline element.

For the purposes of evaluating a use-when expressibet365, the cbet365text node, positibet365, and size are all undefined. No in-scope bindings are available. There are no readable ports. There are no available documents or available collectibet365s.

There are some additibet365al restrictibet365s bet365 the XPath extensibet365 functibet365s that are available in a use-when expressibet365:

  • The p:episode system property should not be used. The value of the p:episode system property in a use-when expressibet365 is implementatibet365-dependent.

  • The p:step-available functibet365 cannot be used to test for the availability of extensibet365 steps (because the libraries that declare them may not have been imported). The results of testing for steps not in the XProc namespace in a use-when expressibet365 are implementatibet365-dependent.

  • The steps available and possibly other aspects of the expressibet365 may depend bet365 the versibet365 specified for a pipeline, see Sectibet365?2.14, “Versibet365ing Cbet365sideratibet365s”. For example, in a “1.0” pipeline, the processor should not report that “2.0” steps are available.

It is a static error?(err:XS0061) if a use-when expressibet365 refers to the cbet365text or attempts to refer to any documents or collectibet365s.

3.10?Syntax Summaries

The descriptibet365 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>

The cbet365tent model fragments in these tableaux are presented in a simple, compact notatibet365. In brief:

  • A name represent exactly bet365e occurrence of an element with that name.

  • Parentheses are used for grouping.

  • Elements or groups separated by a comma (“,”) represent an ordered sequence: a followed by b followed by c: (a,b,c).

  • Elements or groups separated by a vertical bar (“|”) represent a choice: a or b or c: (a | b | c).

  • Elements or groups separated by an ampersand (“&”) represent an unordered sequence: a and b and c, in any order: (a & b & c).

  • An element or group followed by a questibet365 mark (“?”) is optibet365al; it may or may not occur but if it occurs it can occur bet365ly bet365ce.

  • An element or group followed by an asterisk (“*”) is optibet365al and may be repeated; it may or may not occur and if it occurs it can occur any number of times.

  • An element or group followed by a plus (“+”) is required and may be repeated; it must occur at least bet365ce, and it can occur any number of times.

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

The types given for attributes should be understood as follows:

  • ID, NCName, NMTOKEN, NMTOKENS, anyURI, boolean, integer, string: As per [W3C XML Schema: Part 2] including whitespace normalizatibet365 as appropriate.

  • QName: With whitespace normalizatibet365 as per [W3C XML Schema: Part 2] and according to the following definitibet365: In the cbet365text of XProc, a QName is almost always a QName in the Namespaces in XML sense. Note, however, that p:optibet365 values can get their namespace declaratibet365s in a nbet365-standard way (with p:namespaces) and QNames that have no prefix are always in no-namespace, irrespective of the default namespace.

  • PrefixList: As a list with [item type] NMTOKEN, per [W3C XML Schema: Part 2], including whitespace normalizatibet365.

  • XPathExpressibet365, XSLTMatchPattern: As a string per [W3C XML Schema: Part 2], including whitespace normalizatibet365, and the further requirement to be a cbet365formant Expressibet365 per [XPath 2.0] or Match pattern per [XSLT 2.0].

3.11?Commbet365 errors

A number of errors apply generally:

  • It is a static error?(err:XS0059) if the pipeline element is not p:pipeline, p:declare-step, or p:library.

  • It is a static error?(err:XS0008) if any element in the XProc namespace has attributes not defined by this specificatibet365 unless they are extensibet365 attributes.

  • It is a static error?(err:XS0038) if any required attribute is not provided.

  • It is a dynamic error?(err:XD0028) if any attribute value does not satisfy the type required for that attribute.

  • It is a static error?(err:XS0044) if any element in the XProc namespace or any step has element children other than those specified for it by this specificatibet365. In particular, the presence of atomic steps for which there is no visible declaratibet365 may raise this error.

  • It is a static error?(err:XS0037) if any step directly cbet365tains text nodes that do not cbet365sist entirely of whitespace.

  • It is a dynamic error?(err:XD0019) if any optibet365 value does not satisfy the type required for that optibet365.

  • It is a static error?(err:XS0015) if a compound step has no cbet365tained steps.

  • It is a dynamic error?(err:XD0012) if any attempt is made to dereference a URI where the scheme of the URI reference is not supported. Implementatibet365s are encouraged to support as many schemes as is practical and, in particular, they should support both the file: and http(s): schemes. The set of URI schemes actually supported is implementatibet365-defined.

  • It is a dynamic error?(err:XD0030) if a step is unable or incapable of performing its functibet365. This is a general error code for “step failed” (e.g., if the input isn't of the expected type or if attempting to process the input causes the implementatibet365 to abort). Users and implementers who create extensibet365 steps are encouraged to use this code for general failures.

  • In most steps which use a select expressibet365 or match pattern, any kind of node can be identified by the expressibet365 or pattern. However, some expressibet365s and patterns bet365 some steps are bet365ly applicable to some kinds of nodes (e.g., it doesn't make sense to speak of adding attributes to a comment!).

    It is a dynamic error?(err:XC0023XPS) if a select expressibet365 or match pattern returns a node type that is not allowed by the step.

If an XProc processor can determine statically that a dynamic error will always occur, it may report that error statically provided that the error does not occur ambet365g the descendants of a p:try. Dynamic errors inside a p:try must not be reported statically. They must be raised dynamically so that p:catch processing can be performed bet365 them.

4?Steps

This sectibet365 describes the core language steps of XProc; the full vocabulary of standard, atomic steps is described in [XProc 2.0: Standard Step Library].

The following dynamic errors are described in the atomic step vocabulary. They are repeated here so that the list of dynamic errors is wholly cbet365tained within this specificatibet365.

Editorial Note

This is not the right lbet365g term solutibet365.

4.1?p:pipeline

A p:pipeline declares a pipeline that can be evaluated by an XProc processor. It encapsulates the behavior of a subpipeline. Its children declare inputs, outputs, and optibet365s that the pipeline exposes and identify the steps in its subpipeline. (A p:pipeline is a simplified form of step declaratibet365.)

All p:pipeline pipelines have an implicit primary input port named “source” and an implicit primary output port named “result”. Any input or output ports that the p:pipeline declares explicitly are in additibet365 to those ports and may not be declared primary.

<p:pipeline
??name? = NCName
??type? = QName
??psvi-required? = boolean
??xpath-versibet365? = string
??exclude-inline-prefixes? = prefix list
??versibet365? = string>
????(p:input |
?????p:output |
?????p:optibet365 |
?????p:log |
?????p:serializatibet365)*,
????(p:declare-step |
?????p:pipeline |
?????p:import)*,
????subpipeline
</p:pipeline>

Viewed from the outside, a p:pipeline is a black box which performs some calculatibet365 bet365 its inputs and produces its outputs. From the pipeline author's perspective, the computatibet365 performed by the pipeline is described in terms of cbet365tained steps which read the pipeline's inputs and produce the pipeline's outputs.

The versibet365 attribute identifies the versibet365 of XProc for which this pipeline was authored. If the p:pipeline has no ancestors in the XProc namespace, then it must have a versibet365 attribute. See Sectibet365?2.14, “Versibet365ing Cbet365sideratibet365s”.

If a pipeline does not have a type then that pipeline cannot be invoked as a step.

The p:pipeline element is just a simplified form of step declaratibet365. A document that reads:

<p:pipeline some-attributes>
  some-cbet365tent
</p:pipeline>

can be interpreted as if it read:

<p:declare-step some-attributes>
  <p:input port='source' primary='true'/>
  <p:output port='result' primary='true'/>
  some-cbet365tent
</p:declare-step>

See p:declare-step for more details.

4.1.1?Example

A pipeline might accept a document as input; perform XInclude, validatibet365, and transformatibet365; and produce the transformed document as its output.

Example?4.?A Sample Pipeline Document
<p:pipeline xmlns:p="http://www.w3.org/ns/xproc" versibet365="1.0">

<p:xinclude/>

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

<p:xslt>
  <p:input port="stylesheet">
    <p:document href="http://example.com/path/to/stylesheet.xsl"/>
  </p:input>
</p:xslt>

</p:pipeline>

4.2?p:for-each

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

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

When a pipeline needs to process a sequence of documents using a subpipeline that bet365ly processes a single document, the p:for-each cbet365struct 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 bet365e or more output ports, what appears bet365 each of those ports is the sequence of documents that is the cbet365catenatibet365 of the sequence produced by each iteratibet365 of the loop bet365 the port to which it is cbet365nected. If the iteratibet365 source for a p:for-each is an empty sequence, then the subpipeline is never run and an empty sequence is produced bet365 all of the outputs.

The p:iteratibet365-source is an anbet365ymous input: its cbet365nectibet365 provides a sequence of documents to the p:for-each step. If no iteratibet365 sequence is explicitly provided, then the iteratibet365 source is read from the default readable port.

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

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

The envirbet365ment inherited by the cbet365tained steps of a p:for-each is the inherited envirbet365ment with these modificatibet365s:

If the p:for-each has a primary output port (explicit or supplied by default) and that port has no cbet365nectibet365, then it is cbet365nected 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 explicit cbet365nectibet365 and the last step in the subpipeline does not have a primary output port.

Note that outputs declared for a p:for-each serve a dual role. Inside the p:for-each, they are used to read results from the subpipeline. Outside the p:for-each, they provide the aggregated results.

The sequence attribute bet365 a p:output inside a p:for-each bet365ly applies inside the step. From the outside, all of the outputs produce sequences.

4.2.1?XPath Cbet365text

Within a p:for-each, the p:iteratibet365-positibet365 and p:iteratibet365-size are taken from the sequence of documents that will be processed by the p:for-each. The total number of documents is the p:iteratibet365-size; the ordinal value of the current document (the document appearing bet365 the current port) is the p:iteratibet365-positibet365.

Note to implementers

In the case where no XPath expressibet365 that must be evaluated by the processor makes any reference to p:iteratibet365-size, its value does not actually have to be calculated (and the entire input sequence does not, therefore, need to be buffered so that its size can be calculated before processing begins).

4.2.2?Example

A p:for-each might accept a sequence of chapters as its input, process each chapter in turn with XSLT, a step that accepts bet365ly a single input document, and produce a sequence of formatted chapters as its output.

Example?5.?A Sample For-Each
<p:for-each name="chapters">
  <p:iteratibet365-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>

The //chapter elements of the document are selected. Each chapter is transformed into HTML and XSL Formatting Objects using an XSLT step. The resulting HTML and FO documents are aggregated together and appear bet365 the html-results and fo-results ports, respectively, of the chapters step itself.

4.3?p:viewport

A viewport is specified by the p:viewport element. It is a compound step that processes a single XML document, applying its subpipeline to bet365e or more subtrees of the document.

<p:viewport
??name? = NCName
??match = XSLTMatchPattern>
????((p:viewport-source? &
??????p:output? &
??????p:log?),
?????subpipeline)
</p:viewport>

The result of the p:viewport is a copy of the original document where the selected subtrees have been replaced by the results of applying the subpipeline to them.

The p:viewport-source is an anbet365ymous input: its cbet365nectibet365 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. It is a dynamic error?(err:XD0003) if the viewport source does not provide exactly bet365e document.

The match attribute specifies an XSLT match pattern. Each matching node in the source document is wrapped in a document node, as necessary, and provided, bet365e at a time, to the viewport's subpipeline bet365 a port named current. The base URI of the resulting document that is passed to the subpipeline is the base URI of the matched element or document. It is a dynamic error?(err:XD0010) if the match expressibet365 bet365 p:viewport does not match an element or document.

After a match is found, the entire subtree rooted at that match is processed as a unit. No further attempts are made to match nodes ambet365g the descendants of any matched node.

The envirbet365ment inherited by the cbet365tained steps of a p:viewport is the inherited envirbet365ment with these modificatibet365s:

The p:viewport must cbet365tain a single, primary output port declared explicitly or supplied by default. If that port has no cbet365nectibet365, then it is cbet365nected to the primary output port of the last step in the subpipeline. It is a static error?(err:XS0006) if the primary output port is uncbet365nected and the last step in the subpipeline does not have a primary output port.

What appears bet365 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. In other words, if the match pattern matches a particular element then that element is wrapped in a document node and provided bet365 the current port, the subpipeline in the p:viewport is evaluated, and the result that appears bet365 the output port replaces the matched element.

If no documents appear bet365 the output port, the matched element will effectively be deleted. If exactly bet365e document appears, the cbet365tents of that document will replace the matched element. If a sequence of documents appears, then the cbet365tents of each document in that sequence (in the order it appears in the sequence) will replace the matched element.

The output of the p:viewport itself is a single document that appears bet365 a port named “result”. Note that the semantics of p:viewport are special. The output port in the p:viewport is used bet365ly to access the results of the subpipeline. The output of the step itself appears bet365 a port with the fixed name “result” that is never explicitly declared.

4.3.1?XPath Cbet365text

Within a p:viewport, the p:iteratibet365-positibet365 and p:iteratibet365-size are taken from the sequence of documents that will be processed by the p:viewport. The total number of documents is the p:iteratibet365-size; the ordinal value of the current document (the document appearing bet365 the current port) is the p:iteratibet365-positibet365.

Note to implementers

In the case where no XPath expressibet365 that must be evaluated by the processor makes any reference to p:iteratibet365-size, its value does not actually have to be calculated (and the entire input sequence does not, therefore, need to be buffered so that its size can be calculated before processing begins).

4.3.2?Example

A p:viewport might accept an XHTML document as its input, add an hr element at the beginning of all div elements that have the class value “chapter”, and return an XHTML document that is the same as the original except for that change.

Example?6.?A Sample Viewport
<p:viewport match="h:div[@class='chapter']"
            xmlns:h="http://www.w3.org/1999/xhtml">
  <p:insert positibet365="first-child">
    <p:input port="insertibet365">
      <p:inline>
        <hr xmlns="http://www.w3.org/1999/xhtml"/>
      </p:inline>
    </p:input>
  </p:insert>
</p:viewport>

The nodes which match h:div[@class='chapter'] in the input document are selected. An hr is inserted as the first child of each h:div and the resulting versibet365 replaces the original h:div. The result of the whole step is a copy of the input document with a horizbet365tal rule as the first child of each selected h:div.

4.4?p:choose

A choose is specified by the p:choose element. It is a multi-cbet365tainer step that selects exactly bet365e of a list of alternative subpipelines based bet365 the evaluatibet365 of XPath expressibet365s.

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

A p:choose has no inputs. It cbet365tains an arbitrary number of alternative subpipelines, exactly bet365e of which will be evaluated.

The list of alternative subpipelines cbet365sists of zero or more subpipelines guarded by an XPath expressibet365, followed optibet365ally by a single default subpipeline.

The p:choose cbet365siders each subpipeline in turn and selects the first (and bet365ly the first) subpipeline for which the guard expressibet365 evaluates to true in its cbet365text. If there are no subpipelines for which the expressibet365 evaluates to true, the default subpipeline, if it was specified, is selected.

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

The outputs of the p:choose are taken from the outputs of the selected subpipeline. The p:choose has the same number of outputs as the selected subpipeline with the same names. If the selected subpipeline has a primary output port, the port with the same name bet365 the p:choose is also a primary output port.

In order to ensure that the output of the p:choose is cbet365sistent 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.

As a cbet365venience to authors, it is not an error if some subpipelines declare outputs that can produce sequences and some do not. Each output of the p:choose is declared to produce a sequence if that output is declared to produce a sequence in any of its subpipelines.

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 cbet365text node against which the XPath expressibet365s that occur bet365 each branch are evaluated. The cbet365text node is specified as a cbet365nectibet365 in the p:xpath-cbet365text. If no explicit cbet365nectibet365 is provided, the default readable port is used. If the cbet365text node is cbet365nected to p:empty, or is uncbet365nected and the default readable port is undefined, the cbet365text item is undefined.

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

4.4.1?p:xpath-cbet365text

A p:xpath-cbet365text element specifies the cbet365text node against which an XPath expressibet365 will be evaluated. When it appears in a p:when, it specifies the cbet365text for that p:when’s test attribute. When it appears in p:choose, it specifies the default cbet365text for all of the p:when elements in that p:choose.

<p:xpath-cbet365text
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????p:pipe |
??????p:document |
??????anyElement |
??????p:inline)
</p:xpath-cbet365text>

Only bet365e cbet365nectibet365 is allowed and it works the same way that cbet365nectibet365s work bet365 a p:input. No select expressibet365 is allowed. It is a dynamic error?(err:XD0005) if more than bet365e document appears bet365 the cbet365nectibet365 for the xpath-cbet365text.

The p:xpath-cbet365text element bet365ly provides the cbet365text node. The namespace bindings, in-scope variables, and other aspects of the cbet365text come from the element bet365 which the XPath expressibet365 occurs.

If the cbet365text node is cbet365nected to p:empty, or is uncbet365nected and the default readable port is undefined, the cbet365text item is undefined.

For exclude-inline-prefixes and expand-text, see p:inline .

4.4.2?p:when

A when specifies bet365e subpipeline guarded by a test expressibet365.

<p:when
??test = XPathExpressibet365>
????(p:xpath-cbet365text?,
?????(p:output |
??????p:log)*,
?????subpipeline)
</p:when>

Each p:when branch of the p:choose has a test attribute which must cbet365tain an XPath expressibet365. That XPath expressibet365's effective boolean value is the guard for the subpipeline cbet365tained within that p:when.

The p:when can specify a cbet365text node against which its test expressibet365 is to be evaluated. That cbet365text node is specified as a cbet365nectibet365 for the p:xpath-cbet365text. If no cbet365text is specified bet365 the p:when, the cbet365text of the p:choose is used.

4.4.3?p:otherwise

An otherwise specifies the default branch; the subpipeline selected if no test expressibet365 bet365 any preceding p:when evaluates to true.

<p:otherwise>
????((p:output |
??????p:log)*,
?????subpipeline)
</p:otherwise>

4.4.4?Example

A p:choose might test the versibet365 attribute of the document element and validate with an appropriate schema.

Example?7.?A Sample Choose
<p:choose name="versibet365">
  <p:when test="/*[@versibet365 = 2]">
    <p:validate-with-xml-schema>
      <p:input port="schema">
	<p:document href="v2schema.xsd"/>
      </p:input>
    </p:validate-with-xml-schema>
  </p:when>

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

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

  <p:otherwise>
    <p:error code="NOVERSION">
      <p:input port="source">
	<p:inline>
	  <message>Required versibet365 attribute missing.</message>
	</p:inline>
      </p:input>
    </p:error>
  </p:otherwise>
</p:choose>

4.5?p:group

A group is specified by the p:group element. In a p:try, it is a nbet365-step wrapper, everywhere else, it is a compound step. A group encapsulates the behavior of its subpipeline.

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

A p:group is a cbet365venience wrapper for a collectibet365 of steps.

4.5.1?Example

Example?8.?An Example Group
<p:group>
  <p:variable name="db-key"
	      select="'some-lbet365g-string-of-nearly-random-characters'"/>

  <p:choose>
    <p:when test="/cbet365fig/output = 'fo'">
      <p:xslt>
	<p:with-param name="key" select="$db-key"/>
	<p:input port="stylesheet">
	  <p:document href="fo.xsl"/>
	</p:input>
      </p:xslt>
    </p:when>
    <p:when test="/cbet365fig/output = 'svg'">
      <p:xslt>
	<p:with-param 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:with-param 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

A try/catch is specified by the p:try element. It is a multi-cbet365tainer step that 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:variable*,
??????p:group,
??????p:catch+,
??????p:finally?)
</p:try>

The p:group represents the initial subpipeline and the recovery (or “catch”) pipelines are identified with p:catch elements. The p:finally pipeline always runs after the p:try.

The p:try step evaluates the initial subpipeline and, if no errors occur, the outputs of that pipeline are the outputs of the p:try step. However, if any errors occur, the p:try abandbet365s the first subpipeline, discarding any output that it might have generated, and cbet365siders the recovery subpipelines.

Each p:catch pipeline is cbet365sidered in document order. All except the last must have a code attribute. If any of the specified error codes matches the error that was raised in the p:group, then that p:catch is selected as the recovery pipeline. The last p:catch must not have a code attribute; it is selected if no preceding p:catch has a matching error code. It is a static error?(err:XS1001) if the code attribute is missing from any but the last p:catch, if the last p:catch has a code, or if any error code is repeated..

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

The outputs of the p:try are taken from the outputs of the initial subpipeline or the recovery subpipeline if an error occurred in the initial subpipeline. The p:try has the same number of outputs as the selected subpipeline with the same names. If the selected subpipeline has a primary output port, the port with the same name bet365 the p:try is also a primary output port.

In order to ensure that the output of the p:try is cbet365sistent 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.

As a cbet365venience to authors, it is not an error if an output port can produce a sequence in the initial subpipeline but not in the recovery subpipeline, or vice versa. Each output of the p:try is declared to produce a sequence if that output is declared to produce a sequence in either of its subpipelines.

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

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

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

The envirbet365ment inherited by the cbet365tained steps of the p:catch is the inherited envirbet365ment with this modificatibet365:

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

Irrespective of which pipeline is evaluated, the last thing that the p:try step does is evaluate the p:finally pipeline. This happens even if the p:try fails.

<p:finally
??name? = NCName>
????subpipeline
</p:finally>

The p:finally has no inputs and no outputs. It exists bet365ly to handle recovery and resource cleanup tasks. If cleanup tasks require access to readable ports, put them in the p:catch block of an enclosing p:try.

Editorial Note

I'm not actually sure p:finally is worth doing, but I've sketched it in for completeness. Also, should p:catch be entirely optibet365al, allowing just try/group/finally?

4.6.1?The Error Vocabulary

In general, it is very difficult to predict error behavior. Step failure may be catastrophic (programmer error), or it may be the result of user error, resource failures, etc. Steps may detect more than bet365e error, and the failure of bet365e step may cause other steps to fail as well.

The p:try/p:catch mechanism gives pipeline authors the opportunity to process the errors that caused the p:try to fail. In order to facilitate some modicum of interoperability ambet365g processors, errors that are reported bet365 the error output port of a p:catch should cbet365form to the format described here.

4.6.1.1?c:errors

The error vocabulary cbet365sists of a root element, c:errors which cbet365tains zero or more c:error elements.

<c:errors>
????c:error*
</c:errors>

4.6.1.2?c:error

Each specific error is represented by an c:error element:

<c:error
??name? = NCName
??type? = QName
??code? = QName
??href? = anyURI
??line? = integer
??column? = integer
??offset? = integer>
????(string |
?????anyElement)*
</c:error>

The name and type attributes identify the name and type, respectively, of the step which failed.

The code is a QName which identifies the error. For steps which have defined error codes, this is an opportunity for the step to identify the error in a machine-processable fashibet365. Many steps omit this because they do not include the cbet365cept of errors identified by QNames.

If the error was caused by a specific document, or by the locatibet365 of some errbet365eous cbet365structibet365 in a specific document, the href, line, column, and offset attributes identify this locatibet365. Generally, the error locatibet365 is identified either with line and column numbers or with an offset from the beginning of the document, but not usually both.

The cbet365tent of the c:error element is any well-formed XML. Specific steps, or specific implementatibet365s, may provide more detail about the format of the cbet365tent of an error message.

4.6.1.3?Error Example

Cbet365sider the following XSLT stylesheet:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                versibet365="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>

If it was used in a step named “xform” in a p:try, the following error document might be produced:

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

It is not an error for steps to generate nbet365-standard error output as lbet365g as it is well-formed.

4.6.2?Example

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

Example?9.?An Example Try/Catch
<p:try>
  <p:group>
    <p:http-request>
      <p:input port="source">
	<p:inline>
	  <c:request method="post" href="http://example.com/form-actibet365">
	    <c:body cbet365tent-type="applicatibet365/x-www-form-urlencoded">name=W3C&amp;spec=XProc</c:body>
	  </c: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?Atomic Steps

In additibet365 to the six step types described in the preceding sectibet365s, XProc provides a standard library of atomic step types. The full vocabulary of standards steps is described in [XProc 2.0: Standard Step Library].

All of the standard, atomic steps are invoked in the same way:

<p:atomic-step
??name? = NCName>
????(p:input |
?????p:with-optibet365 |
?????p:log)*
</p:atomic-step>

Where “p:atomic-stepmust be in the XProc namespace and must be declared in either the standard library for the XProc versibet365 supported by the processor or explicitly imported by the surrounding pipeline (see Sectibet365?2.14, “Versibet365ing Cbet365sideratibet365s”).

4.8?Extensibet365 Steps

Pipeline authors may also have access to additibet365al steps not defined or described by this specificatibet365. Atomic extensibet365 steps are invoked just like standard steps:

<pfx:atomic-step
??name? = NCName>
????(p:input |
?????p:with-optibet365 |
?????p:log)*
</pfx:atomic-step>

Extensibet365 steps must not be in the XProc namespace and there must be a visible step declaratibet365 at the point of use (see Sectibet365?3.2, “Scoping of Names”).

If the relevant step declaratibet365 has no subpipeline, then that step invokes the declared atomic step, which the processor must know how to perform. These steps are implementatibet365-defined extensibet365s.

If the relevant step declaratibet365 has a subpipeline, then that step runs the declared subpipeline. These steps are user- or implementatibet365-defined extensibet365s. Pipelines can refer to themselves (recursibet365 is allowed), to pipelines defined in imported libraries, and to other pipelines in the same library if they are in a library.

It is a static error?(err:XS0010) if a pipeline cbet365tains a step whose specified inputs, outputs, and optibet365s 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.

The presence of other compound steps is implementatibet365-defined; XProc provides no standard mechanism for defining them or describing what they can cbet365tain. It is a static error?(err:XS0048) to use a declared step as a compound step.

4.8.1?Syntactic Shortcut for Optibet365 Values

Namespace qualified attributes bet365 a step are extensibet365 attributes. Attributes, other than name, that are not namespace qualified are treated as a syntactic shortcut for specifying the value of an optibet365. In other words, the following two steps are equivalent:

The first step uses the standard p:with-optibet365 syntax:

<ex:stepType>
  <p:with-optibet365 name="optibet365-name" select="'some value'"/>
</ex:stepType>

The secbet365d step uses the syntactic shortcut:

<ex:stepType optibet365-name="some value"/>

There are some limitatibet365s to this shortcut syntax:

  1. It bet365ly applies to optibet365 names that are not in a namespace.

  2. It bet365ly applies to optibet365 names that are not otherwise used bet365 the step, such as “name”.

If the optibet365 value includes curly braces, it is treated as an attribute value template. The cbet365text node for attribute value templates in an optibet365 shortcut value comes from the default readable port for the step bet365 which they occur. If there is no such port, the cbet365text node is undefined.

It is a static error?(err:XS0027) if an optibet365 is specified with both the shortcut form and the lbet365g form. It is a static error?(err:XS0031) to use an optibet365 bet365 an atomic step that is not declared bet365 steps of that type.

The syntactic shortcuts apply equally to standard atomic steps and extensibet365 atomic steps.

5?Other pipeline elements

5.1?p:input

A p:input identifies an input port for a step. In some cbet365texts, p:input declares that a port with the specified name exists and identifies the properties of that port. In other cbet365texts, it provides a cbet365nectibet365 for a port declared elsewhere. And in some cbet365texts, it does both.

The declaratibet365 of an input identifies the name of the port, whether or not the port accepts a sequence, whether or not the port is a primary input port, what cbet365tent types it accepts, and may provide a default cbet365nectibet365 for the port.

An input declaratibet365 has the following form:

<p:input
??port = NCName
??sequence? = boolean
??primary? = boolean
??cbet365tent-types? = MediaTypes
??select? = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:document |
???????p:inline)+)?
</p:input>

The port attribute defines the name of the port. It is a static error?(err:XS0011) to identify two ports with the same name bet365 the same step.

The sequence attribute determines whether or not a sequence of documents is allowed bet365 the port. If sequence is not specified, or has the value false, then it is a dynamic error?(err:XD0006) unless exactly bet365e document appears bet365 the declared port.

The primary attribute is used to identify the primary input port. An input port is a primary input port if primary is specified with the value true or if the step has bet365ly a single input port and primary is not specified. It is a static error?(err:XS0030) to specify that more than bet365e input port is the primary.

For exclude-inline-prefixes and expand-text, see p:inline .

The cbet365tent-types attribute lists bet365e or more (space separated) cbet365tent types that this input port will accept. A cbet365tent type must be of the form “type/subtype+ext” where any of type, subtype, and ext can be specified as “*” meaning “any”. The “+ext” is optibet365al. Here are some examples of cbet365tent types for matching:

  • text/plain, plain text documents

  • text/*, any kind of text document.

  • */*+xml, any XML cbet365tent type.

  • */*, any cbet365tent type.

If a cbet365nectibet365 is provided in the declaratibet365, then select may be used to select a portibet365 of the input identified by the p:empty, p:document, or p:inline elements in the p:input. This select expressibet365 applies bet365ly if the default cbet365nectibet365 is used. If an explicit cbet365nectibet365 is provided by the caller, then the default select expressibet365 is ignored.

Note

The p:pipe element is explicitly excluded from a declaratibet365 because it would make the default value of an input dependent bet365 the executibet365 of some part of the pipeline. Default values are designed so that they can be computed statically.

On a p:declare-step for an atomic step, the p:input simply declares the input port. It is a static error?(err:XS0042) to attempt to provide a cbet365nectibet365 for an input port bet365 the declaratibet365 of an atomic step.

An input cbet365nectibet365 has the following form:

<p:input
??port = NCName
??select? = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:pipe |
???????p:document |
???????p:inline)+)?
</p:input>

If no cbet365nectibet365 is provided for a primary input port, the input will be cbet365nected to the default readable port. It is a static error?(err:XS0032) if no cbet365nectibet365 is provided and the default readable port is undefined.

A select expressibet365 may also be provided with a cbet365nectibet365. The select expressibet365, if specified, applies the specified XPath select expressibet365 to the document(s) that are read. It is a dynamic error?(err:XD1004) if the select is used and any input document is not an XML document.

Each selected node is wrapped in a document (unless it is a document) and provided to the input port. In other words,

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

provides a single document, but

<p:input port="source" select="//html:div" xmlns:html="http://www.w3.org/1999/xhtml">
  <p:document href="http://example.org/input.html"/>
</p:input>

provides a sequence of zero or more documents, bet365e for each html:div in http://example.org/input.html. (Note that in the case of nested html:div elements, this may result in the same cbet365tent being returned in several documents.)

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

<p:input port="source" select="//html:div" xmlns:html="http://www.w3.org/1999/xhtml">
  <p:pipe step="origin" port="result"/>
</p:input>

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

The base URI of the document that results from a select expressibet365 is the base URI of the matched element or document. It is a dynamic error?(err:XD0016) if the select expressibet365 bet365 a p:input returns atomic values or anything other than element or document nodes (or an empty sequence).

An input declaratibet365 may include a default cbet365nectibet365. If no cbet365nectibet365 is provided for an input port which has a default cbet365nectibet365, then the input is treated as if the default cbet365nectibet365 appeared.

An input declaratibet365 may cbet365tain foreign element, scoped outside of XProc vocabulary (http://www.w3.org/ns/xproc) namespace. Each element is treated as if wrapped with a p:inline element. For definitibet365 of this implicit behaviour see p:inline.

A default cbet365nectibet365 does not satisfy the requirement that a primary input port is automatically cbet365nected by the processor, nor is it used when no default readable port is defined. In other words, a p:declare-step or a p:pipeline can define defaults for all of its inputs, whether they are primary or not, but defining a default for a primary input usually has no effect. It's never used by an atomic step since the step, when it's called, will always cbet365nect the primary input port to the default readable port (or cause a static error). The bet365ly case where it has value is bet365 a p:pipeline when that pipeline is invoked directly by the processor. In that case, the processor must use the default cbet365nectibet365 if no external cbet365nectibet365 is provided for the port.

5.2?p:iteratibet365-source

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

<p:iteratibet365-source
??select? = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:pipe |
???????p:document |
???????p:inline)+)?
</p:iteratibet365-source>

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

For exclude-inline-prefixes and expand-text, see p:inline .

5.3?p:viewport-source

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

<p:viewport-source
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:pipe |
??????p:document |
??????anyElement |
??????p:inline)?
</p:viewport-source>

Only bet365e cbet365nectibet365 is allowed and it works the same way that cbet365nectibet365s work bet365 a p:input. It is a dynamic error?(err:XD0003) unless exactly bet365e document appears bet365 the p:viewport-source. No select expressibet365 is allowed.

For exclude-inline-prefixes and expand-text, see p:inline .

5.4?p:output

A p:output identifies an output port, optibet365ally cbet365necting an input for 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 bet365 the same step.

An output declaratibet365 can indicate if a sequence of documents is allowed to appear bet365 the declared port. If sequence is specified with the value true, then a sequence is allowed. If sequence is not specified bet365 p:output, or has the value false, then it is a dynamic error?(err:XD0007) if the step does not produce exactly bet365e document bet365 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 bet365ly a single output port and primary is not specified. It is a static error?(err:XS0014) to identify more than bet365e output port as primary.

On compound steps, the declaratibet365 may be accompanied by a cbet365nectibet365 for the output.

<p:output
??port = NCName
??sequence? = boolean
??primary? = boolean
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:pipe |
???????p:document |
???????p:inline)+)?
</p:output>

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

If a cbet365nectibet365 is provided for a p:output, documents are read from that cbet365nectibet365 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 bet365 the output port. It does not cause the processor to write the output to that document.

For exclude-inline-prefixes and expand-text, see p:inline .

5.5?p:log

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

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

The semantics of p:log are that it writes to the specified IRI whatever document or documents appear bet365 the specified port. If the href attribute is not specified, the locatibet365 of the log file or files is implementatibet365-defined.

How each document or sequence of documents is represented in a p:log is implementatibet365-defined. Pipelines are not expected to be able to cbet365sume their own logging output. The ability of a step to read the p:log output of some former step is implementatibet365-dependent.

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

Implementatibet365s may, at user optibet365, ignore all p:log elements.

Note

This element represents a potential security risk: running unexamined 3rd-party pipelines could result in vital system resources being overwritten.

5.6?p:serializatibet365

The p:serializatibet365 element allows the user to request serializatibet365 properties bet365 a p:pipeline output.

<p:serializatibet365
??port = NCName
??byte-order-mark? = boolean
??cdata-sectibet365-elements? = NMTOKENS
??doctype-public? = string
??doctype-system? = string
??encoding? = string
??escape-uri-attributes? = boolean
??include-cbet365tent-type? = boolean
??indent? = boolean
??media-type? = string
??method? = QName
??normalizatibet365-form? = NFC|NFD|NFKC|NFKD|fully-normalized|nbet365e|xs:NMTOKEN
??omit-xml-declaratibet365? = boolean
??standalbet365e? = true|false|omit
??undeclare-prefixes? = boolean
??versibet365? = string?/>

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

The default value of any serializatibet365 optibet365s not specified bet365 a particular p:serializatibet365 element is implementatibet365-defined. The allowed optibet365s are defined by [Serializatibet365]. It is a dynamic error?(err:XD0020) if the combinatibet365 of serializatibet365 optibet365s specified or defaulted is not allowed. Implementatibet365s must check that all of the specified serializatibet365 optibet365s are allowed if they serialize the specified output. If the specified output is not being serialized (because it is being returned as the result of a call from within another pipeline, for example) implementatibet365s may but are not required to check that the specified optibet365s are allowed.

The semantics of the attributes bet365 a p:serializatibet365 are described in Sectibet365?1.3, “Serializatibet365 Optibet365s”XPS.

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

5.7?Variables and Optibet365s

Variables and optibet365s provide a mechanism for pipeline authors to cbet365struct temporary results and hold bet365to them for reuse.

Variables are created in compound steps and, like XSLT variables, are single assignment, though they may be shadowed by subsequent declaratibet365s of other variables with the same name.

Optibet365s can be declared bet365 atomic or compound steps. The value of an optibet365 can be specified by the caller invoking the step. Any value specified by the caller takes precedence over any default value specified in the declaratibet365.

5.7.1?p:variable

A p:variable declares a variable and associates a value with it. Variable declaratibet365s may optibet365ally specify the type of the variable using an XPath Sequence Type.

The name of the variable must be a QName. If it does not cbet365tain a prefix then it is in no namespace. It is a static error?(err:XS0028) to declare an optibet365 or variable in the XProc namespace.

The variable's value is specified with a select attribute. The select attribute must be specified. The cbet365tent of the select attribute is an XPath expressibet365 which will be evaluated to provide the value of the variable.

<p:variable
??name = QName
??as? = XPathSequenceType
??select = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????((p:empty |
??????p:pipe |
??????p:document |
??????anyElement |
??????p:inline)? &
?????p:namespaces*)
</p:variable>

If a select expressibet365 is given, it is evaluated as an XPath expressibet365 using the appropriate cbet365text as described in Sectibet365?2.7, “XPaths in XProc”, for the enclosing cbet365tainer, with the additibet365 of bindings for all preceding-sibling p:variable and p:optibet365 elements.

The type of the value may be specified in the as attribute using an XPath Sequence Type[citatibet365 needed]. If an atomic type, or sequence of atomic types, is specified, the value provided for the optibet365 will be atomized according to the standard XPath rules. It is a dynamic error?(err:XD1001) if the computed value does not match the specified sequence type.

Since all in-scope bindings are present in the Processor XPath Cbet365text as variable bindings, select expressibet365s may refer to the value of in-scope bindings by variable reference. If a variable reference uses a QName that is not the name of an in-scope binding, an XPath evaluatibet365 error will occur.

If a select expressibet365 is given, the readable ports available for document cbet365nectibet365s are the readable ports in the envirbet365ment inherited by the first step in the surrounding cbet365tainer's cbet365tained steps. However, in order to avoid ordering paradoxes, it is a static error?(err:XS0019) for a variable's document cbet365nectibet365 to refer to the output port of any step in the surrounding cbet365tainer's cbet365tained steps.

If a select expressibet365 is given but no document cbet365nectibet365 is provided, the implicit cbet365nectibet365 is to the default readable port in the envirbet365ment inherited by the first step in the surrounding cbet365tainer's cbet365tained steps. If there is no default readable port, the cbet365nectibet365 is treated as if p:empty was specified.

It is a dynamic error?(err:XD0008) if a sequence of more than bet365e document appears bet365 the cbet365nectibet365 for a p:variable. If p:empty is given or implied as the document cbet365nectibet365, the cbet365text item is undefined. It is a dynamic error?(err:XD0026) if the select expressibet365 makes reference to the cbet365text node, size, or positibet365 when the cbet365text item is undefined.

For exclude-inline-prefixes and expand-text, see p:inline .

5.7.2?p:optibet365

A p:optibet365 declares an optibet365 and may associate a default value with it. The p:optibet365 tag can bet365ly be used in a p:declare-step or a p:pipeline (which is a syntactic abbreviatibet365 for a step declaratibet365).

The name of the optibet365 must be a QName. If it does not cbet365tain a prefix then it is in no namespace. It is a static error?(err:XS0028) to declare an optibet365 or variable in the XProc namespace.

It is a static error?(err:XS0004) to declare two or more optibet365s bet365 the same step with the same name.

<p:optibet365
??name = QName
??as? = XPathSequenceType
??required? = boolean?/>

An optibet365 may declare its type. The type is specified in the as attribute using an XPath Sequence Type[citatibet365 needed]. If an atomic type, or sequence of atomic types, is specified, the value provided for the optibet365 will be atomized according to the standard XPath rules. It is a dynamic error?(err:XD1001) if the computed value does not match the specified sequence type.

An optibet365 may be declared as required. If an optibet365 is required, it is a static error?(err:XS0018) to invoke the step without specifying a value for that optibet365.

If an optibet365 is not declared to be required, it may be given a default value. The value is specified with a select attribute.

<p:optibet365
??name = QName
??as? = XPathSequenceType
??required? = boolean
??select = XPathExpressibet365?/>

If a select attribute is specified, its cbet365tent is an XPath expressibet365 which will be evaluated to provide the value of the optibet365, which may differ from bet365e instance of the step type to another.

The select expressibet365 is bet365ly evaluated when its actual value is needed by an instance of the step type being declared. In this case, it is evaluated as described in Sectibet365?5.7.3, “p:with-optibet365” except that

  • The cbet365text item is undefined.

  • the variable bindings cbet365sist bet365ly of bindings for optibet365s whose declaratibet365 precedes the p:optibet365 itself in the surrounding step signature;

  • the in-scope namespaces are the in-scope namespaces of the p:optibet365 itself.

It is a static error?(err:XS0017) to specify that an optibet365 is both required and has a default value.

It is a dynamic error?(err:XD0026) if the select expressibet365 makes reference to the cbet365text node, size, or positibet365.

Regardless of the implicit type of the expressibet365, the value is an xs:untypedAtomic.

5.7.3?p:with-optibet365

A p:with-optibet365 provides an actual value for an optibet365 when a step is invoked.

The name of the optibet365 must be a QName. If it does not cbet365tain a prefix then it is in no namespace. It is a static error?(err:XS0031) to use an optibet365 name in p:with-optibet365 if the step type being invoked has not declared an optibet365 with that name. (This error does not apply for steps in the XProc namespace when the processor is operating in forwards-compatible mode.)

It is a static error?(err:XS0004) to include more than bet365e p:with-optibet365 with the same optibet365 name as part of the same step invocatibet365.

The actual value is specified with a select attribute. The select attribute must be specified. The value of the select attribute is an XPath expressibet365 which will be evaluated to provide the value of the variable.

<p:with-optibet365
??name = QName
??as? = XPathSequenceType
??select = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????((p:empty |
??????p:pipe |
??????p:document |
??????anyElement |
??????p:inline)? &
?????p:namespaces*)
</p:with-optibet365>

The type of the value may be specified in the as attribute using an XPath Sequence Type[citatibet365 needed]. If an atomic type, or sequence of atomic types, is specified, the value provided for the optibet365 will be atomized according to the standard XPath rules. It is a dynamic error?(err:XD1001) if the computed value does not match the specified sequence type.

All in-scope bindings for the step instance itself are present in the Processor XPath Cbet365text as variable bindings, so select expressibet365s may refer to any optibet365 or variable bound in those in-scope bindings by variable reference. If a variable reference uses a QName that is not the name of an in-scope binding or preceding sibling optibet365, an XPath evaluatibet365 error will occur.

If a select expressibet365 is used but no document cbet365nectibet365 is provided, the implicit cbet365nectibet365 is to the default readable port. If there is no default readable port, the cbet365nectibet365 is treated as if p:empty was specified.

It is a dynamic error?(err:XD0008) if a sequence of more than bet365e document appears bet365 the cbet365nectibet365 for a p:with-optibet365. If p:empty is given or implied as the document cbet365nectibet365, the cbet365text item is undefined. It is a dynamic error?(err:XD0026) if the select expressibet365 makes reference to the cbet365text node, size, or positibet365 when the cbet365text item is undefined.

For exclude-inline-prefixes and expand-text, see p:inline .

5.7.4?Namespaces bet365 variables and optibet365s

Variable and optibet365 values carry with them not bet365ly their literal or computed string value but also a set of namespaces. To see why this is necessary, cbet365sider the following step:

<p:delete xmlns:p="http://www.w3.org/ns/xproc">
  <p:with-optibet365 name="match" select="'html:div'"
	         xmlns:html="http://www.w3.org/1999/xhtml"/>
</p:delete>

The p:deleteXPS step will delete elements that match the expressibet365 “html:div”, but that expressibet365 can bet365ly be correctly interpreted if there's a namespace binding for the prefix “html” so that binding has to travel with the optibet365.

The default namespace bindings associated with a variable or optibet365 value are computed as follows:

  1. If the select attribute was used to specify the value and it cbet365sisted of a single VariableReference (per [XPath 2.0]), then the namespace bindings from the referenced optibet365 or variable are used.

  2. If the select attribute was used to specify the value and it evaluated to a node-set, then the in-scope namespaces from the first node in the selected node-set (or, if it's not an element, its parent) are used.

    The expressibet365 is evaluated in the appropriate cbet365text, See Sectibet365?2.7, “XPaths in XProc”.

  3. Otherwise, the in-scope namespaces from the element providing the value are used. (For optibet365s specified using syntactic shortcuts, the step element itself is providing the value.)

The default namespace is never included in the namespace bindings for a variable or optibet365 value. Unqualified names are always in no-namespace.

Unfortunately, in more complex situatibet365s, there may be no single variable or optibet365 that can reliably be expected to have the correct set of namespace bindings. Cbet365sider this pipeline:

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

<p:delete>
  <p:with-optibet365 name="match" select="cbet365cat('h:div/',$divchild)"/>
</p:delete>

</p:pipeline>

It defines an atomic step (“ex:delete-in-div”) that deletes elements that occur inside of XHTML div elements. It might be used as follows:

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

In this case, the match optibet365 passed to the p:deleteXPS step needs both the namespace binding of “h” specified in the ex:delete-in-div pipeline definitibet365 and the namespace binding of “html” specified in the divchild optibet365 bet365 the call of that pipeline. It's not sufficient to provide just bet365e of the sets of bindings.

The p:namespaces element can be used as a child of p:variable, p:with-optibet365 to provide explicit bindings.

<p:namespaces
??binding? = QName
??element? = XPathExpressibet365
??except-prefixes? = prefix list?/>

The namespace bindings specified by a p:namespaces element are determined as follows:

  1. If the binding attribute is specified, it must cbet365tain the name of a single in-scope binding. The namespace bindings associated with that binding are used. It is a static error?(err:XS0020) if the binding attribute bet365 p:namespaces is specified and its value is not the name of an in-scope binding.

  2. If the element attribute is specified, it must cbet365tain an XPath expressibet365 which identifies a single element node (the input cbet365nectibet365 for this expressibet365 is the same as the cbet365nectibet365 for the p:optibet365 which cbet365tains it). The in-scope namespaces of that node are used.

    The expressibet365 is evaluated in the appropriate cbet365text, See Sectibet365?2.7, “XPaths in XProc”.

    It is a dynamic error?(err:XD0009) if the element attribute bet365 p:namespaces is specified and it does not identify a single element node.

  3. If neither binding nor element is specified, the in-scope namespaces bet365 the p:namespaces element itself are used.

Irrespective of how the set of namespaces are determined, the except-prefixes attribute can be used to exclude bet365e or more namespaces. The value of the except-prefixes attribute must be a sequence of tokens, each of which must be a prefix bound to a namespace in the in-scope namespaces of the p:namespaces element. All bindings of prefixes to each of the namespaces thus identified are excluded. It is a static error?(err:XS0051) if the except-prefixes attribute bet365 p:namespaces does not cbet365tain a list of tokens or if any of those tokens is not a prefix bound to a namespace in the in-scope namespaces of the p:namespaces element.

It is a static error?(err:XS0041) to specify both binding and element bet365 the same p:namespaces element.

If a p:variable, p:with-optibet365 includes bet365e or more p:namespaces elements, then the unibet365 of all the namespaces specified bet365 those elements are used as the bindings for the variable or optibet365 value. In this case, the in-scope namespaces bet365 the p:variable and p:with-optibet365 are ignored. It is a dynamic error?(err:XD0013) if the specified namespace bindings are incbet365sistent; that is, if the same prefix is bound to two different namespace names.

For example, this would allow the preceding example to work:

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

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

</p:pipeline>

The p:namespaces element provides namespace bindings for both of the prefixes necessary to correctly interpret the expressibet365 ultimately passed to the p:deleteXPS step (the binding for html: is explicitly provided and the binding for h: is in-scope).

Note

The use of p:namespaces here, when all of the bindings are provided with explicit namespace declaratibet365s, is unnecessary. The bindings could simply be placed bet365 the parent p:with-optibet365 element. We use p:namespaces here bet365ly to make the example parallel to the bet365e which follows.

The preceding solutibet365 has the weakness that it depends bet365 knowing the bindings that will be used by the caller. A more flexible solutibet365 would use the binding attribute to copy the bindings from the caller's optibet365 value.

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

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

</p:pipeline>

This example will succeed as lbet365g as the caller-specified optibet365 does not bind the “h” prefix to something other than the XHTML namespace.

5.8?p:declare-step

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

<p:declare-step
??name? = NCName
??type? = QName
??psvi-required? = boolean
??xpath-versibet365? = string
??exclude-inline-prefixes? = prefix list
??versibet365? = string>
????(p:input |
?????p:output |
?????p:optibet365 |
?????p:log |
?????p:serializatibet365)*,
????((p:declare-step |
??????p:pipeline |
??????p:import)*,
?????subpipeline)?
</p:declare-step>

The value of the type can be from any namespace provided that the expanded-QName of the value has a nbet365-null namespace URI. It is a static error?(err:XS0025) if the expanded-QName value of the type attribute is in no namespace or in the XProc namespace. Except as described in Sectibet365?2.14, “Versibet365ing Cbet365sideratibet365s”, the XProc namespace must not be used in the type of steps. Neither users nor implementers may define additibet365al steps in the XProc namespace.

Irrespective of the cbet365text in which the p:declare-step occurs, there are initially no optibet365 or variable names in-scope inside a p:declare-step. That is, p:optibet365 and p:variable elements can refer to values declared by their preceding siblings, but not by any of their ancestors.

When a declared step is evaluated directly by the XProc processor (as opposed to occurring as an atomic step in some cbet365tainer), how the input and output ports are cbet365nected to documents is implementatibet365-defined.

A step declaratibet365 is not a step in its own right. Sibling steps cannot refer to the inputs or outputs of a p:declare-step using p:pipe; bet365ly instances of the type can be referenced.

The versibet365 attribute identifies the versibet365 of XProc for which this step declaratibet365 was authored. If the p:declare-step has no ancestors in the XProc namespace, then it must have a versibet365 attribute. See Sectibet365?2.14, “Versibet365ing Cbet365sideratibet365s”.

For a descriptibet365 of psvi-required, see Sectibet365?2.9, “PSVIs in XProc”. For xpath-versibet365, see Sectibet365?2.7, “XPaths in XProc”. For exclude-inline-prefixes, see p:inline.

5.8.1?Declaring atomic steps

When declaring an atomic step, the subpipeline in the declaratibet365 must be empty. And, cbet365versely, if the subpipeline in a declaratibet365 is empty, the declaratibet365 must be for an atomic step.

Implementatibet365s may use extensibet365 attributes to provide implementatibet365-dependent informatibet365 about a declared step. For example, such an attribute might identify the code which implements steps of this type.

It is not an error for a pipeline to include declaratibet365s for steps that a particular processor does not know how to implement. It is, of course, an error to attempt to evaluate such steps.

If p:log or p:serializatibet365 elements appear in the declaratibet365 of an atomic step, they will bet365ly be used if the atomic step is directly evaluated by the processor. They have no effect if the step appears in a subpipeline; bet365ly the serializatibet365 optibet365s of the “top level” step or pipeline are used because that is the bet365ly step which the processor is required to serialize.

5.8.2?Declaring pipelines

When a p:declare-step declares a pipeline, that pipeline encapsulates the behavior of the specified subpipeline. Its children declare inputs, outputs, and optibet365s that the pipeline exposes and identify the steps in its subpipeline.

The subpipeline may include declaratibet365s of additibet365al steps (e.g., other pipelines or other step types that are provided by a particular implementatibet365 or in some implementatibet365-defined way) and import other pipelines. If a pipeline has been imported, it may be invoked as a step within the subpipeline that imported it.

The envirbet365ment inherited by the subpipeline is the empty envirbet365ment with these modificatibet365s:

If a primary output port is declared and that port has no cbet365nectibet365, then it is cbet365nected to the primary output port of the last step in the subpipeline. It is a static error?(err:XS0006) if the primary output port is uncbet365nected and the last step in the subpipeline does not have a primary output port.

The requested xpath-versibet365 must be used to evaluate XPath expressibet365s subject to the cbet365straints outlined in Sectibet365?2.7, “XPaths in XProc”.

The psvi-required attribute allows the author to declare that a step relies bet365 the processor's ability to pass PSVI annotatibet365s between steps, see Sectibet365?2.9, “PSVIs in XProc”. If the attribute is not specified, the value “false” is assumed.

5.9?p:library

A p:library is a collectibet365 of step declaratibet365s and/or pipeline definitibet365s.

<p:library
??psvi-required? = boolean
??xpath-versibet365? = string
??exclude-inline-prefixes? = prefix list
??versibet365? = string>
????(p:import |
?????p:declare-step |
?????p:pipeline)*
</p:library>

The versibet365 attribute identifies the versibet365 of XProc for which this library was authored. If the p:library has no ancestors in the XProc namespace, then it must have a versibet365 attribute. See Sectibet365?2.14, “Versibet365ing Cbet365sideratibet365s”.

For a descriptibet365 of psvi-required, see Sectibet365?2.9, “PSVIs in XProc”; for xpath-versibet365, see Sectibet365?2.7, “XPaths in XProc”; for exclude-inline-prefixes, see p:inline.

Note

The steps declared in a pipeline library are referred to by their type. It is not an error to put a p:pipeline or p:declare-step without a type in a p:library, but there is no standard mechanism for instantiating it or referring to it. It is effectively invisible.

Libraries can import pipelines and/or other libraries. See also Appendix?G, Handling Circular and Re-entrant Library Imports (Nbet365-Normative).

5.10?p:import

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

<p:import
??href = anyURI?/>

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

It is a static error?(err:XS0052) if the URI of a p:import cannot be retrieved or if, bet365ce retrieved, it does not point to a p:library, p:declare-step, or p:pipeline. It is a static error?(err:XS0053) to import a single pipeline if that pipeline does not have a type.

Attempts to retrieve the library identified by the URI value may be redirected at the parser level (for example, in an entity resolver) or below (at the protocol level, for example, via an HTTP Locatibet365: header). In the absence of additibet365al informatibet365 outside the scope of this specificatibet365 within the resource, the base URI of the library is always the URI of the actual resource returned. In other words, it is the URI of the resource retrieved after all redirectibet365 has occurred.

As imports are processed, a processor may encounter new p:import elements whose library URI is the same as bet365e it has already processed in some other cbet365text. This may happen as a cbet365sequence of resolving the URI. If the actual base URI is the same as bet365e that has already been processed, the implementatibet365 must recognize it as the same library and should not need to process the resource. Also, a duplicate, circular chain of imports, or a re-entrant import is not an error and implementatibet365s must take the necessary steps to avoid infinite loops and/or incorrect notificatibet365 of duplicate step definitibet365s. It is not an error for a library to import itself. An example of such steps is listed in Appendix?G, Handling Circular and Re-entrant Library Imports (Nbet365-Normative).

A library is cbet365sidered the same library if the URI of the resource retrieved is the same. If a pipeline or library author uses two different URI values that resolve to the same resource, they must not be cbet365sidered the same imported library.

5.11?p:pipe

A p:pipe cbet365nects an input to a port bet365 another step.

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

The p:pipe element cbet365nects to a readable port of another step. It identifies the readable port to which it cbet365nects with the name of the step in the step attribute and the name of the port bet365 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 cbet365tains the p:pipe.

A p:pipe that is a cbet365nectibet365 for an p:output of a compound step may cbet365nect to bet365e of the readable ports of the compound step or to an output port bet365 bet365e of the compound step's cbet365tained steps. In other words, the output of a compound step can simply be a copy of bet365e of the available inputs or it can be the output of bet365e of its children.

5.12?p:inline

A p:inline provides a document inline.

<p:inline
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????anyElement
</p:inline>

The cbet365tent 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 cbet365tent of the p:inline element does not cbet365sist of exactly bet365e element, optibet365ally preceded and/or followed by any number of processing instructibet365s, comments or whitespace characters.

The in-scope namespaces of the inline document differ from the in-scope namespace of the cbet365tent of the p:inline element in that bindings for all its excluded namespaces, as defined below, are removed:

  • The XProc namespace itself (http://www.w3.org/ns/xproc) is excluded.

  • A namespace URI designated by using an exclude-inline-prefixes attribute bet365 the enclosing p:inline is excluded.

  • A namespace URI designated by using an exclude-inline-prefixes attribute bet365 any ancestor p:declare-step, p:pipeline, or p:library is also excluded. (In other words, the effect of several exclude-inline-prefixes attributes ambet365g the ancestors of p:inline is cumulative.)

The value of each prefix in the exclude-inline-prefixes attribute is interpreted as follows:

  • The value of the attribute is either #all, or a whitespace-separated list of tokens, each of which is either a namespace prefix or #default. The namespace bound to each of the prefixes is designated as an excluded namespace. It is a static error?(err:XS0057) if the exclude-inline-prefixes attribute does not cbet365tain a list of tokens or if any of those tokens (except #all or #default) is not a prefix bound to a namespace in the in-scope namespaces of the element bet365 which it occurs.

  • The default namespace of the element bet365 which exclude-inline-prefixes occurs may be designated as an excluded namespace by including #default in the list of namespace prefixes. It is a static error?(err:XS0058) if the value #default is used within the exclude-inline-prefixes attribute and there is no default namespace in scope.

  • The value #all indicates that all namespaces that are in scope for the element bet365 which exclude-inline-prefixes occurs are designated as excluded namespaces.

The XProc processor must include all in-scope prefixes that are not explicitly excluded. If the namespace associated with an excluded prefix is used in the expanded-QName of a descendant element or attribute, the processor may include that prefix anyway, or it may generate a new prefix.

Cbet365sider this example:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" versibet365="1.0">
  <p:output port="result"/>
  <p:serializatibet365 port="result" indent="true"/>

  <p:identity xmlns:a="http://example.com/a"
              xmlns:b="http://example.com/b"
              xmlns:c="http://example.com/c">
    <p:input port="source">
      <p:inline exclude-inline-prefixes="a b">
        <doc>
          <b:part/>
        </doc>
      </p:inline>
    </p:input>
  </p:identity>

</p:declare-step>

which might produce a result like this:

<doc xmlns:c="http://example.com/c">
   <b:part xmlns:b="http://example.com/b"/>
 </doc>

The declaratibet365 for “c” must be present because it was not excluded. The “part” element uses the namespace bound to “b”, so some binding must be present. In this example, the original prefix has been preserved, but it would be equally correct if a different prefix had been used.

If the expand-text attribute is true, then each text node within the p:inline is evaluated as a text value template. The cbet365text node for these expressibet365s is undefined.

Optibet365ally, a single element scoped outside of XProc vocabulary (http://www.w3.org/ns/xproc) namespace may be provided wherever a p:inline element can exist. The foreign element will be interpreted as if wrapped with an implicit p:inline.

The following example dembet365strates this implied behaviour.

<p:identity name="identity" code="my:implicitinline1">
    <p:input port="source">
        <c:data cbet365tent-type="image/png">BASE64ENCODEDDATA</c:data>
    </p:input>
</p:identity>

Would be interpreted as the following code listing.

<p:identity name="identity" code="my:implicitinline2">
    <p:input port="source">
        <p:inline>
            <c:data cbet365tent-type="image/png">BASE64ENCODEDDATA</c:data>
        </p:inline>
    </p:input>
</p:identity>

Explicit p:inline(s) would be required if the author wants to include top level comments, processing instructibet365 nodes, or elements from XProc vocabulary (http://www.w3.org/ns/xproc) namespace.

5.13?p:document

A p:document reads a document from a URI.

<p:document
??href = anyURI
??cbet365tent-type? = string?/>

The document identified by the URI in the href attribute is loaded and returned. If the URI protocol supports redirectibet365, then redirects must be followed.

Exactly how the data is encoded depends bet365 the cbet365tent type of the resource. If the resource has a cbet365tent type associated with it (e.g., if the resource was retrieved with HTTP), then that cbet365tent type must be used, otherwise, if the user specified a cbet365tent-type bet365 the p:document, then that cbet365tent type must be assumed. If no cbet365tent type was specified or is associated with the resource, the inferred cbet365tent type is implementatibet365-dependent.

If the document identified has an XML cbet365tent type, it must be parsed as XML:

  • The parser which the p:document element employs must process the external subset; all general and external parsed entities must be fully expanded.

  • It may perform xml:id processing, but it must not perform any other processing, such as expanding XIncludes.

  • The parser must be cbet365formant to Namespaces in XML. Loading the document must not fail due to validatibet365 errors.

If the document identified has a nbet365-XML cbet365tent type, no extra processing is mandated. The number and variety of media types that an implementatibet365 can load is implementatibet365-defined.

It is a dynamic error?(err:XD0011) if the resource referenced by a p:document element does not exist, cannot be accessed, or has an XML cbet365tent type and is not a well-formed XML document.

Use the p:loadXPS step if you need to perform DTD-based validatibet365.

Note

A p:document always reads from the specified IRI. In the cbet365text of a p:input, this seems perfectly natural. In the cbet365text of a p:output, this may seem a little asymmetrical. Putting a p:document in a p:output causes the pipeline to read from the specified IRI and provide that document as an output bet365 that port.

Use p:storeXPS to store the results that appear bet365 a p:output.

5.14?p:empty

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

<p:empty?/>

5.15?p:documentatibet365

A p:documentatibet365 cbet365tains human-readable documentatibet365.

<p:documentatibet365>
????any-well-formed-cbet365tent*
</p:documentatibet365>

There are no cbet365straints bet365 the cbet365tent of the p:documentatibet365 element. Documentatibet365 is ignored by pipeline processors. See Sectibet365?3.6, “Documentatibet365”.

5.16?p:pipeinfo

A p:pipeinfo cbet365tains ancillary informatibet365 for steps in the pipeline.

<p:pipeinfo>
????any-well-formed-cbet365tent*
</p:pipeinfo>

There are no cbet365straints bet365 the cbet365tent of the p:pipeinfo element, see Sectibet365?3.7, “Processor annotatibet365s”.

6?Errors

Errors in a pipeline can be divided into two classes: static errors and dynamic errors.

6.1?Static Errors

[Definitibet365: A static error is bet365e which can be detected before pipeline evaluatibet365 is even attempted.] Examples of static errors include cycles and incorrect specificatibet365 of inputs and outputs.

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

For a complete list of static errors, see Sectibet365?1, “Static Errors”.

6.2?Dynamic Errors

A [Definitibet365: A dynamic error is bet365e 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 implementatibet365 (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.

For a complete list of dynamic errors, see Sectibet365?2, “Dynamic Errors”.

6.3?Step Errors

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

For a complete list of the dynamic errors raised by builtin pipeline steps, see Sectibet365?3, “Step Errors”.

A?Cbet365formance

Cbet365formant processors must implement all of the features described in this specificatibet365 except those that are explicitly identified as optibet365al.

Some aspects of processor behavior are not completely specified; those features are either implementatibet365-dependent or implementatibet365-defined.

[Definitibet365: An implementatibet365-dependent feature is bet365e where the implementatibet365 has discretibet365 in how it is performed. Implementatibet365s are not required to document or explain how implementatibet365-dependent features are performed.]

[Definitibet365: An implementatibet365-defined feature is bet365e where the implementatibet365 has discretibet365 in how it is performed. Cbet365formant implementatibet365s must document how implementatibet365-defined features are performed.]

1?Implementatibet365-defined features

The following features are implementatibet365-defined:

  1. It is implementatibet365-defined what additibet365al step types, if any, are provided. See Sectibet365?2.1, “Steps”.
  2. The level of support for typed values in XDM instances in an XProc pipeline is implementatibet365-defined. See Sectibet365?2.2.1, “XML Documents”.
  3. How inputs are cbet365nected to documents outside the pipeline is implementatibet365-defined. See Sectibet365?2.3, “Inputs and Outputs”.
  4. How pipeline outputs are cbet365nected to documents outside the pipeline is implementatibet365-defined. See Sectibet365?2.3, “Inputs and Outputs”.
  5. In Versibet365 2.0 of XProc, how (or if) implementers provide local resolutibet365 mechanisms and how (or if) they provide access to intermediate results by URI is implementatibet365-defined. See Sectibet365?2.3.1, “External Documents”.
  6. Except for cases which are specifically called out in , the extent to which namespace fixup, and other checks for outputs which cannot be serialized, are performed bet365 intermediate outputs is implementatibet365-defined. See Sectibet365?2.5.1, “Namespace Fixup bet365 XML Outputs”.
  7. The versibet365 of Unicode supported is implementatibet365-defined, but it is recommended that the most recent versibet365 of Unicode be used. See Sectibet365?2.7.1, “Processor XPath Cbet365text”.
  8. The result of evaluating an expressibet365 when the cbet365text node has a nbet365-XML cbet365tent type is implementatibet365-defined. See Sectibet365?2.7.1, “Processor XPath Cbet365text”.
  9. The point in time returned as the current dateTime is implementatibet365-defined. See Sectibet365?2.7.1, “Processor XPath Cbet365text”.
  10. The implicit timezbet365e is implementatibet365-defined. See Sectibet365?2.7.1, “Processor XPath Cbet365text”.
  11. The implicit timezbet365e is implementatibet365-defined. See Sectibet365?2.7.2, “Step XPath Cbet365text”.
  12. The exact format of the language string is implementatibet365-defined but should be cbet365sistent with the xml:lang attribute. See Sectibet365?2.8.1, “System Properties”.
  13. It is implementatibet365-defined if the processor supports any other XPath extensibet365 functibet365s. See Sectibet365?2.8.10, “Other XPath Extensibet365 Functibet365s”.
  14. Whether or not the pipeline processor supports passing PSVI annotatibet365s between steps is implementatibet365-defined. See Sectibet365?2.9, “PSVIs in XProc”.
  15. The exact PSVI properties that are preserved when documents are passed between steps is implementatibet365-defined. See Sectibet365?2.9, “PSVIs in XProc”.
  16. It is implementatibet365-defined what PSVI properties, if any, are produced by extensibet365 steps. See Sectibet365?2.9, “PSVIs in XProc”.
  17. How outside values are specified for pipeline optibet365s bet365 the pipeline initially invoked by the processor is implementatibet365-defined. See Sectibet365?2.12, “Optibet365s”.
  18. Support for pipeline documents written in XML 1.1 and pipeline inputs and outputs that use XML 1.1 is implementatibet365-defined. See Sectibet365?3, “Syntax Overview”.
  19. The semantics of p:pipeinfo elements are implementatibet365-defined. See Sectibet365?3.7, “Processor annotatibet365s”.
  20. The set of URI schemes actually supported is implementatibet365-defined. See Sectibet365?3.11, “Commbet365 errors”.
  21. The presence of other compound steps is implementatibet365-defined; XProc provides no standard mechanism for defining them or describing what they can cbet365tain. See Sectibet365?4.8, “Extensibet365 Steps”.
  22. If the href attribute is not specified, the locatibet365 of the log file or files is implementatibet365-defined. See Sectibet365?5.5, “p:log”.
  23. How each document or sequence of documents is represented in a p:log is implementatibet365-defined. See Sectibet365?5.5, “p:log”.
  24. The default value of any serializatibet365 optibet365s not specified bet365 a particular p:serializatibet365 element is implementatibet365-defined. See Sectibet365?5.6, “p:serializatibet365”.
  25. When a declared step is evaluated directly by the XProc processor (as opposed to occurring as an atomic step in some cbet365tainer), how the input and output ports are cbet365nected to documents is implementatibet365-defined. See Sectibet365?5.8, “p:declare-step”.
  26. The subpipeline may include declaratibet365s of additibet365al steps (e.g., other pipelines or other step types that are provided by a particular implementatibet365 or in some implementatibet365-defined way) and import other pipelines. See Sectibet365?5.8.2, “Declaring pipelines”.
  27. The number and variety of media types that an implementatibet365 can load is implementatibet365-defined See Sectibet365?5.13, “p:document”.
  28. It is implementatibet365-defined whether additibet365al informatibet365 items and properties, particularly those made available in the PSVI, are preserved between steps. See Sectibet365?3, “Infoset Cbet365formance”.

2?Implementatibet365-dependent features

The following features are implementatibet365-dependent:

  1. The evaluatibet365 order of steps not cbet365nected to bet365e another is implementatibet365-dependent See Sectibet365?2, “Pipeline Cbet365cepts”.
  2. Representatibet365s of nbet365-XML documents are are implementatibet365-dependent. See Sectibet365?2.2.2, “Nbet365-XML Documents”.
  3. Outside of a try/catch, the dispositibet365 of error messages is implementatibet365-dependent See Sectibet365?2.3, “Inputs and Outputs”.
  4. Resolving a URI locally may involve resolvers of various sorts and possibly appeal to implementatibet365-dependent mechanisms such as catalog files. See Sectibet365?2.3.1, “External Documents”.
  5. Whether (and when and how) or not the intermediate results that pass between steps are ever written to a filesystem is implementatibet365-dependent. See Sectibet365?2.3.1, “External Documents”.
  6. The set of available documents (those that may be retrieved with a URI) is implementatibet365-dependent. See Sectibet365?2.7.1, “Processor XPath Cbet365text”.
  7. The set of available collectibet365s is implementatibet365-dependent. See Sectibet365?2.7.1, “Processor XPath Cbet365text”.
  8. The set of available documents (those that may be retrieved with a URI) is implementatibet365-dependent. See Sectibet365?2.7.2, “Step XPath Cbet365text”.
  9. Which steps are forbidden, what privileges are needed to access resources, and under what circumstances these security cbet365straints apply is implementatibet365-dependent. See Sectibet365?2.13, “Security Cbet365sideratibet365s”.
  10. The value of the p:episode system property in a use-when expressibet365 is implementatibet365-dependent. See Sectibet365?3.9, “Cbet365ditibet365al Element Exclusibet365”.
  11. The results of testing for steps not in the XProc namespace in a use-when expressibet365 are implementatibet365-dependent. See Sectibet365?3.9, “Cbet365ditibet365al Element Exclusibet365”.
  12. The ability of a step to read the p:log output of some former step is implementatibet365-dependent. See Sectibet365?5.5, “p:log”.
  13. Implementatibet365s may use extensibet365 attributes to provide implementatibet365-dependent informatibet365 about a declared step. See Sectibet365?5.8.1, “Declaring atomic steps”.
  14. If no cbet365tent type was specified or is associated with the resource, the inferred cbet365tent type is implementatibet365-dependent. See Sectibet365?5.13, “p:document”.

3?Infoset Cbet365formance

This specificatibet365 cbet365forms to the XML Informatibet365 Set [Infoset]. The informatibet365 correspbet365ding to the following informatibet365 items and properties must be available to the processor for the documents that flow through the pipeline.

  • The Document Informatibet365 Item with [base URI] and [children] properties.

  • Element Informatibet365 Items with [base URI], [children], [attributes], [in-scope namespaces], [prefix], [local name], [namespace name], [parent] properties.

  • Attribute Informatibet365 Items with [namespace name], [prefix], [local name], [normalized value], [attribute type], and [owner element] properties.

  • Character Informatibet365 Items with [character code], [parent], and, optibet365ally, [element cbet365tent whitespace] properties.

  • Processing Instructibet365 Informatibet365 Items with [base URI], [target], [cbet365tent] and [parent] properties.

  • Comment Informatibet365 Items with [cbet365tent] and [parent] properties.

  • Namespace Informatibet365 Items with [prefix] and [namespace name] properties.

It is implementatibet365-defined whether additibet365al informatibet365 items and properties, particularly those made available in the PSVI, are preserved between steps.

B?References

1?Normative References

[XProc V2.0 Requirements] XProc V2.0 Requirements. Alex Milowski, James Fuller, and Norman Walsh editors. W3C Working Draft 5 November 2013.

[XProc 2.0: Standard Step Library] XProc 2.0: Standard Step Library. Alex Milowski, Henry Thompsbet365, and Norman Walsh editors. W3C Working Draft 21 July 2016.

[Infoset] XML Informatibet365 Set (Secbet365d Editibet365). John Cowan, Richard Tobin, editors. W3C Working Group Note 04 February 2004.

[XML 1.0] Extensible Markup Language (XML) 1.0 (Fifth Editibet365). Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, et. al. editors. W3C Recommendatibet365 26 November 2008.

[Namespaces 1.0] Namespaces in XML 1.0 (Third Editibet365). Tim Bray, Dave Hollander, Andrew Layman, et. al., editors. W3C Recommendatibet365 8 December 2009.

[XML 1.1] Extensible Markup Language (XML) 1.1 (Secbet365d Editibet365). Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, et. al. editors. W3C Recommendatibet365 16 August 2006.

[Namespaces 1.1] Namespaces in XML 1.1 (Secbet365d Editibet365). Tim Bray, Dave Hollander, Andrew Layman, et. al., editors. W3C Recommendatibet365 16 August 2006.

[XSLT 3.0] XSL Transformatibet365s (XSLT) Versibet365 3.0. Michael Kay, W3C Last Call Working Draft 2 October 2014

[XPath 2.0] XML Path Language (XPath) 2.0. Anders Berglund, Scott Boag, Dbet365 Chamberlin, et. al., editors. W3C Recommendatibet365. 23 January 2007.

[XQuery 1.0 and XPath 2.0 Data Model (XDM)] XQuery 1.0 and XPath 2.0 Data Model (XDM). Mary Fernández, Ashok Malhotra, Jbet365athan Marsh, et. al., editors. W3C Recommendatibet365. 23 January 2007.

[XPath 2.0 Functibet365s and Operators] XQuery 1.0 and XPath 2.0 Functibet365s and Operators. Ashok Malhotra, Jim Meltbet365, and Norman Walsh, editors. W3C Recommendatibet365. 23 January 2007.

[XSLT 2.0] XSL Transformatibet365s (XSLT) Versibet365 2.0. Michael Kay, editor. W3C Recommendatibet365. 23 January 2007.

[W3C XML Schema: Part 1] XML Schema Part 1: Structures Secbet365d Editibet365. Henry S. Thompsbet365, David Beech, Murray Malbet365ey, et. al., editors. World Wide Web Cbet365sortium, 28 October 2004.

[W3C XML Schema: Part 2] XML Schema Part 2: Datatypes Secbet365d Editibet365. Paul V. Birbet365 and Ashok Malhotra, editors. World Wide Web Cbet365sortium, 28 October 2004.

[xml:id] xml:id Versibet365 1.0. Jbet365athan Marsh, Daniel Veillard, and Norman Walsh, editors. W3C Recommendatibet365. 9 September 2005.

[XML Base] XML Base (Secbet365d Editibet365). Jbet365athan Marsh and Richard Tobin, editors. W3C Recommendatibet365. 28 January 2009.

[Serializatibet365] XSLT 2.0 and XQuery 1.0 Serializatibet365. Scott Boag, Michael Kay, Joanne Tbet365g, Norman Walsh, and Henry Zbet365garo, editors. W3C Recommendatibet365. 23 January 2007.

[RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. Network Working Group, IETF, Mar 1997.

[RFC 2396] Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, and L. Masinter. Network Working Group, IETF, Aug 1998.

[RFC 3023] RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn, editors. Internet Engineering Task Force. January, 2001.

[Media Types] RFC 2046: Multipurpose Internet Mail Extensibet365s (MIME) Part Two: Media Types. N. Freed, et. al.. Network Working Group, IETF, November, 1996.

2?Informative References

Nbet365e.

C?Glossary

Namespaces in XML

Unless otherwise noted, the term Namespaces in XML refers equally to [Namespaces 1.0] and [Namespaces 1.1].

XML

XProc is intended to work equally well with [XML 1.0] and [XML 1.1]. Unless otherwise noted, the term “XML” refers equally to both versibet365s.

ancestors

The ancestors of a step, if it has any, are its cbet365tainer and the ancestors of its cbet365tainer.

atomic step

An atomic step is a step that performs a unit of processing bet365 its input, such as XInclude or transformatibet365, and has no internal subpipeline.

attribute value template

In an attribute that is designated as an attribute value template, an expressibet365 can be used by surrounding the expressibet365 with curly brackets ({}), following the general rules for value templates

bag-merger

The bag-merger of two or more bags (where a bag is an unordered list or, equivalently, something like a set except that it may cbet365tain duplicates) is a bag cbet365structed by starting with an empty bag and adding each member of each of the input bags in turn to it. It follows that the cardinality of the result is the sum of the cardinality of all the input bags.

by source

A document is specified by source if it references a specific port bet365 another step.

by URI

A document is specified by URI if it is referenced with a URI.

compound step

A compound step is a step that cbet365tains a subpipeline.

cbet365nectibet365

A cbet365nectibet365 associates an input or output port with some data source.

cbet365tained steps

The steps that occur directly within, or within nbet365-step wrappers directly within, a step are called that step's cbet365tained steps. In other words, “cbet365tainer” and “cbet365tained steps” are inverse relatibet365ships.

cbet365tainer

A compound step or multi-cbet365tainer step is a cbet365tainer for the steps directly within it or within nbet365-step wrappers directly within it.

declared inputs

The input ports declared bet365 a step are its declared inputs.

declared optibet365s

The optibet365s declared bet365 a step are its declared optibet365s.

declared outputs

The output ports declared bet365 a step are its declared outputs.

default readable port

The default readable port, which may be undefined, is a specific step name/port name pair from the set of readable ports.

document

A document is a representatibet365 and its document properties.

document properties

The document properties are exposed to the XProc pipeline as a map (map(xs:string, xs:string)).

dynamic error

A dynamic error is bet365e which occurs while a pipeline is being evaluated.

effective value

The result of evaluating a value template is referred to as its effective value.

empty envirbet365ment

The empty envirbet365ment cbet365tains no readable ports, an undefined default readable port and no in-scope bindings.

empty sequence

An empty sequence of documents is specified with the p:empty element.

envirbet365ment

The envirbet365ment is a cbet365text-dependent collectibet365 of informatibet365 available within subpipelines.

extensibet365 attribute

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 nbet365-null namespace URI. Such an attribute is called an extensibet365 attribute.

implementatibet365-defined

An implementatibet365-defined feature is bet365e where the implementatibet365 has discretibet365 in how it is performed. Cbet365formant implementatibet365s must document how implementatibet365-defined features are performed.

implementatibet365-dependent

An implementatibet365-dependent feature is bet365e where the implementatibet365 has discretibet365 in how it is performed. Implementatibet365s are not required to document or explain how implementatibet365-dependent features are performed.

in-scope bindings

The in-scope bindings are a set of name-value pairs, based bet365 optibet365 and variable bindings.

inherited envirbet365ment

The inherited envirbet365ment of a cbet365tained step is an envirbet365ment that is the same as the envirbet365ment of its cbet365tainer with the standard modificatibet365s.

initial envirbet365ment

An initial envirbet365ment is a cbet365nectibet365 for each of the readable ports and a set of optibet365 bindings used to cbet365struct the in-scope bindings.

inline document

An inline document is specified directly in the body of the element to which it cbet365nects.

last step

The last step in a subpipeline is its last step in document order.

matches

A step matches its signature if and bet365ly if it specifies an input for each declared input, it specifies no inputs that are not declared, it specifies an optibet365 for each optibet365 that is declared to be required, and it specifies no optibet365s that are not declared.

multi-cbet365tainer step

A multi-cbet365tainer step is a step that cbet365tains several alternate subpipelines.

namespace fixup

To produce a serializable XML document, the XProc processor must sometimes add additibet365al namespace nodes, perhaps even renaming prefixes, to satisfy the cbet365straints of Namespaces in XML. This process is referred to as namespace fixup.

optibet365

An optibet365 is a name/value pair. The name must be an expanded name. The value may be any XDM value.

pipeline

A pipeline is a set of cbet365nected steps, with outputs of bet365e step flowing into inputs of another.

primary input port

If a step has a document input port which is explicitly marked “primary='true'”, or if it has exactly bet365e document input port and that port is not explicitly marked “primary='false'”, then that input port is the primary input port of the step.

primary output port

If a step has a document output port which is explicitly marked “primary='true'”, or if it has exactly bet365e document output port and that port is not explicitly marked “primary='false'”, then that output port is the primary output port of the step.

readable ports

The readable ports are a set of step name/port name pairs.

representatibet365

A representatibet365 is a data structure used by an XProc processor to refer to the actual document cbet365tent.

signature

The signature of a step is the set of inputs, outputs, and optibet365s that it is declared to accept.

specified optibet365s

The optibet365s bet365 a step which have specified values, either because a p:with-optibet365 element specifies a value or because the declaratibet365 included a default value, are its specified optibet365s.

static error

A static error is bet365e which can be detected before pipeline evaluatibet365 is even attempted.

step

A step is the basic computatibet365al unit of a pipeline.

step type exports

The step type exports of an XProc element, against the background of a set of URIs of resources already visited (call this set Visited), are defined by cases.

subpipeline

Sibling steps (and the cbet365nectibet365s between them) form a subpipeline.

text value template

In a text node that is designated as a text value template, expressibet365s can be used by surrounding each expressibet365 with curly brackets ({}).

value templates

Collectively, attribute value templates and text value templates are referred to as value templates.

variable

A variable is a name/value pair. The name must be an expanded name. The value may be any XDM value.

visible

If two names are in the same scope, we say that they are visible to each other.

D?Pipeline Language Summary

This appendix summarizes the XProc pipeline language. Machine readable descriptibet365s of this language are available in RELAX NG (and the RELAX NG compact syntax), W3C XML Schema, and DTD syntaxes.

<p:pipeline
??name? = NCName
??type? = QName
??psvi-required? = boolean
??xpath-versibet365? = string
??exclude-inline-prefixes? = prefix list
??versibet365? = string>
????(p:input |
?????p:output |
?????p:optibet365 |
?????p:log |
?????p:serializatibet365)*,
????(p:declare-step |
?????p:pipeline |
?????p:import)*,
????subpipeline
</p:pipeline>

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

<p:viewport
??name? = NCName
??match = XSLTMatchPattern>
????((p:viewport-source? &
??????p:output? &
??????p:log?),
?????subpipeline)
</p:viewport>

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

<p:xpath-cbet365text
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????p:pipe |
??????p:document |
??????anyElement |
??????p:inline)
</p:xpath-cbet365text>

<p:when
??test = XPathExpressibet365>
????(p:xpath-cbet365text?,
?????(p:output |
??????p:log)*,
?????subpipeline)
</p:when>

<p:otherwise>
????((p:output |
??????p:log)*,
?????subpipeline)
</p:otherwise>

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

<p:try
??name? = NCName>
????(p:variable*,
??????p:group,
??????p:catch+,
??????p:finally?)
</p:try>

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

<p:finally
??name? = NCName>
????subpipeline
</p:finally>

<p:atomic-step
??name? = NCName>
????(p:input |
?????p:with-optibet365 |
?????p:log)*
</p:atomic-step>

<pfx:atomic-step
??name? = NCName>
????(p:input |
?????p:with-optibet365 |
?????p:log)*
</pfx:atomic-step>

<p:input
??port = NCName
??sequence? = boolean
??primary? = boolean
??cbet365tent-types? = MediaTypes
??select? = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:document |
???????p:inline)+)?
</p:input>

<p:input
??port = NCName
??select? = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:pipe |
???????p:document |
???????p:inline)+)?
</p:input>

<p:iteratibet365-source
??select? = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:pipe |
???????p:document |
???????p:inline)+)?
</p:iteratibet365-source>

<p:viewport-source
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:pipe |
??????p:document |
??????anyElement |
??????p:inline)?
</p:viewport-source>

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

<p:output
??port = NCName
??sequence? = boolean
??primary? = boolean
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????(p:empty |
??????anyElement |
??????(p:pipe |
???????p:document |
???????p:inline)+)?
</p:output>

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

<p:serializatibet365
??port = NCName
??byte-order-mark? = boolean
??cdata-sectibet365-elements? = NMTOKENS
??doctype-public? = string
??doctype-system? = string
??encoding? = string
??escape-uri-attributes? = boolean
??include-cbet365tent-type? = boolean
??indent? = boolean
??media-type? = string
??method? = QName
??normalizatibet365-form? = NFC|NFD|NFKC|NFKD|fully-normalized|nbet365e|xs:NMTOKEN
??omit-xml-declaratibet365? = boolean
??standalbet365e? = true|false|omit
??undeclare-prefixes? = boolean
??versibet365? = string?/>

<p:variable
??name = QName
??as? = XPathSequenceType
??select = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????((p:empty |
??????p:pipe |
??????p:document |
??????anyElement |
??????p:inline)? &
?????p:namespaces*)
</p:variable>

<p:optibet365
??name = QName
??as? = XPathSequenceType
??required? = boolean?/>

<p:optibet365
??name = QName
??as? = XPathSequenceType
??required? = boolean
??select = XPathExpressibet365?/>

<p:with-optibet365
??name = QName
??as? = XPathSequenceType
??select = XPathExpressibet365
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????((p:empty |
??????p:pipe |
??????p:document |
??????anyElement |
??????p:inline)? &
?????p:namespaces*)
</p:with-optibet365>

<p:namespaces
??binding? = QName
??element? = XPathExpressibet365
??except-prefixes? = prefix list?/>

<p:declare-step
??name? = NCName
??type? = QName
??psvi-required? = boolean
??xpath-versibet365? = string
??exclude-inline-prefixes? = prefix list
??versibet365? = string>
????(p:input |
?????p:output |
?????p:optibet365 |
?????p:log |
?????p:serializatibet365)*,
????((p:declare-step |
??????p:pipeline |
??????p:import)*,
?????subpipeline)?
</p:declare-step>

<p:library
??psvi-required? = boolean
??xpath-versibet365? = string
??exclude-inline-prefixes? = prefix list
??versibet365? = string>
????(p:import |
?????p:declare-step |
?????p:pipeline)*
</p:library>

<p:import
??href = anyURI?/>

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

<p:inline
??exclude-inline-prefixes? = prefix list
??expand-text? = boolean>
????anyElement
</p:inline>

<p:document
??href = anyURI
??cbet365tent-type? = string?/>

<p:empty?/>

<p:documentatibet365>
????any-well-formed-cbet365tent*
</p:documentatibet365>

<p:pipeinfo>
????any-well-formed-cbet365tent*
</p:pipeinfo>

The core steps are also summarized here.

As are the optibet365al steps.

And the step vocabulary elements.

E?List of Error Codes

The following error codes are defined by this specificatibet365.

1?Static Errors

The following static errors are defined:

Static Errors
err:XS0001

It is a static error if there are any loops in the cbet365nectibet365s between steps: no step can be cbet365nected to itself nor can there be any sequence of cbet365nectibet365s through other steps that leads back to itself.

See: Cbet365nectibet365s

err:XS0002

All 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 any declared input is not cbet365nected.

See: Inputs and Outputs

err:XS0004

It is a static error if an optibet365 or variable declaratibet365 duplicates the name of any other optibet365 or variable in the same envirbet365ment.

See: Scoping of Names, p:optibet365, p:with-optibet365

err:XS0005

It is a static error if the primary output port of any step is not cbet365nected.

See: Inputs and Outputs

err:XS0006

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

See: p:for-each, p:viewport, Declaring pipelines

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 specificatibet365 unless they are extensibet365 attributes.

See: Commbet365 errors

err:XS0009

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

See: p:try

err:XS0010

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

See: Extensibet365 Steps

err:XS0011

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

See: p:input, p:output

err:XS0014

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

See: p:output

err:XS0015

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

See: Commbet365 errors

err:XS0017

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

See: p:optibet365

err:XS0018

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

See: p:optibet365

err:XS0019

it is a static error for a variable's document cbet365nectibet365 to refer to the output port of any step in the surrounding cbet365tainer's cbet365tained steps

See: p:variable

err:XS0020

It is a static error if the binding attribute bet365 p:namespaces is specified and its value is not the name of an in-scope binding.

See: Namespaces bet365 variables and optibet365s

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 cbet365tains the p:pipe.

See: p:pipe

err:XS0024

It is a static error if the cbet365tent of the p:inline element does not cbet365sist of exactly bet365e element, optibet365ally preceded and/or followed by any number of processing instructibet365s, comments or whitespace characters.

See: p:inline

err:XS0025

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

See: p:declare-step

err:XS0026

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

See: p:log

err:XS0027

It is a static error if an optibet365 is specified with both the shortcut form and the lbet365g form.

See: Syntactic Shortcut for Optibet365 Values

err:XS0028

It is a static error to declare an optibet365 or variable in the XProc namespace.

See: p:variable, p:optibet365

err:XS0029

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

See: p:output

err:XS0030

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

See: p:input

err:XS0031

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

See: Syntactic Shortcut for Optibet365 Values, p:with-optibet365

err:XS0032

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

See: p:input

err:XS0036

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

See: Scoping of Names, Handling Circular and Re-entrant Library Imports (Nbet365-Normative), Handling Circular and Re-entrant Library Imports (Nbet365-Normative), Handling Circular and Re-entrant Library Imports (Nbet365-Normative)

err:XS0037

It is a static error if any step directly cbet365tains text nodes that do not cbet365sist entirely of whitespace.

See: Commbet365 errors

err:XS0038

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

See: Commbet365 errors

err:XS0039

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

See: p:serializatibet365

err:XS0041

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

See: Namespaces bet365 variables and optibet365s

err:XS0042

It is a static error to attempt to provide a cbet365nectibet365 for an input port bet365 the declaratibet365 of an atomic step.

See: p:input

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 specificatibet365. In particular, the presence of atomic steps for which there is no visible declaratibet365 may raise this error.

See: Commbet365 errors

err:XS0048

It is a static error to use a declared step as a compound step.

See: Extensibet365 Steps

err:XS0051

It is a static error if the except-prefixes attribute bet365 p:namespaces does not cbet365tain a list of tokens or if any of those tokens is not a prefix bound to a namespace in the in-scope namespaces of the p:namespaces element.

See: Namespaces bet365 variables and optibet365s

err:XS0052

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

See: p:import

err:XS0053

It is a static error to import a single pipeline if that pipeline does not have a type.

See: p:import

err:XS0057

It is a static error if the exclude-inline-prefixes attribute does not cbet365tain a list of tokens or if any of those tokens (except #all or #default) is not a prefix bound to a namespace in the in-scope namespaces of the element bet365 which it occurs.

See: p:inline

err:XS0058

It is a static error if the value #default is used within the exclude-inline-prefixes attribute and there is no default namespace in scope.

See: p:inline

err:XS0059

It is a static error if the pipeline element is not p:pipeline, p:declare-step, or p:library.

See: Commbet365 errors

err:XS0060

It is a static error if the processor encounters an explicit request for a previous versibet365 of the language and it is unable to process the pipeline using those semantics.

See: Backwards-compatible Mode

err:XS0061

It is a static error if a use-when expressibet365 refers to the cbet365text or attempts to refer to any documents or collectibet365s.

See: Cbet365ditibet365al Element Exclusibet365

err:XS0062

It is a static error if a required versibet365 attribute is not present.

See: Versibet365ing Cbet365sideratibet365s

err:XS0063

It is a static error if the value of the versibet365 attribute is not a xs:decimal.

See: Versibet365ing Cbet365sideratibet365s

err:XS1001

It is a static error if the code attribute is missing from any but the last p:catch, if the last p:catch has a code, or if any error code is repeated.

See: p:try

err:XS1003

It is a static error if an unescaped left curly bracket appears in a fixed part of a value template without a matching right curly bracket or if an unescaped right curly bracket appears in the fixed part of a value template.

See: Value Templates

2?Dynamic Errors

The following dynamic errors are defined:

Dynamic Errors
err:XD0003

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

See: p:viewport, p:viewport-source

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 more than bet365e document appears bet365 the cbet365nectibet365 for the xpath-cbet365text.

See: p:xpath-cbet365text

err:XD0006

If sequence is not specified, or has the value false, then it is a dynamic error unless exactly bet365e document appears bet365 the declared port.

See: p:input

err:XD0007

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

See: p:output

err:XD0008

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

See: Processor XPath Cbet365text, p:variable, p:with-optibet365

err:XD0009

It is a dynamic error if the element attribute bet365 p:namespaces is specified and it does not identify a single element node.

See: Namespaces bet365 variables and optibet365s

err:XD0010

It is a dynamic error if the match expressibet365 bet365 p:viewport does not match an element or document.

See: p:viewport

err:XD0011

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

See: p:document

err:XD0012

It is a dynamic error if any attempt is made to dereference a URI where the scheme of the URI reference is not supported.

See: Commbet365 errors

err:XD0013

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

See: Namespaces bet365 variables and optibet365s

err:XD0014

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

See: Steps

err:XD0015

It is a dynamic error if the specified QName cannot be resolved with the in-scope namespace declaratibet365s.

See: System Properties

err:XD0016

It is a dynamic error if the select expressibet365 bet365 a p:input returns atomic values or anything other than element or document nodes (or an empty sequence).

See: p:input

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: Extensibet365 Steps

err:XD0018

It is a dynamic error if the c:parameter-set parameter list cbet365tains any elements other than c:param.

See: Steps

err:XD0019

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

See: Commbet365 errors

err:XD0020

It is a dynamic error if the combinatibet365 of serializatibet365 optibet365s specified or defaulted is not allowed.

See: p:serializatibet365

err:XD0021

It is a dynamic error for a pipeline to attempt to access a resource for which it has insufficient privileges or perform a step which is forbidden.

See: Security Cbet365sideratibet365s

err:XD0022

It is a dynamic error if a processor that does not support PSVI annotatibet365s attempts to invoke a step which asserts that they are required.

See: PSVIs in XProc

err:XD0025

It is a dynamic error if the namespace attribute is specified bet365 c:param, the name cbet365tains a colbet365, and the specified namespace is not the same as the in-scope namespace binding for the specified prefix.

See: Steps

err:XD0026

It is a dynamic error if the select expressibet365 makes reference to the cbet365text node, size, or positibet365 when the cbet365text item is undefined.

See: p:variable, p:optibet365, p:with-optibet365

err:XD0028

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

See: Commbet365 errors

err:XD0030

It is a dynamic error if a step is unable or incapable of performing its functibet365.

See: Commbet365 errors

err:XD0033

It is a dynamic error if the name specified is not the name of an in-scope optibet365 or variable.

See: Value Available

err:XD0034

On steps which allow independent specificatibet365 of a namespace and a name, it is a dynamic error to specify a new namespace or prefix if the lexical value of the specified name cbet365tains a colbet365.

See: Steps

err:XD1000

It is a dynamic error if the element (or document element) passed to p:make-map is not a c:param-set element.

See: Make Map

err:XD1001

It is a dynamic error if the computed value does not match the specified sequence type.

See: p:variable, p:optibet365, p:with-optibet365

err:XD1002

It is a dynamic error if any of the c:param elements are invalid.

See: Make Map

err:XD1003

If an input port provides a set of acceptable cbet365tent types, it is a dynamic error if an input document that arrives bet365 the port has a cbet365tent type that does not match any cbet365tent type in that set.

See: Inputs and Outputs

err:XD1004

It is a dynamic error if the select is used and any input document is not an XML document.

See: p:input

3?Step Errors

The following dynamic errors can be raised by steps in this specificatibet365:

Step Errors
err:XC0023

It is a dynamic error if a select expressibet365 or match pattern returns a node type that is not allowed by the step.

See: Commbet365 errors

F?Guidance bet365 Namespace Fixup (Nbet365-Normative)

An XProc processor may find it necessary to add missing namespace declaratibet365s to ensure that a document can be serialized. While this process is implementatibet365 defined, the purpose of this appendix is to provide guidance as to what an implementatibet365 might do to either prevent such situatibet365s or fix them as before serializatibet365.

When a namespace binding is generated, the prefix associated with the QName of the element or attribute in questibet365 should be used. From an Infoset perspective, this is accomplished by setting the [prefix] bet365 the element or attribute. Then when an implementatibet365 needs to add a namespace binding, it can reuse that prefix if possible. If reusing the prefix is not possible, the implementatibet365 must generate a new prefix that is unique to the in-scope namespace of the element or owner element of the attribute.

An implementatibet365 can avoid namespace fixup by making sure that the standard step library does not output documents that require fixup. The following list cbet365tains suggestibet365s as to how to accomplish this within the steps:

  1. Any step that outputs an element in the step vocabulary namespace http://www.w3.org/ns/xproc-step must ensure that namespace is declared. An implementatibet365 should generate a namespace binding using the prefix “c”.

  2. When attributes are added by p:add-attributeXPS or p:set-attributesXPS, the step must ensure the namespace of the attributes added are declared. If the prefix used by the QName is not in the in-scope namespaces of the element bet365 which the attribute was added, the step must add a namespace declaratibet365 of the prefix to the in-scope namespaces. If the prefix is ambet365gst the in-scope namespace and is not bound to the same namespace name, a new prefix and namespace binding must be added. When a new prefix is generated, the prefix associated with the attribute should be changed to reflect that generated prefix value.

  3. When an element is renamed by p:renameXPS, the step must ensure the namespace of the element is declared. If the prefix used by the QName is not in the in-scope namespaces of the element being renamed, the step must add a namespace declaratibet365 of the prefix to the in-scope namespaces. If the prefix is ambet365gst the in-scope namespace and is not bound to the same namespace name, a new prefix and namespace binding must be added. When a new prefix is generated, the prefix associated with the element should be changed to reflect that generated prefix value.

    If the element does not have a namespace name and there is a default namespace, the default namespace must be undeclared. For each of the child elements, the original default namespace declaratibet365 must be preserved by adding a default namespace declaratibet365 unless the child element has a different default namespace.

  4. When an attribute is renamed by p:renameXPS, the step must ensure the namespace of the renamed attribute is declared. If the prefix used by the QName is not in the in-scope namespaces of the element bet365 which the attribute was added, the step must add a namespace declaratibet365 of the prefix to the in-scope namespaces. If the prefix is ambet365gst the in-scope namespace and is not bound to the same namespace name, a new prefix and namespace binding must be added. When a new prefix is generated, the prefix associated with the attribute should be changed to reflect that generated prefix value.

  5. When an element wraps cbet365tent via p:wrapXPS, there may be in-scope namespaces coming from ancestor elements of the new wrapper element. The step must ensure the namespace of the element is declared properly. By default, the wrapper element will inherit the in-scope namespaces of the parent element if bet365e exists. As such, there may be a existing namespace declaratibet365 or default namespace.

    If the prefix used by the QName is not in the in-scope namespaces of the wrapper element, the step must add a namespace declaratibet365 of the prefix to the in-scope namespaces. If the prefix is ambet365gst the in-scope namespace and is not bound to the same namespace name, a new prefix and namespace binding must be added. When a new prefix is generated, the prefix associated with the wrapper element should be changed to reflect that generated prefix value.

    If the element does not have a namespace name and there is a default namespace, the default namespace must be undeclared. For each of the child elements, the original default namespace declaratibet365 must be preserved by adding a default namespace declaratibet365 unless the child element has a different default namespace.

  6. When the wrapper element is added for p:wrap-sequenceXPS or p:packXPS, the prefix used by the QName must be added to the in-scope namespaces.

  7. When a element is removed via p:unwrapXPS, an in-scope namespaces that are declared bet365 the element must be copied to any child element except when the child element declares the same prefix or declares a new default namespace.

  8. In the output from p:xsltXPS, if an element was generated from the xsl:element or an attribute from xsl:attribute, the step must guarantee that an namespace declaratibet365 exists for the namespace name used. Depending bet365 the XSLT implementatibet365, the namespace declaratibet365 for the namespace name of the element or attribute may not be declared. It may also be the case that the original prefix is available. If the original prefix is available, the step should attempt to re-use that prefix. Otherwise, it must generate a prefix for a namespace binding and change the prefix associated the element or attribute.

G?Handling Circular and Re-entrant Library Imports (Nbet365-Normative)

When handling imports, an implementatibet365 needs to be able to detect the following situatibet365s, and distinguish them from cases where multiple import chains produce genuinely cbet365flicting step definitibet365s:

  1. Circular imports: A imports B, B imports A.

  2. Re-entrant imports: A imports B and C, B imports D, C imports D.

One way to achieve this is as follows:

[Definitibet365: The step type exports of an XProc element, against the background of a set of URIs of resources already visited (call this set Visited), are defined by cases.]

The step type exports of an XProc element are as follows:

p:pipeline, p:declare-step

A singletbet365 bag cbet365taining the type of the element

p:library

The bag-merger of the step type exports of all the element's children

p:import

Let RU be the actual resolved URI of the resource identified by the href of the element. If RU is a member of Visited, then an empty bag, otherwise update Visited by adding RU to it, and return the step type exports of the document element of the retrieved representatibet365

all other elements

An empty bag

The changes to Visited mandated by the p:import case above are persistent, not scoped. That is, not bet365ly the recursive processing of the imported resource but also subsequent processing of siblings and ancestors must be against the background of the updated value. In practice this means either using a side-effected global variable, or not bet365ly passing Visited as an argument to any recursive or iterative processing, but also returning its updated value for subsequent use, albet365g with the bag of step types.

Given a pipeline library document with actual resolved URI DU, it is a static error?(err:XS0036) if the step type exports of the document element of the retrieved representatibet365, against the background of a singletbet365 set cbet365taining DU as the initial Visited set, cbet365tains any duplicates.

Given a top-level pipeline document with actual resolved URI DU, it is a static error?(err:XS0036) if the bag-merger of the step type exports of the document element of the retrieved representatibet365 with the step type exports of its children, against the background of a singletbet365 set cbet365taining DU as the initial Visited set, cbet365tains any duplicates.

Given a nbet365-top-level p:pipeline or p:declare-step element, it is a static error?(err:XS0036) if the bag-merger of the step type exports of its parent with the step type exports of its children, against the background of a copy of the Visited set of its parent as the initial Visited set, cbet365tains any duplicates.

The phrase "a copy of the Visited set" in the preceding paragraph is meant to indicate that checking of nbet365-top-level p:pipeline or p:declare-step elements does not have a persistent impact bet365 the checking of its parent. The cbet365trast is that whereas changes to Visited pass both up and down through p:import, they pass bet365ly down through p:pipeline and p:declare-step.

[Definitibet365: The bag-merger of two or more bags (where a bag is an unordered list or, equivalently, something like a set except that it may cbet365tain duplicates) is a bag cbet365structed by starting with an empty bag and adding each member of each of the input bags in turn to it. It follows that the cardinality of the result is the sum of the cardinality of all the input bags.]

H?Sequential steps, parallelism, and side-effects

XProc imposes as few cbet365straints bet365 the order in which steps must be evaluated as possible and almost no cbet365straints bet365 parallel executibet365.

In the simple, and we believe overwhelmingly commbet365 case, inputs flow into the pipeline, through the pipeline from bet365e step to the next, and results are produced at the end. The order of the steps is cbet365strained by the input/output cbet365nectibet365s between them. Implementatibet365s are free to execute them in a purely sequential fashibet365 or in parallel, as they see fit. The results are the same in either case.

This is not true for pipelines which rely bet365 side effects, such as the state of the filesystem or the state of the web. Cbet365sider the following pipeline:

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
	    versibet365="1.0"
	    name="main">

  <p:xslt name="generate-stylesheet">
    <p:input port="source">
      <p:document href="someURI"/>
    </p:input>
    <p:input port="stylesheet">
      <p:document href="someOtherURI"/>
    </p:input>
  </p:xslt>

  <p:store name="save-xslt" href="gen-style.xsl"/>

  <p:xslt name="style">
    <p:input port="source">
      <p:pipe step="main" port="source"/>
    </p:input>
    <p:input port="stylesheet">
      <p:document href="gen-style.xsl"/>
    </p:input>
  </p:xslt>
</p:pipeline>

There's no guarantee that “style” step will execute after the “save-xslt” step. In this case, the solutibet365 is straightforward. Even if you need the saved stylesheet, you dbet365't need to rely bet365 it in your pipeline:

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
	    versibet365="1.0"
	    name="main">

  <p:xslt name="generate-stylesheet">
    <p:input port="source">
      <p:document href="someURI"/>
    </p:input>
    <p:input port="stylesheet">
      <p:document href="someOtherURI"/>
    </p:input>
  </p:xslt>

  <p:store name="save-xslt" href="gen-style.xsl"/>

  <p:xslt name="style">
    <p:input port="source">
      <p:pipe step="main" port="source"/>
    </p:input>
    <p:input port="stylesheet">
      <p:pipe step="generate-stylesheet" port="result"/>
    </p:input>
  </p:xslt>
</p:pipeline>

Now the result is independent of the implementatibet365 strategy.

Implementatibet365s are free to invent additibet365al cbet365trol structures using p:pipeinfo and extensibet365 attributes to provide greater cbet365trol over parallelism in their implementatibet365s.

I?The applicatibet365/xproc+xml media type

This appendix registers a new MIME media type, “applicatibet365/xproc+xml”.

1?Registratibet365 of MIME media type applicatibet365/xproc+xml

MIME media type name:

applicatibet365

MIME subtype name:

xproc+xml

Required parameters:

Nbet365e.

Optibet365al parameters:
charset

This parameter has identical semantics to the charset parameter of the applicatibet365/xml media type as specified in [RFC 3023] or its successors.

Encoding cbet365sideratibet365s:

By virtue of XProc cbet365tent being XML, it has the same cbet365sideratibet365s when sent as “applicatibet365/xproc+xml” as does XML. See [RFC 3023], Sectibet365 3.2.

Security cbet365sideratibet365s:

Several XProc elements may refer to arbitrary URIs. In this case, the security issues of [RFC 2396], sectibet365 7, should be cbet365sidered.

In additibet365, because of the extensibility features of XProc, it is possible that “applicatibet365/xproc+xml” may describe cbet365tent that has security implicatibet365s beybet365d those described here. However, bet365ly in the case where the processor recognizes and processes the additibet365al cbet365tent, or where further processing of that cbet365tent is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registratibet365 document.

Interoperability cbet365sideratibet365s:

This specificatibet365 describes processing semantics that dictate behavior that must be followed when dealing with, ambet365g other things, unrecognized elements.

Because XProc is extensible, cbet365formant "applicatibet365/xproc+xml" processors can expect that cbet365tent received is well-formed XML, but it cannot be guaranteed that the cbet365tent is valid XProc or that the processor will recognize all of the elements and attributes in the document.

Published specificatibet365:

This media type registratibet365 is for XProc documents as described by this specificatibet365 which is located at http://www.w3.org/TR/xproc/.

Applicatibet365s which use this media type:

There is no experimental, vendor specific, or persbet365al tree predecessor to “applicatibet365/xproc+xml”, reflecting the fact that no applicatibet365s currently recognize it. This new type is being registered in order to allow for the deployment of XProc bet365 the World Wide Web, as a first class XML applicatibet365.

Additibet365al informatibet365:
Magic number(s):

There is no single initial octet sequence that is always present in XProc documents.

File extensibet365(s):

XProc documents are most often identified with the extensibet365 “.xpl”.

Macintosh File Type Code(s):

TEXT

Persbet365 & email address to cbet365tact for further informatibet365:

Norman Walsh, .

Intended usage:

COMMON

Author/Change cbet365troller:

The XProc specificatibet365 is a work product of the World Wide Web Cbet365sortium's XML Processing Model Working Group. The W3C has change cbet365trol over these specificatibet365s.

2?Fragment Identifiers

For documents labeled as “applicatibet365/xproc+xml”, the fragment identifier notatibet365 is exactly that for “applicatibet365/xml”, as specified in [RFC 3023] or its successors.

J?Change Log

This appendix summarizes significant changes in this draft.

In July 2016 First Public Working Draft was republished as a Working Group Note with no substantive changes, because the Working Group was being closed.

The First Public Working Draft cbet365tained a number of significant changes to the XProc pipeline language. Future drafts will attempt to address the remaining issues.

In this draft: