xproc

XProc: An XML Pipeline Language XProc: An XML Pipeline Language W3C Recommendation 11 May 2010 This Version: http://www.w3.org/TR/2010/REC-xproc-20100511/ Latest Version: http://www.w3.org/TR/xproc/ Previous versions: http://www.w3.org/TR/2010/PR-xproc-20100309/ http://www.w3.org/TR/2010/WD-xproc-20100105/ http://www.w3.org/TR/2009/CR-xproc-20090528/ Editors: Norman Walsh MarkLogic Corporation < [email protected] Alex Milowski Invited expert < [email protected] Henry S. Thompson University of Edinburgh < [email protected] Please refer to the errata See also translations This document is also available in these non-normative formats: XML Copyright W3C ® MIT ERCIM Keio liability trademark document use Abstract This specification describes the syntax and semantics of XProc: An XML Pipeline Language An XML Pipeline specifies a sequence of operations to be performed on zero or more XML documents. Pipelines generally accept zero or more XML documents as input and produce zero or more XML documents as output. Pipelines are made up of simple steps which perform atomic operations on XML documents and constructs similar to conditionals, iteration, and exception handlers which control which steps are executed. Status of this Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index This document is a W3C Recommendation XProc Requirements XML Processing Model Working Group XML Activity This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web. Please report errors in this document to the public mailing list [email protected] archives There is an Implementation Report for XProc XProc Test Suite This document was produced by a group operating under the 5 February 2004 W3C Patent Policy public list of any patent disclosures Essential Claim(s) section 6 of the W3C Patent Policy Table of Contents 1 Introduction 2 Pipeline Concepts 2.1 Steps 2.1.1 Step names 2.2 Inputs and Outputs 2.2.1 External Documents 2.2.2 Non-XML Documents 2.3 Primary Inputs and Outputs 2.4 Connections 2.4.1 Namespace Fixup on Outputs 2.5 Environment 2.6 XPaths in XProc 2.6.1 XPath 1.0 processors 2.6.2 XPath 2.0 processors 2.7 XPath Extension Functions 2.7.1 System Properties 2.7.2 Step Available 2.7.3 Value Available 2.7.4 Iteration Position 2.7.5 Iteration Size 2.7.6 Base URI 2.7.7 Resolve URI 2.7.8 Version Available 2.7.9 XPath Version Available 2.7.10 Other XPath Extension Functions 2.8 PSVIs in XProc 2.9 Variables 2.10 Options 2.11 Parameters 2.12 Security Considerations 2.13 Versioning Considerations 2.13.1 Backwards-compatible Mode 2.13.2 Forwards-compatible Mode 3 Syntax Overview 3.1 XProc Namespaces 3.2 Scoping of Names 3.3 Base URIs and xml:base 3.4 Unique identifiers 3.5 Associating Documents with Ports 3.6 Documentation 3.7 Processor annotations 3.8 Extension attributes 3.9 Conditional Element Exclusion 3.10 Syntax Summaries 3.11 Common errors 4 Steps 4.1 p:pipeline 4.2 p:for-each 4.2.1 XPath Context 4.3 p:viewport 4.3.1 XPath Context 4.4 p:choose 4.4.1 p:xpath-context 4.4.2 p:when 4.4.3 p:otherwise 4.5 p:group 4.6 p:try 4.6.1 The Error Vocabulary 4.7 Atomic Steps 4.8 Extension Steps 4.8.1 Syntactic Shortcut for Option Values 5 Other pipeline elements 5.1 p:input 5.1.1 Document Inputs 5.1.2 Parameter Inputs 5.2 p:iteration-source 5.3 p:viewport-source 5.4 p:output 5.5 p:log 5.6 p:serialization 5.7 Variables, Options, and Parameters 5.7.1 p:variable 5.7.2 p:option 5.7.3 p:with-option 5.7.4 p:with-param 5.7.5 Namespaces on variables, options, and parameters 5.8 p:declare-step 5.8.1 Declaring atomic steps 5.8.2 Declaring pipelines 5.9 p:library 5.10 p:import 5.11 p:pipe 5.12 p:inline 5.13 p:document 5.14 p:data 5.15 p:empty 5.16 p:documentation 5.17 p:pipeinfo 6 Errors 6.1 Static Errors 6.2 Dynamic Errors 6.3 Step Errors 7 Standard Step Library 7.1 Required Steps 7.1.1 p:add-attribute 7.1.2 p:add-xml-base 7.1.3 p:compare 7.1.4 p:count 7.1.5 p:delete 7.1.6 p:directory-list 7.1.7 p:error 7.1.8 p:escape-markup 7.1.9 p:filter 7.1.10 p:http-request 7.1.11 p:identity 7.1.12 p:insert 7.1.13 p:label-elements 7.1.14 p:load 7.1.15 p:make-absolute-uris 7.1.16 p:namespace-rename 7.1.17 p:pack 7.1.18 p:parameters 7.1.19 p:rename 7.1.20 p:replace 7.1.21 p:set-attributes 7.1.22 p:sink 7.1.23 p:split-sequence 7.1.24 p:store 7.1.25 p:string-replace 7.1.26 p:unescape-markup 7.1.27 p:unwrap 7.1.28 p:wrap 7.1.29 p:wrap-sequence 7.1.30 p:xinclude 7.1.31 p:xslt 7.2 Optional Steps 7.2.1 p:exec 7.2.2 p:hash 7.2.3 p:uuid 7.2.4 p:validate-with-relax-ng 7.2.5 p:validate-with-schematron 7.2.6 p:validate-with-xml-schema 7.2.7 p:www-form-urldecode 7.2.8 p:www-form-urlencode 7.2.9 p:xquery 7.2.10 p:xsl-formatter 7.3 Serialization Options A Conformance A.1 Implementation-defined features A.2 Implementation-dependent features A.3 Infoset Conformance B References B.1 Normative References B.2 Informative References C Glossary D Pipeline Language Summary E List of Error Codes E.1 Static Errors E.2 Dynamic Errors E.3 Step Errors F Guidance on Namespace Fixup (Non-Normative) G Handling Circular and Re-entrant Library Imports (Non-Normative) H Sequential steps, parallelism, and side-effects I The application/xproc+xml I.1 Registration of MIME media type application/xproc+xml I.2 Fragment Identifiers An XML Pipeline specifies a sequence of operations to be performed on a collection of XML input documents. Pipelines take zero or more XML documents as their input and produce zero or more XML documents as their output. A pipeline There are three kinds of steps: atomic steps, compound steps, and multi-container steps. Atomic steps carry out single operations and have no substructure as far as the pipeline is concerned. Compound steps and multi-container steps control the execution of other steps, which they include in the form of one or more subpipelines. This specification defines a standard library, Section 7, “Standard Step Library” may Figure 1, “A simple, linear XInclude/Validate pipeline” Figure 1. A simple, linear XInclude/Validate pipeline This is a pipeline that consists 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 validation, “result”, is the result of the pipeline. (For consistency across the step vocabulary, the standard input is usually named “source” and and the standard output is usually named “result”.) The pipeline document determines how the steps are connected together inside the pipeline, that is, how the output of one 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" version="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” If you use p:pipeline p:declare-step source result Where inputs and outputs are connected between sequential sibling steps, they do not have to be made explicit. The same pipeline, using XProc defaults, is shown in Example 2, “A simple, linear XInclude/Validate pipeline (simplified)” Example 2. A simple, linear XInclude/Validate pipeline (simplified) <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" name="xinclude-and-validate" version="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” Figure 2. A validate and transform pipeline The heart of this example is the conditional. The “choose” step evaluates an XPath expression over a test document. Based on the result of that expression, one or another branch is run. In this example, each branch consists of a single validate step. Example 3. A validate and transform pipeline <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0">

<p:choose> <p:when test="/*[@version &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 on XProc defaults for simplicity. It is always valid to write the fully explicit form if you prefer. The media type for pipeline documents is application/xml .xpl In this specification the words must must not should should not may recommended RFC 2119 [Definition: A pipeline step The result of evaluating a pipeline (or subpipeline must not inputs options parameters The pattern of connections between steps will not always completely determine their order of evaluation. implementation-dependent [Definition: A step There are three kinds of steps: atomic compound multi-container [Definition: An atomic step subpipeline There are many types Section 7, “Standard Step Library” may implementation-defined Compound steps, on the other hand, control and organize the flow of documents through a pipeline, reconstructing familiar programming language functionality such as conditionals, iterators and exception handling. They contain other steps, whose evaluation they control. [Definition: A compound step subpipeline Finally, there are two “multi-container steps”: p:choose p:try [Definition: A multi-container step subpipelines p:when p:otherwise p:choose p:group p:catch p:try The output of a multi-container step is the output of exactly one of its subpipelines. In this sense, a multi-container step functions like a compound step [Definition: A compound step or multi-container step is a container [Definition: The steps that occur directly within, or within non-step wrappers directly within, a step are called that step's contained steps [Definition: The ancestors container [Definition: Sibling steps (and the connections between them) form a subpipeline [Definition: The last step 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 declaration Steps have “ports” into which inputs and outputs are connected. 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 A Step may have zero or more options Steps may have parameter input ports, on which parameters All of the different instances of steps (atomic or compound) in a pipeline can be distinguished from one another by name. If the pipeline author does not provide a name for a step, a default name is manufactured automatically The name Section 3.2, “Scoping of Names” If the pipeline author does not provide an explicit name, the processor manufactures a default name. All default names are of the form “ !1 .m .n m n Example 3, “A validate and transform pipeline” p:pipeline !1 p:choose !1.1 p:when !1.1.1 p:otherwise !1.1.2 p:choose p:when !1.1.1 Providing every step in the pipeline with an interoperable name has several benefits: It allows implementors to refer to all steps in an interoperable fashion, for example, in error messages. Pragmatically, we say that readable ports In a valid pipeline that runs successfully to completion, the manufactured names aren't visible (except perhaps in debugging or logging output). Note The format for defaulted names does not conform to the requirements of an NCName p:pipe Although some steps can read and write non-XML resources, what flows between For the purposes of this specification, an XML document is an [ Infoset Section A.3, “Infoset Conformance” Most steps in this specification manipulate XML documents, or portions of XML documents. In these cases, we speak of changing elements, attributes, or nodes without prejudice to the actual representation used by an implementation. An implementation may dynamic error err:XD0001 The common case is that each step has one or more inputs and one or more outputs. Figure 3, “An atomic step” atomic step Figure 3. An atomic step All atomic steps are defined by a p:declare-step p:validate-with-xml-schema source schema result Like atomic steps, top level, user-defined pipelines also have declarations. The situation is slightly more complicated for the other compound steps because they don't have separate declarations; each instance of the compound step serves as its own declaration. On these compound steps, the number and names of the outputs can be different on each instance of the step. Figure 4, “A compound step” Figure 4. A compound step [Definition: The input ports declared on a step are its declared inputs [Definition: The output ports declared on a step are its declared outputs When a step is used, all of the declared inputs must The output port of some other step. A fixed, inline document or sequence of documents. A document read from a URI. One of the inputs declared on one of its ancestors A special port provided by an ancestor compound step, for example, “ current p:for-each p:viewport When an input accepts a sequence of documents, the documents can come from any combination of these locations. static error err:XS0003 The declared outputs The input port of some other step (including p:iteration-source p:viewport-source The p:xpath-context p:choose p:when An option assigned with p:with-option p:with-param One of the outputs declared on its container. The primary output port must static error err:XS0005 Primary input and primary output ports may be implicitly connected if no explicit connection is given, see Section 2.3, “Primary Inputs and Outputs” Output ports on compound steps have a dual nature: from the perspective of the compound step's siblings, its outputs are just ordinary outputs and must be connected as described above. From the perspective of the subpipeline inside the compound step, they are inputs into which something may be connected. Within a compound step, the declared outputs The output port of some contained step A fixed, inline document or sequence of documents. A document read from a URI. If a (non-primary) output port of a compound step is left unconnected, it produces an empty sequence of documents from the perspective of its siblings. Each input and output on a step is declared to accept or produce either a single document or a sequence of documents. It is not It is also not an error to connect a port that is declared to produce a single document to a port that is declared to accept a sequence. A single document is the same as a sequence of one document. An output port may have more than one connection: it may be connected to more than one input port, more than one of its container's output ports, or both. At runtime this will result in distinct copies of the output. [Definition: The signature [Definition: A step matches must may Steps may error p:catch try/catch implementation-dependent implementation-defined must must not Infoset [unexpanded entity reference information items] implementation-defined It's common for some of the documents used in processing a pipeline to be read from URIs. Sometimes this occurs directly, for example with a p:document p:xslt xsl:import The process of dereferencing a URI to retrieve a document is often more interesting than it seems at first. On the web, it may involve caches, proxies, and various forms of indirection. implementation-dependent In XProc, the situation is made even more interesting by the fact that many intermediate results produced by steps in the pipeline have base URIs. implementation-dependent implementation-defined Version 1.0 of XProc does not require implementations to guarantee that multiple attempts to dereference the same URI always produce consistent results. Note On the one hand, this is a somewhat unsatisfying state of affairs because it leaves room for interoperability problems. On the other, it is not expected to cause such problems very often in practice. If these problems arise in practice, implementers are encouraged to use the existing extension mechanisms to give users the control needed to circumvent them. Should such mechanisms become widespread, a standard mechanism could be added in some future version of the language. XProc is designed to allow pipeline authors to specify how an XML document, or sequence of XML documents, flows through a series of steps. For the most part, non-XML documents are considered out-of-scope. However, to be useful, XProc pipelines must interact with the real world where non-XML documents (HTML documents, raster images, non-XML encodings of data, etc.) are a fact of life. Accordingly, some pipelines may need to access non-XML documents and some non-XML documents may “leak” into pipelines. XProc provides a limited set of tools for processing these documents. In particular, XProc offers the ability to turn some “almost-XML” documents into XML and to allow some non-XML documents to flow quietly through the pipeline. It is not There are two standard ways that a non-XML document may enter a pipeline: directly through p:data p:http-request p:http-request file: In either case, non-XML documents are converted into text or are base64-encoded, depending on their content type and character encoding. The result is an XML document that consists of a document element containing either escaped text or base64-encoded text. This document can be processed like any other XML document. The p:unescape-markup implementation-defined XProc provides no standard means to save encoded data in its unencoded binary form. Implementors may provide extension methods to allow the p:store ext:binary <p:store method="ext:binary" href="my.png"> <p:input port="source"> <p:inline> <c:data content-type="image/png">BASE64ENCODEDDATA</c:data> </p:inline> </p:input> </p:store> As a convenience for pipeline authors, each step may have one input port designated as the primary input port and one output port designated as the primary output port. [Definition: If a step has a document input port which is explicitly marked “ primary='true' not primary='false' primary input port primary='false' [Definition: If a step has a document output port which is explicitly marked “ primary='true' not primary='false' primary output port primary='false' The special significance of primary input and output ports is that they are connected automatically by the processor if no explicit connection is given. Generally speaking, if two steps appear sequentially in a subpipeline, then the primary output of the first step will automatically be connected to the primary input of the second. Additionally, if a compound step has no declared outputs and the last step sequence p:declare-step Steps are connected together by their input ports and output ports. static error err:XS0001 XProc processors are expected, and sometimes required, to perform namespace fixup The in-scope namespaces associated with a node (even those that are inherited from namespace bindings that appear among its ancestors in the document in which it appears initially) are assumed to travel with that node. Changes to one 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 serialization (because they include nodes with conflicting or missing namespace declarations, for example). [Definition: To produce a serializable XML Namespaces in XML namespace fixup Implementors are encouraged to perform namespace fixup does Except where the semantics of a step explicitly require changes, processors are required to preserve the information in the documents and fragments they manipulate. In particular, the information corresponding to the [ Infoset [attributes] [base URI] [children] [local name] [namespace name] [normalized value] [owner] [parent] must The information corresponding to [prefix] [in-scope namespaces] [namespace attributes] [attribute type] should namespace fixup Section 7, “Standard Step Library” implementation-defined Whenever an implementation serializes pipeline contents, for example for pipeline outputs, logging, or as part of steps such as p:store p:http-request dynamic error XML Namespaces in XML [Definition: The environment The environment consists of: A set of readable ports. [Definition: The readable ports A default readable port. [Definition: The default readable port A set of in-scope bindings. [Definition: The in-scope bindings option variable [Definition: The empty environment Unless otherwise specified, the environment of a contained step inherited environment [Definition: The inherited environment contained step container standard modifications The standard modifications The declared inputs of the container are added to the readable ports In other words, contained steps can see the inputs to their container. The union 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 addition to the outputs visible to their container. If there is a preceding sibling step element: If that preceding sibling has a primary output port default readable port Otherwise, the default readable port If there is not If the container has a primary input port default readable port primary input port Otherwise, the default readable port is unchanged. The names and values from each p:variable in-scope bindings Section 5.7.1, “p:variable” A step with no parent inherits the empty environment XProc uses XPath as an expression language. XPath expressions are evaluated by the XProc processor in several places: on compound steps, to compute the default values of options and the values of variables; on atomic steps, to compute the actual values of options and the values of parameters. XPath expressions are also passed to some steps. These expressions are evaluated by the implementations of the individual steps. This distinction can be seen in the following example: <p:variable name="home" select="'http://example.com/docs'"/>

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

<p:split-sequence name="select-chapters" test="@role='chapter'"> <p:input port="source" select="//section"/> </p:split-sequence> The select expression on the variable “ home http://example.com/docs The href p:load href http://example.com/docs/document.xml source p:split-sequence The XPath expression “ @role='chapter' test p:split-sequence p:split-sequence it evaluates The XProc processor evaluates all of the XPath expressions in select match p:viewport test p:when An XProc implementation can use either XPath 1.0 XPath 2.0 Note Allowing either XPath 1.0 or XPath 2.0 is a compromise driven entirely by the timing of XProc development. During the development of this specification, the community indicated that it was too early to mandate that all implementations use XPath 2.0 and too late to mandate that all implementations use XPath 1.0. Many, many expressions that are likely to be used in XProc pipelines are the same in both versions (simple element tests, ancestor and descendant tests, string-based attribute tests, etc.). As an aid to interoperability, pipeline authors may indicate the version of XPath that they require. The attribute xpath-version p:pipeline p:declare-step p:library must Note In Version 1.0 of XProc, no similar level of control is provided for specifying (or testing) the version of XSLT used when evaluating XSLTMatchPattern As XPath, XSLT, and XProc continue to evolve, additional facilities for specifying and testing the version of XSLT used to evaluate match patterns may be added to XProc. If an xpath-version p:pipeline p:declare-step xpath-version p:library implementation-defined Note The decision about which XPath version applies can be made dynamically. For example, if a pipeline explicitly labeled with xpath-version xpath-version The following rules determine how the indicated version and the implementation's actual version interact: If the indicated version and the implementation version are the same, then that version is used. If the indicated version is 1.0 and the implementation uses XPath 2.0 (or later), the expression must dynamic error err:XD0024 Otherwise: dynamic error err:XD0027 xpath-version XProc processors divide naturally into two classes: XPath 1.0 processors and XPath 2.0 processors. Irrespective of which version of XPath is used, all expressions evaluated by XProc or passed to steps for evaluation must be valid XPath expressions. dynamic error err:XD0023 XProc processors that support only XPath 1.0 do not support any types (or features) beyond those described in [ XPath 1.0 must XSLT 1.0 When the XProc processor evaluates an XPath expression using XPath 1.0, unless otherwise indicated by a particular step, it does so with the following initial context: context node The document node of a document. The document is either specified with a connection default readable port dynamic error err:XD0008 If there is no explicit connection and there is no default readable port then the context node is an empty document node. context position and context size The context position and context size are both “1”. variable bindings The union of the in-scope specified options Note An option that has neither a specified value nor a default value will not appear as an in-scope variable. Consequently, an attempt to refer to that variable will raise an error. function library The [ XPath 1.0 Section 2.7, “XPath Extension Functions” does not in-scope namespaces The namespace bindings in-scope on the element where the expression occurred. When a step context node The document node that appears on the primary input port of the step, unless otherwise specified by the step. context position and context size The position and size are both “1”, unless otherwise specified by the step. variable bindings None, unless otherwise specified by the step. function library The [ XPath 1.0 does not in-scope namespaces The set of namespace bindings provided by the XProc processor. The processor computes this set of bindings by taking a union of the bindings on the step element itself as well as the bindings on any of the options and parameters used in computing values for the step (see Section 5.7.5, “Namespaces on variables, options, and parameters” implementation-dependent Note Some steps may also provide for implementation-defined or implementation-dependent amendments to the contexts. Those amendments are in addition to any specified by XProc. XProc processors that support XPath 2.0 are XPath 2.0 processors. Such processors can refer to the primitive atomic schema types, but cannot import additional types. XPath 2.0 processors must XSLT 2.0 When the XProc processor evaluates an XPath expression using XPath 2.0, unless otherwise indicated by a particular step, it does so with the following static context: XPath 1.0 compatibility mode Is true if the indicated XPath version is 1.0, false otherwise. Statically known namespaces The namespace declarations in-scope for the containing element. Default element/type namespace The null namespace. Default function namespace The [ XPath 2.0 does not In-scope schema definitions A basic XPath 2.0 XProc processor includes the following named type definitions in its in-scope schema definitions: All the primitive atomic types defined in [ W3C XML Schema: Part 2 xs:NOTATION xs:string xs:boolean xs:decimal xs:double xs:float xs:date xs:time xs:dateTime xs:duration xs:QName xs:anyURI xs:gDay xs:gMonthDay xs:gMonth xs:gYearMonth xs:gYear xs:base64Binary xs:hexBinary The derived atomic type xs:integer W3C XML Schema: Part 2 The types xs:anyType xs:anySimpleType xs:yearMonthDuration xs:dayTimeDuration xs:anyAtomicType xs:untyped xs:untypedAtomic XQuery 1.0 and XPath 2.0 Data Model (XDM) In-scope variables The union of the in-scope specified options Note An option that has neither a specified value nor a default value will not appear as an in-scope variable. Consequently, an attempt to refer to that variable will raise an error. Context item static type Document. Function signatures The signatures of the [ XPath 2.0 Functions and Operators Section 2.7, “XPath Extension Functions” Statically known collations Implementation-defined but must implementation-defined Default collation Unicode code point collation. Base URI The base URI of the element on which the expression occurs. Statically known documents None. Statically known collections None. And the following dynamic context: context item The document node of a document. The document is either specified with a connection default readable port dynamic error err:XD0008 If there is no explicit connection and there is no default readable port then the context node is undefined. context position and context size The context position and context size are both “1”. Variable values The union of the in-scope options and variables are available as variable bindings to the XPath processor. Function implementations The [ XPath 2.0 Functions and Operators Section 2.7, “XPath Extension Functions” Current dateTime implementation-defined Implicit timezone implementation-defined Available documents implementation-dependent Available collections implementation-dependent Default collection None. When a step evaluates an XPath expression using XPath 2.0, unless otherwise indicated by a particular step, it does so with the following static context: XPath 1.0 compatibility mode Is true if the indicated XPath version is 1.0, false otherwise. Statically known namespaces The namespace declarations in-scope for the containing element or made available through p:namespaces Default element/type namespace The null namespace. Default function namespace The [ XPath 2.0 does not In-scope schema definitions The same as the Section 2.6.2.1, “Processor XPath Context” In-scope variables None, unless otherwise specified by the step. Context item static type Document. Function signatures The signatures of the [ XPath 2.0 Functions and Operators Statically known collations Implementation-defined but must Default collation Unicode code point collation. Base URI The base URI of the element on which the expression occurs. Statically known documents None. Statically known collections None. And the following initial dynamic context: context item The document node of the document that appears on the primary input of the step, unless otherwise specified by the step. context position and context size The context position and context size are both “1”, unless otherwise specified by the step. Variable values None, unless otherwise specified by the step. Function implementations The [ XPath 2.0 Functions and Operators Current dateTime An implementation-defined point in time. Implicit timezone implementation-defined Available documents implementation-dependent Available collections None. Default collection None. Note Some steps may also provide for implementation-defined or implementation-dependent amendments to the contexts. Those amendments are in addition to any specified by XProc. The XProc processor must In the following descriptions, the names of types ( string boolean W3C XML Schema: Part 2 XPath expressions within a pipeline document can interrogate the processor for information about the current state of the pipeline. Various aspects of the processor are exposed through the p:system-property p:system-property ( $property as xs:string ) as xs:string The $property QName dynamic error err:XD0015 p:system-property must Implementations must p:episode Returns a string which should 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 localization purposes. implementation-defined should xml:lang p:product-name Returns a string containing the name of the implementation, as defined by the implementer. This should normally remain constant from one release of the product to the next. It should also be constant across platforms in cases where the same source code is used to produce compatible products for multiple execution platforms. p:product-version Returns a string identifying the version of the implementation, as defined by the implementer. This should normally vary from one release of the product to the next, and at the discretion of the implementer it may also vary across different execution platforms. p:vendor Returns a string which identifies the vendor of the processor. p:vendor-uri Returns a URI which identifies the vendor of the processor. Often, this is the URI of the vendor's web site. p:version Returns the version(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 only XProc 2.0 would return “2.0”. p:xpath-version Returns the version(s) of XPath implemented by the processor for evaluating XPath expressions on XProc elements. The result is a space-separated list of versions supported. For example, a processor that only supports XPath 1.0 would return “1.0”; a processor that supports XPath 2.0 and XPath 1.0 backwards compatibility mode could return “1.0 2.0”; a processor that supports only XPath 2.0 would return “2.0”. p:psvi-supported Returns true if the implementation supports passing PSVI annotations between steps, false otherwise. Implementations may support additional system properties but such properties must must not The p:step-available p:step-available ( $step-name as xs:string ) as xs:boolean The $step-type must p:step-available The p:value-available p:value-available ( $option-name as xs:string ) as xs:boolean p:value-available ( $option-name as xs:string , $fail-if-unknown as xs:boolean ) as xs:boolean The $option-name must p:value-available in-scope binding dynamic error err:XD0033 In the two-argument form, it is not an error to specify a name that is not the name of an in-scope option or variable if $fail-if-unknown $fail-if-unknown Consider the following example: <p:declare-step type="ex:dir-list"> <p:output port="result"/> <p:option name="path"/>

<p:choose> <p:when test="p:value-available('path')"> <p:directory-list> <p:with-option 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 ex:dir-list p:when p:otherwise . Both p:for-each p:viewport p:iteration-position p:for-each p:viewport p:iteration-position ( ) as xs:integer If there is no p:for-each p:viewport p:iteration-position Both p:for-each p:viewport p:iteration-size p:for-each p:viewport p:iteration-size ( ) as xs:integer If there is no p:for-each p:viewport p:iteration-size Returns the base URI of the specified node, if it has one. This function provides an interoperable way for XPath 1.0 based processors to access the base URI of a node. It is conceptually the same as the XPath 2.0 fn:base-uri() p:base-uri ( ) as xs:string p:base-uri ( $node as node() ) as xs:string If no argument is specified, the context node is taken to be the argument. This function returns the [base-uri] Note This function is defined in our namespace because it would be inappropriate to require XPath 1.0 based processors to support the fn:base-uri Resolves a relative URI with respect to a particular base URI. This function provides an interoperable way for XPath 1.0 based processors to compose URI references. It is conceptually the same as the XPath 2.0 fn:resolve-uri() p:resolve-uri ( $relative as xs:string ) as xs:string p:resolve-uri ( $relative as xs:string , $base as xs:string ) as xs:string If no base is specified, the base URI of the context node is used. Note This function is defined in our namespace because it would be inappropriate to require XPath 1.0 based processors to support the fn:resolve-uri Returns true if and only if the processor supports the version specified. p:version-available ( $version as xs:decimal ) as xs:boolean A version 1.0 processor will return true() p:version-available(1.0) Returns true if and only if the processor supports the XPath version specified. p:xpath-version-available ( $version as xs:decimal ) as xs:boolean A processor that supports XPath 2.0 will return true() p:xpath-version-available(2.0) implementation-defined must not XML documents flow between steps in an XProc pipeline. Section A.3, “Infoset Conformance” must may implementation-defined implementation-defined A pipeline can use the p:psvi-supported A pipeline can assert that PSVI support is required with the psvi-required On a p:pipeline p:declare-step psvi-required dynamic error err:XD0022 On a p:library psvi-required p:pipeline p:declare-step children Many of the steps that an XProc pipeline can use are transformative in nature. The p:delete p:label-elements In order to avoid these inconsistencies, most steps must not If PSVI passing is supported, the following constraints apply: Implementations must When only a subset of the input is processed by a step (because a select match must Note that ID/IDREF constraints, and any other whole-document constraints, may not be satisfied within the selected portion, irrespective of what its PSVI properties claim. If an output of a compound step is connected to an output which includes PSVI properties, those properties must except p:viewport must not If an implementation supports XPath 2.0, the data model constructed with which to evaluate XPath expressions and match patterns should Except as specified above, or in the descriptions of individual steps, implementations must not implementation-defined The exceptions in the standard XProc steps are the p:validate-with-xml-schema p:validate-with-relax-ng p:validate-with-schematron p:xslt p:xquery p:identity p:split-sequence Note A processor that supports passing PSVI properties between steps is always free to do so. Even if psvi-required="false" Variables are name/value pairs. Pipeline authors can create variables to hold computed values. [Definition: A variable expanded name must xs:untypedAtomic Variables and options share the same scope and may shadow each other. Some steps accept options. Options are name/value pairs, like variables. Unlike variables, the value of an option can be changed by the caller. [Definition: An option expanded name must xs:untypedAtomic [Definition: The options declared on a step are its declared options [Definition: The options on a step which have specified values, either because a p:with-option specified options implementation-defined Some steps accept parameters. Parameters are name/value pairs, like variables and options. Unlike variables and options, which have names known in advance to the pipeline, parameters are not declared and their names may be unknown to the pipeline author. Pipelines can dynamically construct sets of parameters. Steps can read dynamically constructed sets on parameter input ports [Definition: A parameter expanded name must xs:untypedAtomic [Definition: A parameter input port Section 5.1.2, “Parameter Inputs” Analogous to primary input ports [Definition: If a step has a parameter input port which is explicitly marked “ primary='true' not primary='false' primary parameter input port primary='false' implementation-defined An XProc pipeline may attempt to access arbitrary network resources: steps such as p:load p:http-request p:store p:exec p:xslt p:xquery In some environments, it may be inappropriate to provide the XProc pipeline with access to these resources. In a server environment, for example, it may be impractical to allow pipelines to store data. In environments where the pipeline cannot be trusted, allowing the pipeline to access arbitrary resources or execute arbitrary code may be a security risk. dynamic error err:XD0021 implementation-dependent Steps in a pipeline may call themselves recursively which could result in pipelines which will never terminate. A conformant XProc processor may limit the resources available to any or all steps in a pipeline. A conformant implementation may raise dynamic errors, or take any other corrective action, for any security problems that it detects. A pipeline author may version version p:declare-step p:pipeline p:library version must xs:decimal static error err:XS0063 version xs:decimal The version of XProc defined by this specification is “ 1.0 A pipeline author must static error err:XS0062 version The version identified applies to the element on which the version When a processor encounters an explicit version (other than a version which it implements), it proceeds in backwards- or forwards-compatible mode. If the processor encounters a request for a previous version of XProc (e.g, if a "2.0" processor encounters an explicit request for the "1.0" language), it must must must static error err:XS0060 If the processor encounters an explicit version 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 conditionally uses new language features. In forwards-compatible mode: On any element in the XProc namespace, unrecognized attributes (other than extension attributes) are ignored. On any step in the XProc namespace, unknown options are ignored. If a step in the XProc namespace includes an unknown input port with an explicit connection, the connection is treated normally for the purpose of computing the dependencies in the pipeline but it is otherwise ignored. Unknown input ports must not primary input ports If a step in the pipeline includes an explicit connection to an unknown output port on a step in the XProc namespace, the connection is treated normally for the purpose of computing the dependencies in the pipeline. An empty sequence of documents must As a consequence of the rules above, future specifications must not should must not primary input ports 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 Suppose that XProc version 2.0 changes the definition of the p:xslt messages <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="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 on the messages messages messages This section describes the normative XML syntax of XProc. This syntax is sufficient to represent all the aspects of a pipeline, as set out in the preceding sections. [Definition: XProc is intended to work equally well with [ XML 1.0 XML 1.1 XML [Definition: Unless otherwise noted, the term Namespaces in XML Namespaces 1.0 Namespaces 1.1 implementation-defined Elements in a pipeline document represent the pipeline, the steps it contains, the connections between those steps, the steps and connections contained within them, and so on. Each step is represented by an element; a combination of elements and attributes specify how the inputs and outputs of each step are connected and how options and parameters are passed. Conceptually, we can speak of steps as objects that have inputs and outputs, that are connected together and which may contain additional steps. Syntactically, we need a mechanism for specifying these relationships. Containment compound step subpipeline The connections between steps are expressed using names and references to those names. Six kinds of things are named in XProc: Step types, Steps, Input ports (both parameter and document), Output ports, Options and variables, and Parameters There are three namespaces associated with XProc: http://www.w3.org/ns/xproc The namespace of the XProc XML vocabulary described by this specification; by convention, the namespace prefix “ p: http://www.w3.org/ns/xproc-step The namespace used for documents that are inputs to and outputs from several standard and optional steps described in this specification. Some steps, such as p:http-request p:store c: http://www.w3.org/ns/xproc-error The namespace used for errors. The conventional prefix “ err: This specification also makes use of the prefix “ xs: W3C XML Schema: Part 1 http://www.w3.org/2001/XMLSchema Names are used to identify step types, steps, ports, options and variables, and parameters. Step types, options, variables, and parameters 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. [Definition: If two names are in the same scope, we say that they are visible The scope of the names of the step types is the pipeline in which they are declared, including any declarations imported from libraries via p:import In other words, the step types that are in scope in a p:pipeline p:declare-step The standard, built-in types ( p:pipeline p:choose Any implementation-provided types. Any step types declared in the pipeline (the p:pipeline p:declare-step The types of any p:pipeline p:declare-step Any types that are in the scope of any p:library Any step types that are in scope for the pipeline's parent p:pipeline p:declare-step The type of the pipeline itself, if it has one. The step types that are in scope in a p:library The standard, built-in types ( p:pipeline p:choose Any implementation-provided types. Any step types declared in the library (the p:pipeline p:declare-step p:library The types of p:pipeline p:declare-step Any types that are in the scope of any p:library must static error err:XS0036 The scope of the names of the steps themselves is determined by the environment must static error err:XS0002 The scope of an input or output port name is the step on which it is defined. The names of all the ports on any step must Taken together, these uniqueness constraints guarantee that the combination of a step name and a port name uniquely identifies exactly one port on exactly one in-scope step. The scope of option and variable names is determined by where they are declared. When an option is declared with p:option p:variable static error err:XS0004 environment Parameter names are not scoped; they are distinct on each step. When a relative URI appears in an option value, the base URI against which it must p:option syntactic shortcut must The pipeline author can control the base URIs of elements within the pipeline document with the xml:base xml:base may XML Base A pipeline author can provide a globally unique identifier for any element in a pipeline with the xml:id The xml:id may xml:id [Definition: A connection by source by URI inline document explicitly empty p:input p:output p:xpath-context p:iteration-source p:viewport-source Specified by URI [Definition: A document is specified by URI href p:document p:data In this example, the input to the p:identity otherstep 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 [Definition: A document is specified by source step port p:pipe In this example, the “ source p:xinclude expand result otherstep <p:xinclude name="expand"> <p:input port="source"> <p:pipe step="otherstep" port="result"/> </p:input> </p:xinclude> See the description of p:pipe Specified inline [Definition: An inline document p:inline In this example, the “ stylesheet xform p:input <p:xslt name="xform"> <p:input port="stylesheet"> <p:inline> <xsl:stylesheet version="1.0"> ... </xsl:stylesheet> </p:inline> </p:input> </p:xslt> Inline documents are considered “quoted”. The pipeline processor passes them literally to the port, even if they contain elements from the XProc namespace or other namespaces that would have other semantics outside of the p:inline Specified explicitly empty [Definition: An empty sequence p:empty In this example, the “ source generate <p:xslt name="generate" version="2.0"> <p:input port="source"> <p:empty/> </p:input> <p:input port="stylesheet"> <p:inline> <xsl:stylesheet version="2.0"> ... </xsl:stylesheet> </p:inline> </p:input> <p:with-option name="template-name" select="'someName'"/> </p:xslt> If you omit the connection on a primary input port, a connection to the default readable port It is inconsistent with the [ XPath 1.0 must Note that a p:input p:output p:pipe p:document p:data p:inline connection Pipeline authors may add documentation to their pipeline documents with the p:documentation p:inline p:documentation p:documentation p:inline p:documentation Pipeline processors that inspect the contents of p:documentation not conformant must p:pipeinfo Pipeline authors may add annotations to their pipeline documents with the p:pipeinfo p:pipeinfo implementation-defined should extension attributes Where p:documentation p:pipeinfo When a p:pipeinfo p:inline must p:pipeinfo [Definition: An element from the XProc namespace may extension attribute The presence of an extension attribute must not cause the connections between steps to differ from the connections 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 extension attribute that it does not implement must Any element in the XProc namespace may have a use-when must must Elements that are not in the XProc namespace may use-when p:use-when use-when Conditional element exclusion occurs before any static analysis of the pipeline. Note The effective exclusion of use-when use-when p:inline For the purposes of evaluating a use-when in-scope bindings There are some additional restrictions on the XPath extension functions that are available in a use-when The p:episode should not p:episode use-when implementation-dependent The p:step-available use-when implementation-dependent The steps available and possibly other aspects of the expression may depend on the version specified for a pipeline, see Section 2.13, “Versioning Considerations” should not static error err:XS0061 use-when The description of each element in the pipeline namespace is accompanied by a syntactic summary that provides a quick overview of the element's syntax: <p:some-element some-type some elements allowed other-elements? The content model fragments in these tableaux are presented in a simple, compact notation. In brief: A name represent exactly one 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 question mark (“?”) is optional; it may or may not occur but if it occurs it can occur only once. An element or group followed by an asterisk (“*”) is optional 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 once, and it can occur any number of times. For clarity of exposition, some attributes and elements are elided from the summaries: An xml:id xml:id An xml:base XML Base A use-when Section 3.9, “Conditional Element Exclusion” The p:documentation p:pipeinfo The p:log p:output Attributes that are syntactic shortcuts for option values The types given for attributes should be understood as follows: ID NCName NMTOKEN NMTOKENS anyURI boolean integer string W3C XML Schema: Part 2 QName W3C XML Schema: Part 2 QName Namespaces in XML p:option p:with-param p:namespaces PrefixList [item type] NMTOKEN W3C XML Schema: Part 2 XPathExpression XSLTMatchPattern W3C XML Schema: Part 2 XPath 1.0 XPath 2.0 XSLT 1.0 XSLT 2.0 A number of errors apply generally: static error err:XS0059 p:pipeline p:declare-step p:library static error err:XS0008 extension attributes static error err:XS0038 dynamic error err:XD0028 static error err:XS0044 static error err:XS0037 dynamic error err:XD0019 static error err:XS0015 contained steps dynamic error err:XD0012 should file: http(s): implementation-defined dynamic error err:XD0030 In most steps which use a select expression or match pattern, any kind of node can be identified by the expression or pattern. However, some expressions and patterns on some steps are only applicable to some kinds of nodes (e.g., it doesn't make sense to speak of adding attributes to a comment!). dynamic error err:XC0023 If an XProc processor can determine statically that a dynamic error will always may does not p:try p:try must not p:catch This section describes the core steps of XProc. Several of the steps defined in this specification refer to other, evolving XML technologies (XSLT, XQuery, XSL-FO, etc.). Where this specification identifies a specific version of a technology, implementors must A p:pipeline subpipeline p:pipeline step declaration All p:pipeline primary input port source primary parameter input port parameters primary output port result p:pipeline in addition <p:pipeline NCName QName boolean string prefix list string p:input p:output p:option p:log p:serialization p:declare-step p:pipeline p:import subpipeline Viewed from the outside, a p:pipeline contained steps The version p:pipeline must version Section 2.13, “Versioning Considerations” If a pipeline does not have a type The p:pipeline <p:pipeline some-attributes some-content can be interpreted as if it read: <p:declare-step some-attributes some-content See p:declare-step A pipeline might accept a document as input; perform XInclude, validation, and transformation; and produce the transformed document as its output. Example 4. A Sample Pipeline Document <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="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> A for-each is specified by the p:for-each compound step subpipeline <p:for-each NCName p:iteration-source p:output p:log subpipeline When a pipeline needs to process a sequence of documents using a subpipeline that only processes a single document, the p:for-each p:for-each The result of the p:for-each p:for-each p:for-each The p:iteration-source connection p:for-each default readable port The processor provides each document, one at a time, to the subpipeline p:for-each current For each declared output, the processor collects all the documents that are produced for that output from all the iterations, in order, into a sequence. The result of the p:for-each The environment inherited by the contained steps p:for-each inherited environment The port named “ current p:for-each readable ports The port named “ current p:for-each default readable port If the p:for-each primary output port supplied by default connection primary output port last step subpipeline static error err:XS0006 last step Note that outputs declared for a p:for-each p:for-each p:for-each The sequence p:output p:for-each Within a p:for-each p:iteration-position p:iteration-size p:for-each p:iteration-size current p:iteration-position Note to implementers In the case where no XPath expression that must be evaluated by the processor makes any reference to p:iteration-size A p:for-each Example 5. A Sample For-Each <p:for-each name="chapters"> <p:iteration-source select="//chapter"/> <p:output port="html-results"> <p:pipe step="make-html" port="result"/> </p:output> <p:output port="fo-results"> <p:pipe step="make-fo" port="result"/> </p:output>

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

<p:xslt name="make-fo"> <p:input port="source"> <p:pipe step="chapters" port="current"/> </p:input> <p:input port="stylesheet"> <p:document href="http://example.com/xsl/fo.xsl"/> </p:input> </p:xslt> </p:for-each> The //chapter html-results fo-results chapters A viewport is specified by the p:viewport compound step subpipeline <p:viewport NCName match XSLTMatchPattern p:viewport-source p:output p:log subpipeline The result of the p:viewport The p:viewport-source connection p:viewport default readable port dynamic error err:XD0003 The match subpipeline current dynamic error err:XD0010 match p:viewport 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 among the descendants of any matched node. The environment inherited by the contained steps p:viewport inherited environment The port named “ current p:viewport readable ports The port named “ current p:viewport default readable port The p:viewport primary output port supplied by default connection primary output port last step subpipeline static error err:XS0006 last step What appears on the output from the p:viewport current p:viewport output If no documents appear on the output The output of the p:viewport result p:viewport output p:viewport result Within a p:viewport p:iteration-position p:iteration-size p:viewport p:iteration-size current p:iteration-position Note to implementers In the case where no XPath expression that must be evaluated by the processor makes any reference to p:iteration-size A p:viewport hr div Example 6. A Sample Viewport <p:viewport match="h:div[@class='chapter']" xmlns:h="http://www.w3.org/1999/xhtml"> <p:insert position="first-child"> <p:input port="insertion"> <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'] hr h:div h:div h:div A choose is specified by the p:choose multi-container step subpipelines <p:choose NCName p:xpath-context p:variable p:when p:otherwise A p:choose subpipelines The list of alternative subpipelines consists of zero or more subpipelines guarded by an XPath expression, followed optionally by a single default subpipeline. The p:choose After a subpipeline The outputs of the p:choose subpipeline p:choose primary output port p:choose In order to ensure that the output of the p:choose subpipeline subpipeline primary output port static error err:XS0007 subpipelines p:choose As a convenience 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 dynamic error err:XD0004 subpipeline p:choose The p:choose connection p:xpath-context default readable port p:empty default readable port empty document node Each conditional subpipeline p:when p:otherwise A p:xpath-context p:when p:when test p:choose p:when p:choose <p:xpath-context> p:empty p:pipe p:document p:inline p:data Only one connection p:input select dynamic error err:XD0005 xpath-context The p:xpath-context In an XPath 1.0 implementation, if the context node is connected to p:empty default readable port empty document node A when specifies one subpipeline guarded by a test expression. <p:when test XPathExpression p:xpath-context p:output p:log subpipeline Each p:when p:choose test must subpipeline p:when The p:when test connection p:xpath-context p:when p:choose An otherwise specifies the default branch; the subpipeline selected if no test expression on any preceding p:when <p:otherwise> p:output p:log subpipeline A p:choose Example 7. A Sample Choose <p:choose name="version"> <p:when test="/*[@version = 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="/*[@version = 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="/*[@version]"> <p:identity/> </p:when>

<p:otherwise> <p:error code="NOVERSION"> <p:input port="source"> <p:inline> <message>Required version attribute missing.</message> </p:inline> </p:input> </p:error> </p:otherwise> </p:choose> A group is specified by the p:group p:try compound step subpipeline <p:group NCName p:output p:log subpipeline A p:group Example 8. An Example Group <p:group> <p:variable name="db-key" select="'some-long-string-of-nearly-random-characters'"/>

<p:choose> <p:when test="/config/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="/config/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> A try/catch is specified by the p:try multi-container step subpipeline <p:try NCName p:variable p:group p:catch The p:group p:catch The p:try p:try p:try If the recovery subpipeline is evaluated, the outputs of the recovery subpipeline are the outputs of the p:try p:try The outputs of the p:try p:try primary output port p:try In order to ensure that the output of the p:try primary output port static error err:XS0009 p:group p:catch As a convenience 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 A pipeline author can cause an error to occur with the p:error The recovery subpipeline of a p:try p:catch <p:catch NCName p:output p:log subpipeline The environment inherited by the contained steps p:catch inherited environment The port named “ error p:catch readable ports What appears on the error error document xsl:message error In general, it is very difficult to predict error behavior. Step failure may be catastrophic (programmer error), or it may be be the result of user error, resource failures, etc. Steps may detect more than one error, and the failure of one step may cause other steps to fail as well. The p:try p:catch p:try error p:catch should The error vocabulary consists of a root element, c:errors c:error <c:errors> c:error Each specific error is represented by an c:error <c:error NCName QName QName anyURI integer integer integer string anyElement The name type The code If the error was caused by a specific document, or by the location of some erroneous construction in a specific document, the href line column offset The content of the c:error Consider the following XSLT stylesheet: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

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

</xsl:stylesheet> If it was used in a step named “xform” in a p:try <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 non-standard error output as long as it is well-formed. A pipeline might attempt to process a document by dispatching it to some web service. If the web service succeeds, then those results are passed to the rest of the pipeline. However, if the web service cannot be contacted or reports an error, the p:catch 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-action"> <c:body content-type="application/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> In addition to the six step types described in the preceding sections, XProc provides a standard library of atomic step types. The full vocabulary of standards steps is described in Section 7, “Standard Step Library” All of the standard, atomic steps are invoked in the same way: < p:atomic-step NCName p:input p:with-option p:with-param p:log p:atomic-step Where “ p:atomic-step must must Section 2.13, “Versioning Considerations” Pipeline authors may also have access to additional steps not defined or described by this specification. Atomic extension steps are invoked just like standard steps: < pfx:atomic-step NCName p:input p:with-option p:with-param p:log pfx:atomic-step Extension steps must not must visible Section 3.2, “Scoping of Names” If the relevant step declaration has no subpipeline If the relevant step declaration has a subpipeline static error err:XS0010 match signature dynamic error err:XD0017 compound steps implementation-defined static error err:XS0048 compound step Namespace qualified attributes on a step are extension attributes name The first step uses the standard p:with-option <ex:stepType> <p:with-option name="option-name" select="'some value'"/> </ex:stepType> The second step uses the syntactic shortcut: <ex:stepType option-name="some value"/> Note that there are significant limitations to this shortcut syntax: It only applies to option names that are not in a namespace. It only applies to option names that are not otherwise used on the step, such as “ name It can only be used to specify a constant value. Options that are computed at runtime must be written using the longer form. static error err:XS0027 static error err:XS0031 atomic step The syntactic shortcuts apply equally to standard atomic steps and extension atomic steps. A p:input p:input p:input The declaration of a document 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 An input declaration <p:input port NCName boolean boolean XPathExpression p:empty p:document p:inline p:data The port static error err:XS0011 The sequence sequence dynamic error err:XD0006 The primary primary input port primary input port primary true primary static error err:XS0030 The kind kind document kind If a connection is provided in the declaration, then select p:empty p:document p:data p:inline p:input only Note The p:pipe On a p:declare-step p:input static error err:XS0042 An input connection <p:input port NCName XPathExpression p:empty p:pipe p:document p:inline p:data If no connection is provided for a primary input port default readable port static error err:XS0032 default readable port A select may select <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, one for each html:div http://example.org/input.html html:div A select expression 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, one for each html:div result origin The base URI of the document that results from a select expression is the base URI of the matched element or document. dynamic error err:XD0016 select p:input An input declaration may include a default connection. If no connection is provided for an input port which has a default connection, then the input is treated as if the default connection appeared. A default connection does not satisfy the requirement that a primary input port is automatically connected by the processor, nor is it used when no default readable port is defined. In other words, a p:declare-step p:pipeline p:pipeline must The declaration of a parameter input identifies the name of the port and that the port is a parameter input. <p:input port NCName boolean boolean kind p:empty p:document p:inline The port static error err:XS0011 The sequence static error err:XS0040 true The primary primary parameter input port primary parameter input port parameter input port primary true primary static error err:XS0030 The kind kind static error err:XS0033 A parameter input port is a distinguished kind of input port. It exists only to receive computed parameters; if a step does not have a parameter input port then it cannot receive parameters. A parameter input port must satisfy all the constraints of a normal, document input port. static error err:XS0035 When used on a step, parameter input ports are connected just like ordinary document ports. Parameter input ports always accept a sequence of documents. If no explicit connection is provided for a primary parameter input port empty sequence static error err:XS0055 p:with-param In other words, it is an error to leave a parameter input port unconnected, but any parameter passed explicitly to that port satisfies the connection requirement. This is an error: <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="1.0"> <p:input port="source"/> <p:output port="result"/>

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

</p:declare-step> The parameter input port on the p:xslt This is not an error: <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="1.0"> <p:input port="source"/> <p:output port="result"/>

<p:xslt> <p:input port="stylesheet"> <p:document href="http://example.com/stylesheets/doc.xsl"/> </p:input> <p:with-param name="mode" select="'debug'"/> </p:xslt>

</p:declare-step> Explicitly setting the “ mode p:xslt This, also, is not an error: <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0">

<p:xslt> <p:input port="stylesheet"> <p:document href="http://example.com/stylesheets/doc.xsl"/> </p:input> <p:with-param name="mode" select="'debug'"/> </p:xslt>

</p:pipeline> The parameter input port on the p:xslt p:xslt mode If a parameter input port on a p:pipeline p:sink p:pipeline A step which accepts a parameter input reads all of the documents presented on that port, using each c:param c:param-set p:with-param p:with-param p:with-param If a connection is manufactured for a primary parameter input port, that connection occurs logically last among the other parameters, options, and connections passed to the step. In other words, the parameter values that appear on that port will be used even if other values were specified with p:with-param p:with-param All of the documents that appear on a parameter input must either be c:param c:param-set Consider the example in Example 10, “A Parameter Example” Example 10. A Parameter Example <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0" name="main">

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

</p:pipeline> This p:pipeline implementation-defined output-type fo profile unclassified parameters When the XSLT step runs, it will read those parameters and combine them with any parameters specified literally on the step. Because the parameter input comes after output-type output-type fo profile unclassified If the parameter input came before output-type html profile unclassified Most steps don't bother to declare parameter inputs, or provide explicit connections for them, and “the right thing” usually happens. A c:param <c:param name QName anyURI value string The name c:param If the namespace name dynamic error err:XD0025 namespace name If the namespace name name c:param If the namespace name Any namespace-qualified attribute names that appear on the c:param dynamic error err:XD0014 name namespace value c:param A c:param-set <c:param-set> c:param The c:param-set c:param dynamic error err:XD0018 c:param Any namespace-qualified attribute names that appear on the c:param-set dynamic error err:XD0014 c:param-set A p:iteration-source p:for-each <p:iteration-source XPathExpression p:empty p:pipe p:document p:inline p:data The select connection p:iteration-source p:input A p:viewport-source p:viewport <p:viewport-source> p:pipe p:document p:inline p:data Only one connection p:input dynamic error err:XD0003 p:viewport-source select A p:output <p:output port NCName boolean boolean The port static error err:XS0011 An output declaration can indicate if a sequence of documents is allowed to appear on the declared port. If sequence true sequence p:output dynamic error err:XD0007 The primary primary true static error err:XS0014 On compound steps may connection <p:output port NCName boolean boolean p:empty p:pipe p:document p:inline p:data static error err:XS0029 p:output p:declare-step If a connection is provided for a p:output read from is written p:document p:output read that document does not write A p:log <p:log port NCName anyURI The semantics of p:log href implementation-defined p:log implementation-defined p:log implementation-dependent static error err:XS0026 p:log p:log Implementations may, at user option, ignore all p:log Note This element represents a potential security risk: running unexamined 3rd-party pipelines could result in vital system resources being overwritten. The p:serialization p:pipeline <p:serialization port NCName boolean NMTOKENS string string string boolean boolean boolean string QName NFC|NFD|NFKC|NFKD|fully-normalized|none|xs:NMTOKEN boolean true|false|omit boolean string If the pipeline processor serializes the output on the specified port, it must p:serialization must may p:serialization implementation-defined Serialization dynamic error err:XD0020 must may The semantics of the attributes on a p:serialization Section 7.3, “Serialization Options” static error err:XS0039 p:serialization p:serialization Variables, options, and parameters provide a mechanism for pipeline authors to construct temporary results and hold onto them for reuse. Variables are created in compound steps and, like XSLT variables, are single assignment, though they may be shadowed by subsequent declarations of other variables with the same name. Options can be declared on atomic or compound steps. The value of an option can be specified by the caller invoking the step. Any value specified by the caller takes precedence over any default value specified in the declaration. Parameters, unlike options and variables, have names that can be computed at runtime. The most common use of parameters is to pass parameter values to XSLT stylesheets. A p:variable The name of the variable must static error err:XS0028 The variable's value is specified with a select select must select <p:variable name QName select XPathExpression p:empty p:pipe p:document p:inline p:data p:namespaces If a select Section 2.6, “XPaths in XProc” container p:variable p:option xs:untypedAtomic Since all in-scope bindings select in-scope bindings in-scope binding If a select readable ports readable ports container contained steps static error err:XS0019 container contained steps If a select default readable port container contained steps p:empty dynamic error err:XD0008 p:variable p:empty empty document node dynamic error err:XD0026 select A p:option p:option p:declare-step p:pipeline The name of the option must static error err:XS0028 static error err:XS0004 <p:option name QName boolean An option may be declared as required static error err:XS0018 If an option is not declared to be required, it may select <p:option name QName boolean select XPathExpression If a select The select Section 5.7.3, “p:with-option” In an XPath 1.0 implementation, an empty document node the variable bindings consist only of bindings for options whose declaration precedes the p:option signature the in-scope namespaces are the in-scope namespaces of the p:option static error err:XS0017 required and dynamic error err:XD0026 select Regardless of the implicit type of the expression, when XPath 1.0 is being used, the string value of the expression becomes the value of the option; when XPath 2.0 is being used, the value is an xs:untypedAtomic A p:with-option The name of the option must static error err:XS0031 p:with-option forwards-compatible mode static error err:XS0004 p:with-option The actual value is specified with a select select must select <p:with-option name QName select XPathExpression p:empty p:pipe p:document p:inline p:data p:namespaces Regardless of the implicit type of the expression, when XPath 1.0 is being used, the string value of the expression becomes the value of the option; when XPath 2.0 is being used, the value is an xs:untypedAtomic All in-scope bindings select in-scope bindings in-scope binding If a select default readable port p:empty dynamic error err:XD0008 p:with-option p:empty empty document node dynamic error err:XD0026 select The p:with-param must The name of the parameter must dynamic error err:XD0031 The value is specified with a select select must select <p:with-param name QName select XPathExpression NCName p:empty p:pipe p:document p:inline p:data p:namespaces The values of parameters for a step must signature select p:with-param Section 2.6, “XPaths in XProc” signature Regardless of the implicit type of the expression, when XPath 1.0 is being used, the string value of the expression becomes the value of the parameter; when XPath 2.0 is being used, the value is an xs:untypedAtomic All in-scope bindings select in-scope bindings in-scope binding If a select default readable port p:empty dynamic error err:XD0008 p:with-param p:empty empty document node dynamic error err:XD0026 select If the optional port primary parameter input port static error err:XS0034 Variable, option and parameter values carry with them not only their literal or computed string value but also a set of namespaces. To see why this is necessary, consider the following step: <p:delete xmlns:p="http://www.w3.org/ns/xproc"> <p:with-option name="match" select="'html:div'" xmlns:html="http://www.w3.org/1999/xhtml"/> </p:delete> The p:delete html:div html The default namespace bindings associated with a variable, option or parameter value are computed as follows: If the select VariableReference XPath 1.0 XPath 2.0 If the select The expression is evaluated in the appropriate context, See Section 2.6, “XPaths in XProc” Otherwise, the in-scope namespaces from the element providing the value are used. (For options specified using syntactic shortcuts The default namespace is never included in the namespace bindings for a variable, option or parameter value. Unqualified names are always in no-namespace. Unfortunately, in more complex situations, there may be no single variable, option or parameter that can reliably be expected to have the correct set of namespace bindings. Consider this pipeline: <p:pipeline type="ex:delete-in-div" version="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:option name="divchild" required="true"/>

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

</p:pipeline> It defines an atomic step (“ ex:delete-in-div <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 p:delete both h ex:delete-in-div and html divchild The p:namespaces p:variable p:with-option p:with-param <p:namespaces QName XPathExpression prefix list The namespace bindings specified by a p:namespaces If the binding must in-scope binding static error err:XS0020 binding p:namespaces in-scope binding If the element must p:option p:with-param The expression is evaluated in the appropriate context, See Section 2.6, “XPaths in XProc” dynamic error err:XD0009 element p:namespaces If neither binding element p:namespaces Irrespective of how the set of namespaces are determined, the except-prefixes must must p:namespaces static error err:XS0051 except-prefixes p:namespaces p:namespaces static error err:XS0041 binding element p:namespaces If a p:variable p:with-option p:with-param p:namespaces p:variable p:with-option p:with-param dynamic error err:XD0013 For example, this would allow the preceding example to work: <p:pipeline type="ex:delete-in-div" version="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:option name="divchild" required="true"/>

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

</p:pipeline> The p:namespaces p:delete html: h: Note The use of p:namespaces p:with-option p:namespaces The preceding solution has the weakness that it depends on knowing the bindings that will be used by the caller. A more flexible solution would use the binding <p:pipeline type="ex:delete-in-div" version="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:option name="divchild" required="true"/>

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

</p:pipeline> This example will succeed as long as the caller-specified option does not bind the “ h A p:declare-step signature atomic step <p:declare-step NCName QName boolean string prefix list string p:input p:output p:option p:log p:serialization p:declare-step p:pipeline p:import subpipeline The value of the type static error err:XS0025 type Section 2.13, “Versioning Considerations” must not Irrespective of the context in which the p:declare-step p:declare-step p:option p:variable container implementation-defined A step declaration is not a step p:declare-step p:pipe The version p:declare-step must version Section 2.13, “Versioning Considerations” For a description of psvi-required Section 2.8, “PSVIs in XProc” xpath-version Section 2.6, “XPaths in XProc” exclude-inline-prefixes p:inline When declaring an atomic step, the subpipeline in the declaration must must extension attributes implementation-dependent It is not an error for a pipeline to include declarations 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 p:serialization subpipeline When a p:declare-step subpipeline implementation-defined The environment inherited by the subpipeline empty environment All of the declared inputs are added to the readable ports If a primary input port default readable port If a primary output port connection primary output port last step subpipeline static error err:XS0006 last step The requested xpath-version must Section 2.6, “XPaths in XProc” The psvi-required Section 2.8, “PSVIs in XProc” false A p:library <p:library boolean string prefix list string p:import p:declare-step p:pipeline The version p:library must version Section 2.13, “Versioning Considerations” For a description of psvi-required Section 2.8, “PSVIs in XProc” xpath-version Section 2.6, “XPaths in XProc” exclude-inline-prefixes 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 p:declare-step type p:library Libraries can import pipelines and/or other libraries. See also Appendix G, Handling Circular and Re-entrant Library Imports (Non-Normative) An p:import 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. static error err:XS0052 p:import p:library p:declare-step p:pipeline static error err:XS0053 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 Location: header). In the absence of additional information outside the scope of this specification 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 redirection has occurred. As imports are processed, a processor may encounter new p:import Appendix G, Handling Circular and Re-entrant Library Imports (Non-Normative) A library is considered 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 considered the same imported library. A p:pipe <p:pipe step NCName port NCName The p:pipe step port p:output compound step static error err:XS0022 p:pipe readable ports p:pipe A p:pipe connection p:output compound step contained steps A p:inline <p:inline prefix list anyElement The content of the p:inline p:inline static error err:XS0024 p:inline The in-scope namespaces of the inline document differ from the in-scope namespace of the content of the p:inline excluded namespaces The XProc namespace itself ( http://www.w3.org/ns/xproc A namespace URI designated by using an exclude-inline-prefixes p:inline A namespace URI designated by using an exclude-inline-prefixes p:declare-step p:pipeline p:library exclude-inline-prefixes p:inline The value of each exclude-inline-prefixes The value of the attribute is either #all #default static error err:XS0057 exclude-inline-prefixes #all #default The default namespace of the element on which exclude-inline-prefixes #default static error err:XS0058 #default exclude-inline-prefixes The value #all exclude-inline-prefixes The XProc processor must may Consider this example: <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="1.0"> <p:output port="result"/> <p:serialization 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 declaration for “ c part b some A p:document <p:document href anyURI The document identified by the URI in the href must dynamic error err:XD0011 p:document The parser which the p:document must must may xml:id must not must Namespaces in XML must not Use the p:load Note A p:document reads p:input p:output p:document p:output read as an output Use p:store p:output A p:data <p:data href anyURI QName string string string The resource identified by the URI in the href must The value of the wrapper must QName wrapper-namespace wrapper-prefix dynamic error err:XD0034 wrapper In other words, these two p:data <p:data href="..." xmlns:x="http://example.com/ns/" wrapper="x:wrap"/> <p:data href="..." wrapper="wrap" wrapper-prefix="x" wrapper-namespace="http://example.com/ns/"/> but this p:data <p:data href="..." xmlns:x="http://example.com/ns/" wrapper="x:wrap" wrapper-prefix="x" wrapper-namespace="http://example.com/ns/"/> If no wrapper element is specified, the default is c:data <c:data string string string string dynamic error err:XD0029 p:data Exactly how the data is encoded depends on the media type of the resource. If the resource has a content type associated with it (e.g., if the resource was retrieved with HTTP), then that content type must content-type p:data implementation-dependent If the media type of the response is an XML media type or text type with a charset Unicode TR#17 charset must If the media type is not an appropriate text type, or if the processor does not recognize the media type, the content is base64-encoded. The resulting data is wrapped in an element with the name specified in the wrapper c:data wrapper Implementations should content-type must encoding base64 If an encoding charset content-type charset must If content-type encoding charset c:data must not c:data must http://www.w3.org/ns/xproc-step Implementations may record additional details in extension attributes For example, this p:identity <p:identity name="readcsv"> <p:input port="source"> <p:data href="stateabbr.csv"/> </p:input> </p:identity> might produce output like this: <c:data xmlns:c="http://www.w3.org/2007/03/xproc-step" content-type="text/plain"> AL,Alabama AK,Alaska AZ,Arizona … </c:data> Whereas this pipeline fragment: <p:identity name="readpng"> <p:input port="source"> <p:data href="icon.png" content-type="image/png"/> </p:input> </p:identity>

<p:add-attribute name="makeimg" match="img" attribute-name="src"> <p:input port="source"><p:inline><img/></p:inline></p:input> <p:with-option name="attribute-value" select="concat('data:image/png;base64,',/*/node())"> <p:pipe step="readpng" port="result"/> </p:with-option> </p:add-attribute> produces a single img data: <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/AP+gvaeTAAAACXBI WXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1QsEDycHOWjhgQAAAB10RVh0Q29tbWVudABDcmVhdGVk IHdpdGggVGhlIEdJTVDvZCVuAAABjklEQVQ4y42Tv0tbcRTFz3t5kuQFwUVFEYIGU6q4mU0RlCDR qYO2g4gdghUyKSFDwD/AwS2IoIMSHOLgpOLg4CIOWdy76GBoqQUJLlr66aCW6LuoF+7wvefcc3/w vZLgpbe0wOoqn/Ro5TKRVIpLi6tkkpoFpFJUj48JSVI2y4LnBTm+D1paYqa5OQiGw5DN8nV7m1hv L99f4o4Dk5Mc6Pwcd2yMXauL/n5+FAqsWdXjca5LJbokSXt7fOzu5toSaWsLxpqaIJcjr0ZbXGQh HDaWZPjQEGc7O3jPBC4u8EZHOXkruaODPxsbDMuylRWSra3cviYwO0upMcdtfNRqGq/X5esVu7nR BxMol4knEtTfGsH3+bu8zLdnydUqXjrN/nsWKEEiwdXmJp3/BYpFctFokOi6EIsF444DU1McSZLW 1+nq6eGnVWlkhNrcHBXXNUe5z+f5rEyGA8cxD+pufp7BYtH+yhL09fFbkYjd4vQ0W08jFgp8se7l wY3gwAC/KhXanwROTwlNTHBocf8BTQe7F9dc2bMAAAAASUVORK5CYII="/> Some steps, such as p:xquery p:validate-with-relax-ng should p:data p:xquery A p:empty empty sequence <p:empty /> A p:documentation <p:documentation> any-well-formed-content There are no constraints on the content of the p:documentation Section 3.6, “Documentation” A p:pipeinfo <p:pipeinfo> any-well-formed-content There are no constraints on the content of the p:pipeinfo Section 3.7, “Processor annotations” Errors in a pipeline can be divided into two classes: static errors and dynamic errors. [Definition: A static error Static errors are fatal and must be detected before any steps are evaluated. For a complete list of static errors, see Section E.1, “Static Errors” A [Definition: A dynamic error If a step fails due to a dynamic error, failure propagates upwards until either a p:try p:try For a complete list of dynamic errors, see Section E.2, “Dynamic Errors” Several of the steps in the standard and option step library can generate dynamic errors. For a complete list of the dynamic errors raised by builtin pipeline steps, see Section E.3, “Step Errors” This section describes the standard XProc steps. A machine-readable description of these steps may be found in xproc-1.0.xpl When a step in this library produces an output document, the base URI of the output is the base URI of the step's primary input document unless the step's process explicitly sets an xml:base Also, in this section, several steps use this element for result information: <c:result> string When a step uses an XPath to compute an option value, the XPath context is as defined in Section 2.6, “XPaths in XProc” When a step specifies a particular version of a technology, implementations must This section describes standard steps that must be supported by any conforming processor. The p:add-attribute source match attribute-name attribute-value The resulting document is produced on the result <p:declare-step type =" p:add-attribute " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" attribute-name " required =" true " /> <!-- QName --> <p:option name =" attribute-prefix " /> <!-- NCName --> <p:option name =" attribute-namespace " /> <!-- anyURI --> <p:option name =" attribute-value " required =" true " /> <!-- string --> </p:declare-step> The value of the match must dynamic error err:XC0023 The value of the attribute-name must QName attribute-namespace attribute-prefix dynamic error err:XD0034 The value of the attribute-value must If an attribute with the same name as the expanded name from the attribute-name attribute-value attribute-value Note If multiple attributes need to be set on the same element(s), the p:set-attributes This step cannot be used to add namespace declarations. dynamic error err:XC0059 attribute-name xmlns http://www.w3.org/2000/xmlns/ Section 2.4.1, “Namespace Fixup on Outputs” If an attribute named xml:base must The p:add-xml-base xml:base source result xml:base <p:declare-step type =" p:add-xml-base " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" all " select =" 'false' " /> <!-- boolean --> <p:option name =" relative " select =" 'true' " /> <!-- boolean --> </p:declare-step> The value of the all must The value of the relative must dynamic error err:XC0058 all relative both true The p:add-xml-base For the document element: force the element to have an xml:base For other elements: If the all true xml:base If the element's [base URI] is different from the its parent's [base URI], force the element to have an xml:base relative true Otherwise, if there is an xml:base The p:compare <p:declare-step type =" p:compare " > <p:input port =" source " primary =" true " /> <p:input port =" alternate " /> <p:output port =" result " primary =" false " /> <p:option name =" fail-if-not-equal " select =" 'false' " /> <!-- boolean --> </p:declare-step> The value of the fail-if-not-equal must This step takes single documents on each of two ports and compares them using the fn:deep-equal XPath 2.0 Functions and Operators dynamic error err:XC0019 fail-if-not-equal true fail-if-not-equal false c:result true false The p:count source result c:result <p:declare-step type =" p:count " > <p:input port =" source " sequence =" true " /> <p:output port =" result " /> <p:option name =" limit " select =" 0 " /> <!-- integer --> </p:declare-step> If the limit p:count The p:delete source result <p:declare-step type =" p:delete " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> The value of the match must If an element is selected by the match This step cannot be used to remove namespaces. dynamic error err:XC0062 match xml:base The p:directory-list <p:declare-step type =" p:directory-list " > <p:output port =" result " /> <p:option name =" path " required =" true " /> <!-- anyURI --> <p:option name =" include-filter " /> <!-- RegularExpression --> <p:option name =" exclude-filter " /> <!-- RegularExpression --> </p:declare-step> The value of the path must anyURI p:with-option p:directory-list syntactic shortcut dynamic error err:XC0017 dynamic error err:XC0012 must file implementation-defined p:directory-list If present, the value of the include-filter exclude-filter must XPath 2.0 Functions and Operators Regular Expression Syntax If the include-filter exclude-filter The result document produced for the specified directory path has a c:directory name <c:directory name string c:file c:directory c:other Its contents are determined as follows, based on the entries in the directory identified by the directory path. For each entry in the directory, if either no filter c:file c:directory c:other A c:directory A c:file <c:file name string p:directory-list c:other implementation-defined <c:other name string When a directory entry is a subdirectory, that directory's entries are not output as part of that entry's c:directory Each of the elements c:file c:directory c:other name c:directory name c:file c:directory c:other implementation-defined The p:error dynamic error <p:declare-step type =" p:error " > <p:input port =" source " primary =" false " /> <p:output port =" result " sequence =" true " /> <p:option name =" code " required =" true " /> <!-- QName --> <p:option name =" code-prefix " /> <!-- NCName --> <p:option name =" code-namespace " /> <!-- anyURI --> </p:declare-step> The value of the code must QName code-namespace code-prefix dynamic error err:XD0034 This step uses the document provided on its input as the content of the error raised. An instance of the c:errors dynamic errors p:try For authoring convenience, the p:error connections For example, given the following invocation: <p:error xmlns:my="http://www.example.org/error" name="bad-document" code="my:unk12"> <p:input port="source"> <p:inline> <message>The document element is unknown.</message> </p:inline> </p:input> </p:error> The error vocabulary element (and document) generated on the error output port would be: <c:errors xmlns:c="http://www.w3.org/ns/xproc-step" xmlns:p="http://www.w3.org/ns/xproc" xmlns:my="http://www.example.org/error"> <c:error name="bad-document" type="p:error" code="my:unk12"><message>The document element is unknown.</message> </c:error> </c:errors> The href line column offset c:error p:error The p:escape-markup <p:declare-step type =" p:escape-markup " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> This step supports the standard serialization options as specified in Section 7.3, “Serialization Options” For example, the input: <description> <div xmlns="http://www.w3.org/1999/xhtml"> <p>This is a chunk of XHTML.</p> </div> </description> produces: <description> &lt;div xmlns="http://www.w3.org/1999/xhtml"&gt; &lt;p>This is a chunk of XHTML.&lt;/p&gt; &lt;/div&gt; </description> Note The result of this step is an XML document that contains the Unicode characters that are the characters that result from escaping the input. It is not encoded characters in a serialized octet stream, therefore, the serialization options related to encoding characters ( byte-order-mark encoding normalization-form By default, this step must not The p:filter <p:declare-step type =" p:filter " > <p:input port =" source " /> <p:output port =" result " sequence =" true " /> <p:option name =" select " required =" true " /> <!-- XPathExpression --> </p:declare-step> This step behaves just like an p:input select The p:http-request source c:request <p:declare-step type =" p:http-request " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" byte-order-mark " /> <!-- boolean --> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" encoding " /> <!-- string --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" normalization-form " select =" 'none' " /> <!-- NormalizationForm --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> The standard serialization options are provided to control the serialization of any XML content which is sent as part of the request. The effect of these options is as specified in Section 7.3, “Serialization Options” Section 7.1.10.2, “Request Entity body conversion” dynamic error err:XC0040 source c:request An HTTP request is represented by a c:request <c:request method NCName anyURI boolean boolean string string string boolean string c:header c:multipart c:body dynamic error err:XC0006 method c:request dynamic error err:XC0005 c:body c:multipart method dynamic error err:XC0004 status-only true detailed true The method href GET POST href Note In the case of simple “GET” requests, implementors are encouraged to support as many protocols as practical. In particular, pipeline authors may attempt to use p:http-request file: If the username username password auth-method send-authorization For the purposes of avoiding an authentication challenge, if the send-authorization true auth-method Authorization Authorization send-authorization false Authorization If the initial response to the request is an authentication challenge, the auth-method username password Authorization Appropriate values for the auth-method RFC 2617 auth-method c:request implementation-defined dynamic error err:XC0003 username password auth-method auth-method RFC 2617 The c:header <c:header name string value string The request is formulated from the attribute values on the c:request c:header c:multipart c:body href Section 7.1.10.4, “Converting Response Entity Bodies” When the request is formulated, the step and/or protocol implementation may add headers as necessary to either complete the request or as appropriate for the content specified (e.g. transfer encodings). A user of this step is guaranteed that their requested headers and content will be sent with the exception of any conflicts with protocol-related headers. The p:http-request c:header Content-Type dynamic error err:XC0020 The c:multipart RFC 1521 <c:multipart content-type string boundary string c:body In the context of a request, the media type of the c:multipart must content-type The boundary -- dynamic error err:XC0002 -- If the boundary is also specified as a parameter in the content-type boundary must boundary content-type must The c:body <c:body content-type string string string string string anyElement The content-type Content-Type The encoding base64 base64 implementation-defined dynamic error err:XC0052 Note The p:http-request For each body or body part, the id Content-ID description Content-Description disposition Content-Disposition If an entity body is to be sent as part of a request (e.g. a POST c:body c:multipart c:multipart c:body c:body If the content-type encoding base64 dynamic error err:XC0028 c:body Otherwise (the content-type does encoding not dynamic error err:XC0022 c:body p:http-request For example, the following input to a p:http-request <c:request method="POST" href="http://example.com/someservice"> <c:body xmlns:c="http://www.w3.org/ns/xproc-step" content-type="application/xml"> <doc> <title>My document</title> </doc> </c:body> </c:request> The corresponding request should look something like this: POST http://example.com/someservice HTTP/1.1 Host: example.com Content-Type: application/xml; charset="utf-8"

<?xml version='1.0'?> <doc> <title>My document</title> </doc> The handling of the response to the request and the generation of the step's result document is controlled by the status-only override-content-type detailed c:request The override-content-type Content-Type Content-Type Content-Type c:header dynamic error err:XC0030 override-content-type text/plain image/png If the status-only true c:body c:multipart The c:response status c:header c:multipart c:body <c:response integer c:header c:multipart c:body The value of the detailed true A single c:response status Each response header is translated into a c:header Unless the status-only true c:body c:multipart Section 7.1.10.4, “Converting Response Entity Bodies” Otherwise (the detailed false If the media type (as determined by the override-content-type Content-Type result Otherwise, the entity body of the response is converted into a c:body c:multipart Section 7.1.10.4, “Converting Response Entity Bodies” In either case the base URI of the output document is the resolved value of the href c:request One possible response from an HTTP request is a redirect, indicated by a status code in the three-hundred range. The precise semantics of the 3xx return codes are laid out by section 10.3 Redirection 3xx RFC 2616 The p:http-request should RFC 2616 With one exception, in version 1.0 of XProc, the p:http-request p:http-request implementation-defined The exception arises in the case of redirection. If a redirect response includes cookies, those cookies should This behavior will allow the p:http-request The entity of a response may be multipart per [ RFC 1521 c:multipart c:body Note Although it is technically possible for any of the individual parts of a multipart message to also implementation-dependent The result of the p:http-request base64 c:body encoding c:body base64 If the media type of the response is a text type with a charset Unicode TR#17 c:body If the response is an XML media type, the content of the constructed c:body In a c:body content-type must Content-Type In the case of a multipart response, the same rules apply when constructing a c:body Note Given the above description, any content identified as text/html c:body p:unescape-markup A simple form might be posted as follows: <c:request method="POST" href="http://www.example.com/form-action" xmlns:c="http://www.w3.org/ns/xproc-step"> <c:body content-type="application/x-www-form-urlencoded"> name=W3C&amp;spec=XProc </c:body> </c:request> and if the response was an XHTML document, the result document would be: <c:response status="200" xmlns:c="http://www.w3.org/ns/xproc-step"> <c:header name="Date" value=" Wed, 09 May 2007 23:12:24 GMT"/> <c:header name="Server" value="Apache/1.3.37 (Unix) PHP/4.4.5"/> <c:header name="Vary" value="negotiate,accept"/> <c:header name="TCN" value="choice"/> <c:header name="P3P" value="policyref='http://www.w3.org/2001/05/P3P/p3p.xml'"/> <c:header name="Cache-Control" value="max-age=600"/> <c:header name="Expires" value="Wed, 09 May 2007 23:22:24 GMT"/> <c:header name="Last-Modified" value="Tue, 08 May 2007 16:10:49 GMT"/> <c:header name="ETag" value="'4640a109;42380ddc'"/> <c:header name="Accept-Ranges" value="bytes"/> <c:header name="Keep-Alive" value="timeout=2, max=100"/> <c:header name="Connection" value="Keep-Alive"/> <c:body content-type="application/xhtml+xml"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><title>OK</title></head> <body><p>OK!</p></body> </html> </c:body> </c:response> The p:identity <p:declare-step type =" p:identity " > <p:input port =" source " sequence =" true " /> <p:output port =" result " sequence =" true " /> </p:declare-step> If the implementation supports passing PSVI annotations between steps, the p:identity must The p:insert insertion source source <p:declare-step type =" p:insert " > <p:input port =" source " primary =" true " /> <p:input port =" insertion " sequence =" true " /> <p:output port =" result " /> <p:option name =" match " select =" '/*' " /> <!-- XSLTMatchPattern --> <p:option name =" position " required =" true " /> <!-- "first-child" | "last-child" | "before" | "after" --> </p:declare-step> The value of the match must dynamic error err:XC0023 insertion The value of the position must “ first-child “ last-child “ before “ after dynamic error err:XC0025 position first-child last-child As the inserted elements are part of the output of the step they are not considered in determining matching elements. If an empty sequence appears on the insertion The p:label-elements <p:declare-step type =" p:label-elements " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" attribute " select =" 'xml:id' " /> <!-- QName --> <p:option name =" attribute-prefix " /> <!-- NCName --> <p:option name =" attribute-namespace " /> <!-- anyURI --> <p:option name =" label " select =" 'concat("_",$p:index)' " /> <!-- XPathExpression --> <p:option name =" match " select =" '*' " /> <!-- XSLTMatchPattern --> <p:option name =" replace " select =" 'true' " /> <!-- boolean --> </p:declare-step> The value of the attribute must QName attribute-namespace attribute-prefix dynamic error err:XD0034 The value of the label The value of the match must dynamic error err:XC0023 The value of the replace must This step operates by generating attribute labels for each element matched. For every matched element, the expression is evaluated with the context node set to the matched element. An attribute is added to the matched element using the attribute name is specified the attribute replace true If this step is used to add or change the value of an attribute named “ xml:base must An implementation must bind the variable “ p:index 1 2 3 The result of the p:label-elements step is the input document with the attribute labels associated with matched elements. All other non-matching content remains the same. The p:load <p:declare-step type =" p:load " > <p:output port =" result " /> <p:option name =" href " required =" true " /> <!-- anyURI --> <p:option name =" dtd-validate " select =" 'false' " /> <!-- boolean --> </p:declare-step> The value of the href must anyURI p:with-option p:load syntactic shortcut The value of the dtd-validate must The p:load p:document The URI to be accessed can be constructed dynamically by the pipeline. The p:load When dtd-validate false p:load p:document href When dtd-validate true p:load p:document href must dynamic error err:XC0027 The retrieved document is produced on the result The p:make-absolute-uris <p:declare-step type =" p:make-absolute-uris " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" base-uri " /> <!-- anyURI --> </p:declare-step> The value of the match must dynamic error err:XC0023 The value of the base-uri must anyURI p:with-option p:make-absolute-uris syntactic shortcut For every element or attribute in the input document which matches the specified pattern, its XPath string-value is resolved against the specified base URI and the resulting absolute IRI is used as the matched node's entire contents in the output. The base URI used for resolution defaults to the matched attribute's element or the matched element's base URI unless the base-uri base-uri p:option base-uri p:make-absolute-uris implementation-dependent The p:namespace-rename <p:declare-step type =" p:namespace-rename " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" from " /> <!-- anyURI --> <p:option name =" to " /> <!-- anyURI --> <p:option name =" apply-to " select =" 'all' " /> <!-- "all" | "elements" | "attributes" --> </p:declare-step> The value of the from must anyURI should The value of the to must anyURI should The value of the apply-to must all elements attributes elements attributes all dynamic error err:XC0014 http://www.w3.org/XML/1998/namespace http://www.w3.org/2000/xmlns/ from to If the value of the from to Namespace bindings: If the from from replaced in the output with a binding to the value of the to otherwise (the to If the from Elements and attributes: If the from from replaced with the value of the to otherwise (the to If the from to Namespace attributes: If the from from the namespace attribute's value is replaced with the value of the to otherwise (the to Note The apply-to from Care should be taken when specifying no namespace with the to The p:pack <p:declare-step type =" p:pack " > <p:input port =" source " sequence =" true " primary =" true " /> <p:input port =" alternate " sequence =" true " /> <p:output port =" result " sequence =" true " /> <p:option name =" wrapper " required =" true " /> <!-- QName --> <p:option name =" wrapper-prefix " /> <!-- NCName --> <p:option name =" wrapper-namespace " /> <!-- anyURI --> </p:declare-step> The value of the wrapper must QName wrapper-namespace wrapper-prefix dynamic error err:XD0034 The step takes each pair of documents, in order, one from the source alternate wrapper result If the step reaches the end of one input sequence before the other, then it simply wraps each of the remaining documents in the longer sequence. Note In the common case, where the document element of a document in the result The p:parameters c:param-set <p:declare-step type =" p:parameters " > <p:input port =" parameters " kind =" parameter " primary =" false " /> <p:output port =" result " primary =" false " /> </p:declare-step> Each parameter passed to the step is converted into a c:param Section 5.1.2, “Parameter Inputs” c:param c:param-set result c:param c:param-set implementation-dependent For consistency and user convenience, if any of the parameters have names that are in a namespace, the namespace c:param must name must The base URI of the output document is the URI of the pipeline document that contains the step. Note Since the parameters not p:with-param must port Section 5.7.4, “p:with-param” The p:rename <p:declare-step type =" p:rename " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" new-name " required =" true " /> <!-- QName --> <p:option name =" new-prefix " /> <!-- NCName --> <p:option name =" new-namespace " /> <!-- anyURI --> </p:declare-step> The value of the match dynamic error err:XC0023 The value of the new-name QName new-namespace new-prefix dynamic error err:XD0034 Each element, attribute, or processing-instruction in the input matched by the match pattern specified in the match new-name If the match new-name new-name With respect to attributes named “ xml:base from xml:base to from to xml:base must If the pattern matches processing instructions, then it is the processing instruction target that is renamed. dynamic error err:XC0013 The p:replace replacement <p:declare-step type =" p:replace " > <p:input port =" source " primary =" true " /> <p:input port =" replacement " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> The value of the match must dynamic error err:XC0023 replacement Every node in the primary input matching the specified pattern is replaced in the output is replaced by the document element of the replacement The p:set-attributes <p:declare-step type =" p:set-attributes " > <p:input port =" source " primary =" true " /> <p:input port =" attributes " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> The value of the match must dynamic error err:XC0023 Each attribute on the document element of the document that appears on the attributes match If an attribute with the same name as one of the attributes to be copied already exists, the value specified on the attribute source The matching elements are specified by the match pattern in the match This step must not copy namespace declarations. If the attributes copied from the attributes result namespace fixup If an attribute named xml:base must The p:sink <p:declare-step type =" p:sink " > <p:input port =" source " sequence =" true " /> </p:declare-step> The p:split-sequence <p:declare-step type =" p:split-sequence " > <p:input port =" source " sequence =" true " /> <p:output port =" matched " sequence =" true " primary =" true " /> <p:output port =" not-matched " sequence =" true " /> <p:option name =" initial-only " select =" 'false' " /> <!-- boolean --> <p:option name =" test " required =" true " /> <!-- XPathExpression --> </p:declare-step> The value of the test must The XPath expression in the test matched not-matched If the initial-only and all the documents that follow it not-matched matched not-matched The XPath context test source position() last() Note In principle, this component cannot stream because it must buffer all of the input sequence in order to find the context size. In practice, if the test expression does not use the last() If the implementation supports passing PSVI annotations between steps, the p:split-sequence must The p:store <p:declare-step type =" p:store " > <p:input port =" source " /> <p:output port =" result " primary =" false " /> <p:option name =" href " required =" true " /> <!-- anyURI --> <p:option name =" byte-order-mark " /> <!-- boolean --> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" encoding " /> <!-- string --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" normalization-form " select =" 'none' " /> <!-- NormalizationForm --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> The value of the href must anyURI p:with-option p:store syntactic shortcut The step attempts to store the XML document to the specified URI. dynamic error err:XC0050 The output of this step is a document containing a single c:result The standard serialization options are provided to control the serialization of the XML content when it is stored. These options are as specified in Section 7.3, “Serialization Options” The p:string-replace source <p:declare-step type =" p:string-replace " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" replace " required =" true " /> <!-- XPathExpression --> </p:declare-step> The value of the match must The value of the replace must The matched nodes are specified with the match pattern in the match replace If the expression given in the match attribute replace xml:base must If the expression matches any other kind of node, the entire node (and not replace The p:unescape-markup p:escape-markup <p:declare-step type =" p:unescape-markup " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" namespace " /> <!-- anyURI --> <p:option name =" content-type " select =" 'application/xml' " /> <!-- string --> <p:option name =" encoding " /> <!-- string --> <p:option name =" charset " /> <!-- string --> </p:declare-step> The value of the namespace must anyURI should When the string value is parsed, the original document element is preserved so that the result will be well-formed XML even if the content consists of multiple, sibling elements. The namespace The content-type may may HTML Tidy TagSoup text/html All implementations must application/xml dynamic error err:XC0051 p:unescape-markup content-type application/xml implementation-defined The encoding must base64 dynamic error err:XC0052 If an encoding charset content-type charset charset must If the specified encoding base64 must dynamic error err:XC0010 base64 The octet-stream that results from decoding the text must charset If no encoding For example, with the 'namespace' option set to the XHTML namespace, the following input: <description> &lt;p>This is a chunk.&lt;/p> &lt;p>This is a another chunk.&lt;/p> </description> would produce: <description> <p xmlns="http://www.w3.org/1999/xhtml">This is a chunk.</p> <p xmlns="http://www.w3.org/1999/xhtml">This is a another chunk.</p> </description> The p:unwrap <p:declare-step type =" p:unwrap " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> The value of the match must dynamic error err:XC0023 Every element in the source match Note The matching applies to the entire document, not just the “top-most” matches. A pattern of the form h:div all h:div This step produces a single document; if the document element is unwrapped, the result might not be well-formed XML. The p:wrap source <p:declare-step type =" p:wrap " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" wrapper " required =" true " /> <!-- QName --> <p:option name =" wrapper-prefix " /> <!-- NCName --> <p:option name =" wrapper-namespace " /> <!-- anyURI --> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" group-adjacent " /> <!-- XPathExpression --> </p:declare-step> The value of the wrapper must QName wrapper-namespace wrapper-prefix dynamic error err:XD0034 The value of the match must dynamic error err:XC0023 The value of the group-adjacent must If the node matched is the document node ( match="/" wrapper When the match pattern does not match the document node, every node that matches the specified match wrapper p:wrap The group-adjacent Two matching nodes are considered adjacent if and only if they are siblings and either there are no nodes between them or all intervening, non-matching nodes are whitespace text, comment, or processing instruction nodes. The p:wrap-sequence <p:declare-step type =" p:wrap-sequence " > <p:input port =" source " sequence =" true " /> <p:output port =" result " sequence =" true " /> <p:option name =" wrapper " required =" true " /> <!-- QName --> <p:option name =" wrapper-prefix " /> <!-- NCName --> <p:option name =" wrapper-namespace " /> <!-- anyURI --> <p:option name =" group-adjacent " /> <!-- XPathExpression --> </p:declare-step> The value of the wrapper must QName wrapper-namespace wrapper-prefix dynamic error err:XD0034 The value of the group-adjacent must In its simplest form, p:wrap-sequence source wrapper The group-adjacent XPath context group-adjacent source position() last() The p:xinclude XInclude source <p:declare-step type =" p:xinclude " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" fixup-xml-base " select =" 'false' " /> <!-- boolean --> <p:option name =" fixup-xml-lang " select =" 'false' " /> <!-- boolean --> </p:declare-step> The value of the fixup-xml-base must XInclude The value of the fixup-xml-lang must XInclude The included documents are located with the base URI of the input document and are not provided as input to the step. dynamic error err:XC0029 The p:xslt XSLT 1.0 XSLT 2.0 <p:declare-step type =" p:xslt " > <p:input port =" source " sequence =" true " primary =" true " /> <p:input port =" stylesheet " /> <p:input port =" parameters " kind =" parameter " /> <p:output port =" result " primary =" true " /> <p:output port =" secondary " sequence =" true " /> <p:option name =" initial-mode " /> <!-- QName --> <p:option name =" template-name " /> <!-- QName --> <p:option name =" output-base-uri " /> <!-- anyURI --> <p:option name =" version " /> <!-- string --> </p:declare-step> If present, the value of the initial-mode must QName If present, the value of the template-name must QName If present, the value of the output-base-uri must anyURI p:with-option p:xslt syntactic shortcut If the step specifies a version must dynamic error err:XC0038 The XSLT stylesheet provided on the stylesheet source parameters result secondary must secondary If a sequence of documents is provided on the source source dynamic error err:XC0039 A dynamic error occurs if the XSLT processor signals a fatal error. This includes the case where the transformation terminates due to a xsl:message terminate yes implementation-dependent The invocation of the transformation is controlled by the initial-mode template-name dynamic error err:XC0056 The output-base-uri result source output-base-uri p:option should output-base-uri If XSLT 2.0 is used, the outputs of this step may The static and initial dynamic contexts of the XSLT processor are the contexts defined in Section 2.6.1.2, “Step XPath Context” Section 2.6.2.2, “Step XPath Context” The dynamic context is augmented as follows: Context item The first document that appears on the source Variable values Any parameters passed on the parameters Function implementations The function implementations provided by the XSLT processor. Default collection The sequence of documents provided on the source The following steps are optional. If they are supported by a processor, they must conform to the semantics outlined here, but a conformant processor is not required to support all (or any) of these steps. The p:exec source result errors <p:declare-step type =" p:exec " > <p:input port =" source " primary =" true " sequence =" true " /> <p:output port =" result " primary =" true " /> <p:output port =" errors " /> <p:output port =" exit-status " /> <p:option name =" command " required =" true " /> <!-- string --> <p:option name =" args " select =" '' " /> <!-- string --> <p:option name =" cwd " /> <!-- string --> <p:option name =" source-is-xml " select =" 'true' " /> <!-- boolean --> <p:option name =" result-is-xml " select =" 'true' " /> <!-- boolean --> <p:option name =" wrap-result-lines " select =" 'false' " /> <!-- boolean --> <p:option name =" errors-is-xml " select =" 'false' " /> <!-- boolean --> <p:option name =" wrap-error-lines " select =" 'false' " /> <!-- boolean --> <p:option name =" path-separator " /> <!-- string --> <p:option name =" failure-threshold " /> <!-- integer --> <p:option name =" arg-separator " select =" ' ' " /> <!-- string --> <p:option name =" byte-order-mark " /> <!-- boolean --> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" encoding " /> <!-- string --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" normalization-form " select =" 'none' " /> <!-- NormalizationForm --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> The values of the command args cwd path-separator arg-separator must The values of the source-is-xml result-is-xml errors-is-xml fix-slashes must The p:exec command args command args dynamic error err:XC0033 If cwd dynamic error err:XC0034 cwd cwd implementation-defined If the path-separator path-separator command args cwd dynamic error err:XC0063 path-separator The value of the args args arg-separator dynamic error err:XC0066 arg-separator The following examples of p:exec arg-separator <p:exec command="someCommand" args="arg1 arg2 arg3"/> The second specifies an alternate separator: <p:exec command="someCommand" args="arg1,arg2,arg3" arg-separator=","/> If one of the arguments contains a space (e.g., a filename that contains a space), then you must specify an alternate separator. The source source source dynamic error err:XD0006 source p:exec source-is-xml The standard output of the command is read and returned on result errors c:result If result-is-xml not If wrap-result-lines c:line <c:line> string dynamic error err:XC0035 result-is-xml wrap-result-lines The same rules apply to the standard error output of the program, with the errors-is-xml wrap-error-lines If either of the results are XML, they must p:document The exit-status c:result p:exec implementation-dependent If a failure-threshold p:exec must dynamic error err:XC0064 failure-threshold p:try The p:hash source <p:declare-step type =" p:hash " > <p:input port =" source " primary =" true " /> <p:output port =" result " /> <p:input port =" parameters " kind =" parameter " /> <p:option name =" value " required =" true " /> <!-- string --> <p:option name =" algorithm " required =" true " /> <!-- QName --> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" version " /> <!-- string --> </p:declare-step> The value of the algorithm If a version crc md sha A hash is constructed from the string specified in the value must CRC32 MD5 SHA1 implementation-defined should The value of the match The hash of the specified value is computed using the algorithm and parameters specified. dynamic error err:XC0036 The matched nodes are specified with the match pattern in the match same If the expression given in the match attribute xml:base must If the expression matches any other kind of node, the entire node (and not The p:uuid UUID source <p:declare-step type =" p:uuid " > <p:input port =" source " primary =" true " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" version " /> <!-- integer --> </p:declare-step> The value of the match version If the version dynamic error err:XC0060 version version implementation-defined Implementations must implementation-defined The matched nodes are specified with the match pattern in the match same If the expression given in the match attribute xml:base must If the expression matches any other kind of node, the entire node (and not The p:validate-with-relax-ng RELAX NG source <p:declare-step type =" p:validate-with-relax-ng " > <p:input port =" source " primary =" true " /> <p:input port =" schema " /> <p:output port =" result " /> <p:option name =" dtd-attribute-values " select =" 'false' " /> <!-- boolean --> <p:option name =" dtd-id-idref-warnings " select =" 'false' " /> <!-- boolean --> <p:option name =" assert-valid " select =" 'true' " /> <!-- boolean --> </p:declare-step> The values of the dtd-attribute-values dtd-id-idref-warnings must If the root element of the schema is c:data c:content-type should RELAX NG Compact Syntax If the dtd-attribute-values true RELAX NG DTD Compatibility If the dtd-id-idref-warnings true should RELAX NG DTD Compatibility dynamic error err:XC0053 assert-valid true The output from this step is a copy of the input, possibly augmented by application of the [ RELAX NG DTD Compatibility may RELAX NG DTD Compatibility implementation defined The p:validate-with-schematron Schematron source <p:declare-step type =" p:validate-with-schematron " > <p:input port =" parameters " kind =" parameter " /> <p:input port =" source " primary =" true " /> <p:input port =" schema " /> <p:output port =" result " primary =" true " /> <p:output port =" report " sequence =" true " /> <p:option name =" phase " select =" '#ALL' " /> <!-- string --> <p:option name =" assert-valid " select =" 'true' " /> <!-- boolean --> </p:declare-step> dynamic error err:XC0054 assert-valid true The value of the phase The parameters The result Schematron assertions and reports, if any, must report should Schematron Validation Report Language The output of this step may The p:validate-with-xml-schema W3C XML Schema: Part 1 source <p:declare-step type =" p:validate-with-xml-schema " > <p:input port =" source " primary =" true " /> <p:input port =" schema " sequence =" true " /> <p:output port =" result " /> <p:option name =" use-location-hints " select =" 'false' " /> <!-- boolean --> <p:option name =" try-namespaces " select =" 'false' " /> <!-- boolean --> <p:option name =" assert-valid " select =" 'true' " /> <!-- boolean --> <p:option name =" mode " select =" 'strict' " /> <!-- "strict" | "lax" --> </p:declare-step> The values of the use-location-hints try-namespaces assert-valid must The value of the mode must strict lax Validation is performed against the set of schemas represented by the documents on the schema xs:import xsi:schema-location If xs:include external documents implementation-defined schemas xs:include The use-location-hints try-namespaces schema schema must If the use-location-hints true should false should If the try-namespaces true should false should not The mode strict lax dynamic error err:XC0053 assert-valid true assert-valid false p:validate-with-xml-schema does When XML Schema validation assessment is performed, the processor is invoked in the mode specified by the mode dynamic error err:XC0055 The result W3C XML Schema: Part 1 The p:www-form-urldecode x-www-form-urlencoded <p:declare-step type =" p:www-form-urldecode " > <p:output port =" result " /> <p:option name =" value " required =" true " /> <!-- string --> </p:declare-step> The value x-www-form-urlencoded c:param-set result dynamic error err:XC0037 value x-www-form-urlencoded dynamic error err:XC0061 xs:NCName The order of the c:param If any parameter name occurs more than once in the encoded string, the resulting parameter set will contain a c:param parameter input port The p:www-form-urlencode x-www-form-urlencoded source <p:declare-step type =" p:www-form-urlencode " > <p:input port =" source " primary =" true " /> <p:output port =" result " /> <p:input port =" parameters " kind =" parameter " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> The value of the match The set of parameters is encoded as a single x-www-form-urlencoded only The parameters are encoded in document order. That is, the first parameter appears first in the resulting string, the second parameter second, etc. reading from left to right. The matched nodes are specified with the match pattern in the match If the expression given in the match attribute not The p:xquery XQuery 1.0 source <p:declare-step type =" p:xquery " > <p:input port =" source " sequence =" true " primary =" true " /> <p:input port =" query " /> <p:input port =" parameters " kind =" parameter " /> <p:output port =" result " sequence =" true " /> </p:declare-step> If a sequence of documents is provided on the source source The query If the document root element is c:query <c:query> string If the document root element is in the XQueryX namespace, the document is treated as an XQueryX-encoded query. implementation-defined If the document root element is c:data content-type content-type If the document root element is not c:data c:content-type implementation-defined The result of the p:xquery dynamic error err:XC0057 For example: <c:query> declare namespace atom="http://www.w3.org/2005/Atom"; /atom:feed/atom:entry </c:query> The output of this step may The static context of the XQuery processor is augmented in the following way: Statically known default collection type document()* Statically known namespaces: Unchanged from the implementation defaults. No namespace declarations in the XProc pipeline are automatically exposed in the static context. The dynamic context of the XQuery processor is augmented in the following way: Context item The first document that appears on the source Context position 1 Context size 1 Variable values Any parameters passed on the parameters xs:untypedAtomic Function implementations The function implementations provided by the XQuery processor. Current dateTime implementation-defined Implicit timezone implementation-defined Available documents implementation-dependent Available collections implementation-dependent Default collection The sequence of documents provided on the source The following pipeline applies XInclude processing and schema validation before using XQuery: Example 11. A Sample Pipeline Document <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0">

<p:xinclude/>

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

<p:xquery> <p:input port="query"> <p:data href="countp.xq" /> </p:input> </p:xquery>

</p:pipeline> Where countp.xq <count>{count(.//p)}</count> The p:xsl-formatter XSL 1.1 href <p:declare-step type =" p:xsl-formatter " > <p:input port =" source " /> <p:input port =" parameters " kind =" parameter " /> <p:output port =" result " primary =" false " /> <p:option name =" href " required =" true " /> <!-- anyURI --> <p:option name =" content-type " /> <!-- string --> </p:declare-step> The value of the href must anyURI p:with-option p:xsl-formatter syntactic shortcut The content-type of the output is controlled by the content-type IANA Media Types content-type implementation-defined content-type implementation-defined should implementation-defined The output of this step is a document containing a single c:result Several steps in this step library require serialization options to control the serialization of XML. These options are used to control serialization as in the [ Serialization The following options may be present on steps that perform serialization: byte-order-mark The value of this option must cdata-section-elements The value of this option must QName doctype-public The value of this option must doctype-system The value of this option must anyURI encoding A character set name. encoding implementation defined method xml xhtml must escape-uri-attributes The value of this option must xhtml html include-content-type The value of this option must xhtml html indent The value of this option must media-type The value of this option must method xml application/xml html text/html xhtml application/xhtml+xml text text/plain xml html xhtml text media-type implementation defined method The value of this option must QName normalization-form The value of this option must NFC NFD NFKC NFKD fully-normalized none omit-xml-declaration The value of this option must standalone The value of this option must true false omit undeclare-prefixes The value of this option must version The value of this option must In order to be consistent with the rest of this specification, boolean values for the serialization parameters must use one of the XML Schema lexical forms for boolean: "true", "false", "1", or "0". This is different from the [ Serialization The method Serialization implementation-defined A minimally conforming implementation must support the xml The version 1.0 The encoding UTF-8 The omit-xml-declaration no All other option values may be ignored for the xml If a processor chooses to implement an option for serialization, it must conform to the semantics defined in the [ Serialization Note The use-character-maps parameter in [ Serialization Conformant processors must Some aspects of processor behavior are not completely specified; those features are either implementation-dependent implementation-defined [Definition: An implementation-dependent implementation-dependent [Definition: An implementation-defined must implementation-defined The following features are implementation-defined: It is implementation-defined what additional step types, if any, are provided. See Section 2.1, “Steps” How inputs are connected to XML documents outside the pipeline is implementation-defined. See Section 2.2, “Inputs and Outputs” How pipeline outputs are connected to XML documents outside the pipeline is implementation-defined. See Section 2.2, “Inputs and Outputs” In Version 1.0 of XProc, how (or if) implementers provide local resolution mechanisms and how (or if) they provide access to intermediate results by URI is implementation-defined. See Section 2.2.1, “External Documents” 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 on intermediate outputs is implementation-defined. See Section 2.4.1, “Namespace Fixup on Outputs” If no version is specified on the step or among its ancestors, then its XPath version is implementation-defined. See Section 2.6, “XPaths in XProc” The version of Unicode supported is implementation-defined, but it is recommended that the most recent version of Unicode be used. See Section 2.6.2.1, “Processor XPath Context” The point in time returned as the current dateTime is implementation-defined. See Section 2.6.2.1, “Processor XPath Context” The implicit timezone is implementation-defined. See Section 2.6.2.1, “Processor XPath Context” The implicit timezone is implementation-defined. See Section 2.6.2.2, “Step XPath Context” The exact format of the language string is implementation-defined but should be consistent with the xml:lang attribute. See Section 2.7.1, “System Properties” It is implementation-defined if the processor supports any other XPath extension functions. See Section 2.7.10, “Other XPath Extension Functions” Whether or not the pipeline processor supports passing PSVI annotations between steps is implementation-defined. See Section 2.8, “PSVIs in XProc” The exact PSVI properties that are preserved when documents are passed between steps is implementation-defined. See Section 2.8, “PSVIs in XProc” It is implementation-defined what PSVI properties, if any, are produced by extension steps. See Section 2.8, “PSVIs in XProc” How outside values are specified for pipeline options on the pipeline initially invoked by the processor is implementation-defined. See Section 2.10, “Options” How outside values are specified for pipeline parameters on the pipeline initially invoked by the processor is implementation-defined. See Section 2.11, “Parameters” Support for pipeline documents written in XML 1.1 and pipeline inputs and outputs that use XML 1.1 is implementation-defined. See Section 3, “Syntax Overview” The semantics of p:pipeinfo elements are implementation-defined. See Section 3.7, “Processor annotations” The set of URI schemes actually supported is implementation-defined. See Section 3.11, “Common errors” The presence of other compound steps is implementation-defined; XProc provides no standard mechanism for defining them or describing what they can contain. See Section 4.8, “Extension Steps” If the href attribute is not specified, the location of the log file or files is implementation-defined. See Section 5.5, “p:log” How each document or sequence of documents is represented in a p:log is implementation-defined. See Section 5.5, “p:log” The default value of any serialization options not specified on a particular p:serialization element is implementation-defined. See Section 5.6, “p:serialization” When a declared step is evaluated directly by the XProc processor (as opposed to occurring as an atomic step in some container), how the input and output ports are connected to documents is implementation-defined. See Section 5.8, “p:declare-step” The subpipeline may include declarations of additional steps (e.g., other pipelines or other step types that are provided by a particular implementation or in some implementation-defined way) and import other pipelines. See Section 5.8.2, “Declaring pipelines” Conformant processors must support directory paths whose scheme is file. It is implementation-defined what other schemes are supported by p:directory-list, and what the interpretation of 'directory', 'file' and 'contents' is for those schemes. See Section 7.1.6, “p:directory-list” Any file or directory determined to be special by the p:directory-list step may be output using a c:other element but the criteria for marking a file as special are implementation-defined. See Section 7.1.6, “p:directory-list” Any attributes other than name on c:file, c:directory, or c:other are implementation-defined. See Section 7.1.6, “p:directory-list” The interpretation of auth-method values on c:request other than “Basic” or “Digest” is implementation-defined. See Section 7.1.10.1, “Specifying a request” An implementation may support encodings other than base64 but these encodings and their names are implementation-defined. See Section 7.1.10.2, “Request Entity body conversion” Pipeline authors that need to preserve cookies across several p:http-request calls in the same pipeline or across multiple invocations of the same or different pipelines will have to rely on implementation-defined mechanisms. See Section 7.1.10.3.2, “Cookies” Behavior of p:unescape-markup for content-types other than application/xml is implementation-defined. See Section 7.1.26, “p:unescape-markup” If cwd is not specified, the current working directory is implementation-defined. See Section 7.2.1, “p:exec” It is implementation-defined what other algorithms are supported. See Section 7.2.2, “p:hash” If the version is not specified, the version of UUID computed is implementation-defined. See Section 7.2.3, “p:uuid” Support for other versions of UUID, and the mechanism by which the necessary inputs are made available for computing other versions, is implementation-defined. See Section 7.2.3, “p:uuid” It is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided. See Section 7.2.6, “p:validate-with-xml-schema” Support for XQueryX is implementation-defined. See Section 7.2.9, “p:xquery” Otherwise, the interpretation of the query is implementation-defined. See Section 7.2.9, “p:xquery” The point in time returned as the current dateTime is implementation-defined. See Section 7.2.9, “p:xquery” The implicit timezone is implementation-defined. See Section 7.2.9, “p:xquery” The use of media type parameters on the content-type option is implementation-defined. See Section 7.2.10, “p:xsl-formatter” If the content-type option is not specified, the output type is implementation-defined. See Section 7.2.10, “p:xsl-formatter” A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the XSL implementation used and are implementation-defined. See Section 7.2.10, “p:xsl-formatter” Implementations may support other method values but their results are implementation-defined. See Section 7.3, “Serialization Options” It is implementation-defined whether additional information items and properties, particularly those made available in the PSVI, are preserved between steps. See Section A.3, “Infoset Conformance” The following features are implementation-dependent: The evaluation order of steps not connected to one another is implementation-dependent See Section 2, “Pipeline Concepts” Outside of a try/catch, the disposition of error messages is implementation-dependent See Section 2.2, “Inputs and Outputs” Resolving a URI locally may involve resolvers of various sorts and possibly appeal to implementation-dependent mechanisms such as catalog files. See Section 2.2.1, “External Documents” Whether (and when and how) or not the intermediate results that pass between steps are ever written to a filesystem is implementation-dependent. See Section 2.2.1, “External Documents” The results of computing the union of namespaces in the presence of conflicting declarations for a particular prefix are implementation-dependent. See Section 2.6.1.2, “Step XPath Context” The set of available documents (those that may be retrieved with a URI) is implementation-dependent. See Section 2.6.2.1, “Processor XPath Context” The set of available collections is implementation-dependent. See Section 2.6.2.1, “Processor XPath Context” The set of available documents (those that may be retrieved with a URI) is implementation-dependent. See Section 2.6.2.2, “Step XPath Context” Which steps are forbidden, what privileges are needed to access resources, and under what circumstances these security constraints apply is implementation-dependent. See Section 2.12, “Security Considerations” The value of the p:episode system property in a use-when expression is implementation-dependent. See Section 3.9, “Conditional Element Exclusion” The results of testing for steps not in the XProc namespace in a use-when expression are implementation-dependent. See Section 3.9, “Conditional Element Exclusion” The ability of a step to read the p:log output of some former step is implementation-dependent. See Section 5.5, “p:log” Implementations may use extension attributes to provide implementation-dependent information about a declared step. See Section 5.8.1, “Declaring atomic steps” If no content type was specified or is associated with the resource, the inferred content type is implementation-dependent. See Section 5.14, “p:data” The interpretation of a multipart message inside another multipart message is implementation-dependent. See Section 7.1.10.4, “Converting Response Entity Bodies” If the IRI reference specified by the base-uri option on p:make-absolute-uris is not valid, or if it is absent and the input document has no base URI, the results are implementation-dependent. See Section 7.1.15, “p:make-absolute-uris” The order in which c:param elements occur in the c:param-set is implementation-dependent. See Section 7.1.18, “p:parameters” How XSLT message termination errors are reported to the XProc processor is implementation-dependent. See Section 7.1.31, “p:xslt” The specific exit status values returned by a process invoked with p:exec are implementation-dependent. See Section 7.2.1, “p:exec” The set of available documents (those that may be retrieved with a URI) is implementation-dependent. See Section 7.2.9, “p:xquery” The set of available collections is implementation-dependent. See Section 7.2.9, “p:xquery” This specification conforms to the XML Information Set [ Infoset The Document Information Item [base URI] [children] Element Information Items [base URI] [children] [attributes] [in-scope namespaces] [prefix] [local name] [namespace name] [parent] Attribute Information Items [namespace name] [prefix] [local name] [normalized value] [attribute type] [owner element] Character Information Items [character code] [parent] [element content whitespace] Processing Instruction Information Items [base URI] [target] [content] [parent] Comment Information Items [content] [parent] Namespace Information Items [prefix] [namespace name] implementation-defined [ XProc Requirements XML Processing Model Requirements and Use Cases [ Infoset XML Information Set (Second Edition) [ XML 1.0 Extensible Markup Language (XML) 1.0 (Fifth Edition) [ Namespaces 1.0 Namespaces in XML 1.0 (Third Edition) [ XML 1.1 Extensible Markup Language (XML) 1.1 (Second Edition) [ Namespaces 1.1 Namespaces in XML 1.1 (Second Edition) [ XPath 1.0 XML Path Language (XPath) Version 1.0 [ XSLT 1.0 XSL Transformations (XSLT) Version 1.0 [ XPath 2.0 XML Path Language (XPath) 2.0 [ XQuery 1.0 and XPath 2.0 Data Model (XDM) XQuery 1.0 and XPath 2.0 Data Model (XDM) et. al. [ XPath 2.0 Functions and Operators XQuery 1.0 and XPath 2.0 Functions and Operators [ XSLT 2.0 XSL Transformations (XSLT) Version 2.0 [ XSL 1.1 Extensible Stylesheet Language (XSL) Version 1.1 [ XQuery 1.0 XQuery 1.0: An XML Query Language [ RELAX NG ISO/IEC 19757-2:2008(E) Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG [ RELAX NG Compact Syntax ISO/IEC 19757-2:2003/Amd 1:2006 Document Schema Definition Languages (DSDL) — Part 2: Grammar-based validation — RELAX NG AMENDMENT 1 Compact Syntax [ RELAX NG DTD Compatibility RELAX NG DTD Compatibility [ Schematron ISO/IEC 19757-3:2006(E) Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron [ W3C XML Schema: Part 1 XML Schema Part 1: Structures Second Edition [ W3C XML Schema: Part 2 XML Schema Part 2: Datatypes Second Edition [ xml:id xml:id Version 1.0 [ XInclude XML Inclusions (XInclude) Version 1.0 (Second Edition) [ XML Base XML Base (Second Edition) [ XPointer Framework XPointer Framework [ XPointer element() Scheme XPointer element() Scheme [ Serialization XSLT 2.0 and XQuery 1.0 Serialization [ MD5 RFC 1321: The MD5 Message-Digest Algorithm [ RFC 1521 RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies [ RFC 2119 Key words for use in RFCs to Indicate Requirement Levels [ RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax [ RFC 2616 RFC 2616: Hypertext Transfer Protocol — HTTP/1.1 [ RFC 2617 RFC 2617: HTTP Authentication: Basic and Digest Access Authentication [ RFC 3023 RFC 3023: XML Media Types [ RFC 3548 RFC 3548: The Base16, Base32, and Base64 Data Encodings [ RFC 3986 RFC 3986: Uniform Resource Identifier (URI): General Syntax [ RFC 3987 RFC 3987: Internationalized Resource Identifiers (IRIs) [ Unicode TR#17 Unicode Technical Report #17: Character Encoding Model [ IANA Media Types IANA MIME Media Types [ HTML Tidy HTML Tidy Library Project [ TagSoup TagSoup - Just Keep On Truckin' [ UUID ITU X.667: Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components [ SHA1 Federal Information Processing Standards Publication 180-1: Secure Hash Standard [ RFC 4122 RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace [ CRC32 The International Conference on Dependable Systems and Networks: 459 10.1109/DSN.2002.1028931 Namespaces in XML Unless otherwise noted, the term Namespaces in XML Namespaces 1.0 Namespaces 1.1 XML XProc is intended to work equally well with [ XML 1.0 XML 1.1 XML ancestors The ancestors container atomic step An atomic step subpipeline bag-merger The bag-merger by source A document is specified by source by URI A document is specified by URI compound step A compound step subpipeline connection A connection contained steps The steps that occur directly within, or within non-step wrappers directly within, a step are called that step's contained steps container A compound step or multi-container step is a container declared inputs The input ports declared on a step are its declared inputs declared options The options declared on a step are its declared options declared outputs The output ports declared on a step are its declared outputs default readable port The default readable port dynamic error A dynamic error empty environment The empty environment empty sequence An empty sequence p:empty environment The environment extension attribute An element from the XProc namespace may extension attribute in-scope bindings The in-scope bindings option variable inherited environment The inherited environment contained step container standard modifications inline document An inline document last step The last step matches A step matches multi-container step A multi-container step subpipelines namespace fixup To produce a serializable XML Namespaces in XML namespace fixup option An option expanded name must xs:untypedAtomic parameter A parameter expanded name must xs:untypedAtomic parameter input port A parameter input port pipeline A pipeline primary parameter input port If a step has a parameter input port which is explicitly marked “ primary='true' not primary='false' primary parameter input port primary input port If a step has a document input port which is explicitly marked “ primary='true' not primary='false' primary input port primary output port If a step has a document output port which is explicitly marked “ primary='true' not primary='false' primary output port readable ports The readable ports signature The signature specified options The options on a step which have specified values, either because a p:with-option specified options static error A static error step A step step type exports The step type exports Visited subpipeline Sibling steps (and the connections between them) form a subpipeline variable A variable expanded name must xs:untypedAtomic visible If two names are in the same scope, we say that they are visible This appendix summarizes the XProc pipeline language. Machine readable descriptions of this language are available in RELAX NG compact syntax W3C XML Schema DTD <p:pipeline NCName QName boolean string prefix list string p:input p:output p:option p:log p:serialization p:declare-step p:pipeline p:import subpipeline <p:for-each NCName p:iteration-source p:output p:log subpipeline <p:viewport NCName match XSLTMatchPattern p:viewport-source p:output p:log subpipeline <p:choose NCName p:xpath-context p:variable p:when p:otherwise <p:xpath-context> p:empty p:pipe p:document p:inline p:data <p:when test XPathExpression p:xpath-context p:output p:log subpipeline <p:otherwise> p:output p:log subpipeline <p:group NCName p:output p:log subpipeline <p:try NCName p:variable p:group p:catch <p:catch NCName p:output p:log subpipeline < p:atomic-step NCName p:input p:with-option p:with-param p:log p:atomic-step < pfx:atomic-step NCName p:input p:with-option p:with-param p:log pfx:atomic-step <p:input port NCName boolean boolean XPathExpression p:empty p:document p:inline p:data <p:input port NCName XPathExpression p:empty p:pipe p:document p:inline p:data <p:input port NCName boolean boolean kind p:empty p:document p:inline <p:iteration-source XPathExpression p:empty p:pipe p:document p:inline p:data <p:viewport-source> p:pipe p:document p:inline p:data <p:output port NCName boolean boolean <p:output port NCName boolean boolean p:empty p:pipe p:document p:inline p:data <p:log port NCName anyURI <p:serialization port NCName boolean NMTOKENS string string string boolean boolean boolean string QName NFC|NFD|NFKC|NFKD|fully-normalized|none|xs:NMTOKEN boolean true|false|omit boolean string <p:variable name QName select XPathExpression p:empty p:pipe p:document p:inline p:data p:namespaces <p:option name QName boolean <p:option name QName boolean select XPathExpression <p:with-option name QName select XPathExpression p:empty p:pipe p:document p:inline p:data p:namespaces <p:with-param name QName select XPathExpression NCName p:empty p:pipe p:document p:inline p:data p:namespaces <p:namespaces QName XPathExpression prefix list <p:declare-step NCName QName boolean string prefix list string p:input p:output p:option p:log p:serialization p:declare-step p:pipeline p:import subpipeline <p:library boolean string prefix list string p:import p:declare-step p:pipeline <p:import href anyURI <p:pipe step NCName port NCName <p:inline prefix list anyElement <p:document href anyURI <p:data href anyURI QName string string string <p:empty /> <p:documentation> any-well-formed-content <p:pipeinfo> any-well-formed-content The core steps are also summarized here. <p:declare-step type =" p:add-attribute " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" attribute-name " required =" true " /> <!-- QName --> <p:option name =" attribute-prefix " /> <!-- NCName --> <p:option name =" attribute-namespace " /> <!-- anyURI --> <p:option name =" attribute-value " required =" true " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:add-xml-base " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" all " select =" 'false' " /> <!-- boolean --> <p:option name =" relative " select =" 'true' " /> <!-- boolean --> </p:declare-step> <p:declare-step type =" p:compare " > <p:input port =" source " primary =" true " /> <p:input port =" alternate " /> <p:output port =" result " primary =" false " /> <p:option name =" fail-if-not-equal " select =" 'false' " /> <!-- boolean --> </p:declare-step> <p:declare-step type =" p:count " > <p:input port =" source " sequence =" true " /> <p:output port =" result " /> <p:option name =" limit " select =" 0 " /> <!-- integer --> </p:declare-step> <p:declare-step type =" p:delete " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> <p:declare-step type =" p:directory-list " > <p:output port =" result " /> <p:option name =" path " required =" true " /> <!-- anyURI --> <p:option name =" include-filter " /> <!-- RegularExpression --> <p:option name =" exclude-filter " /> <!-- RegularExpression --> </p:declare-step> <p:declare-step type =" p:error " > <p:input port =" source " primary =" false " /> <p:output port =" result " sequence =" true " /> <p:option name =" code " required =" true " /> <!-- QName --> <p:option name =" code-prefix " /> <!-- NCName --> <p:option name =" code-namespace " /> <!-- anyURI --> </p:declare-step> <p:declare-step type =" p:escape-markup " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:filter " > <p:input port =" source " /> <p:output port =" result " sequence =" true " /> <p:option name =" select " required =" true " /> <!-- XPathExpression --> </p:declare-step> <p:declare-step type =" p:http-request " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" byte-order-mark " /> <!-- boolean --> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" encoding " /> <!-- string --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" normalization-form " select =" 'none' " /> <!-- NormalizationForm --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:identity " > <p:input port =" source " sequence =" true " /> <p:output port =" result " sequence =" true " /> </p:declare-step> <p:declare-step type =" p:insert " > <p:input port =" source " primary =" true " /> <p:input port =" insertion " sequence =" true " /> <p:output port =" result " /> <p:option name =" match " select =" '/*' " /> <!-- XSLTMatchPattern --> <p:option name =" position " required =" true " /> <!-- "first-child" | "last-child" | "before" | "after" --> </p:declare-step> <p:declare-step type =" p:label-elements " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" attribute " select =" 'xml:id' " /> <!-- QName --> <p:option name =" attribute-prefix " /> <!-- NCName --> <p:option name =" attribute-namespace " /> <!-- anyURI --> <p:option name =" label " select =" 'concat("_",$p:index)' " /> <!-- XPathExpression --> <p:option name =" match " select =" '*' " /> <!-- XSLTMatchPattern --> <p:option name =" replace " select =" 'true' " /> <!-- boolean --> </p:declare-step> <p:declare-step type =" p:load " > <p:output port =" result " /> <p:option name =" href " required =" true " /> <!-- anyURI --> <p:option name =" dtd-validate " select =" 'false' " /> <!-- boolean --> </p:declare-step> <p:declare-step type =" p:make-absolute-uris " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" base-uri " /> <!-- anyURI --> </p:declare-step> <p:declare-step type =" p:namespace-rename " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" from " /> <!-- anyURI --> <p:option name =" to " /> <!-- anyURI --> <p:option name =" apply-to " select =" 'all' " /> <!-- "all" | "elements" | "attributes" --> </p:declare-step> <p:declare-step type =" p:pack " > <p:input port =" source " sequence =" true " primary =" true " /> <p:input port =" alternate " sequence =" true " /> <p:output port =" result " sequence =" true " /> <p:option name =" wrapper " required =" true " /> <!-- QName --> <p:option name =" wrapper-prefix " /> <!-- NCName --> <p:option name =" wrapper-namespace " /> <!-- anyURI --> </p:declare-step> <p:declare-step type =" p:parameters " > <p:input port =" parameters " kind =" parameter " primary =" false " /> <p:output port =" result " primary =" false " /> </p:declare-step> <p:declare-step type =" p:rename " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" new-name " required =" true " /> <!-- QName --> <p:option name =" new-prefix " /> <!-- NCName --> <p:option name =" new-namespace " /> <!-- anyURI --> </p:declare-step> <p:declare-step type =" p:replace " > <p:input port =" source " primary =" true " /> <p:input port =" replacement " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> <p:declare-step type =" p:set-attributes " > <p:input port =" source " primary =" true " /> <p:input port =" attributes " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> <p:declare-step type =" p:sink " > <p:input port =" source " sequence =" true " /> </p:declare-step> <p:declare-step type =" p:split-sequence " > <p:input port =" source " sequence =" true " /> <p:output port =" matched " sequence =" true " primary =" true " /> <p:output port =" not-matched " sequence =" true " /> <p:option name =" initial-only " select =" 'false' " /> <!-- boolean --> <p:option name =" test " required =" true " /> <!-- XPathExpression --> </p:declare-step> <p:declare-step type =" p:store " > <p:input port =" source " /> <p:output port =" result " primary =" false " /> <p:option name =" href " required =" true " /> <!-- anyURI --> <p:option name =" byte-order-mark " /> <!-- boolean --> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" encoding " /> <!-- string --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" normalization-form " select =" 'none' " /> <!-- NormalizationForm --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:string-replace " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" replace " required =" true " /> <!-- XPathExpression --> </p:declare-step> <p:declare-step type =" p:unescape-markup " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" namespace " /> <!-- anyURI --> <p:option name =" content-type " select =" 'application/xml' " /> <!-- string --> <p:option name =" encoding " /> <!-- string --> <p:option name =" charset " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:unwrap " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> <p:declare-step type =" p:wrap " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" wrapper " required =" true " /> <!-- QName --> <p:option name =" wrapper-prefix " /> <!-- NCName --> <p:option name =" wrapper-namespace " /> <!-- anyURI --> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" group-adjacent " /> <!-- XPathExpression --> </p:declare-step> <p:declare-step type =" p:wrap-sequence " > <p:input port =" source " sequence =" true " /> <p:output port =" result " sequence =" true " /> <p:option name =" wrapper " required =" true " /> <!-- QName --> <p:option name =" wrapper-prefix " /> <!-- NCName --> <p:option name =" wrapper-namespace " /> <!-- anyURI --> <p:option name =" group-adjacent " /> <!-- XPathExpression --> </p:declare-step> <p:declare-step type =" p:xinclude " > <p:input port =" source " /> <p:output port =" result " /> <p:option name =" fixup-xml-base " select =" 'false' " /> <!-- boolean --> <p:option name =" fixup-xml-lang " select =" 'false' " /> <!-- boolean --> </p:declare-step> <p:declare-step type =" p:xslt " > <p:input port =" source " sequence =" true " primary =" true " /> <p:input port =" stylesheet " /> <p:input port =" parameters " kind =" parameter " /> <p:output port =" result " primary =" true " /> <p:output port =" secondary " sequence =" true " /> <p:option name =" initial-mode " /> <!-- QName --> <p:option name =" template-name " /> <!-- QName --> <p:option name =" output-base-uri " /> <!-- anyURI --> <p:option name =" version " /> <!-- string --> </p:declare-step> As are the optional steps. <p:declare-step type =" p:exec " > <p:input port =" source " primary =" true " sequence =" true " /> <p:output port =" result " primary =" true " /> <p:output port =" errors " /> <p:output port =" exit-status " /> <p:option name =" command " required =" true " /> <!-- string --> <p:option name =" args " select =" '' " /> <!-- string --> <p:option name =" cwd " /> <!-- string --> <p:option name =" source-is-xml " select =" 'true' " /> <!-- boolean --> <p:option name =" result-is-xml " select =" 'true' " /> <!-- boolean --> <p:option name =" wrap-result-lines " select =" 'false' " /> <!-- boolean --> <p:option name =" errors-is-xml " select =" 'false' " /> <!-- boolean --> <p:option name =" wrap-error-lines " select =" 'false' " /> <!-- boolean --> <p:option name =" path-separator " /> <!-- string --> <p:option name =" failure-threshold " /> <!-- integer --> <p:option name =" arg-separator " select =" ' ' " /> <!-- string --> <p:option name =" byte-order-mark " /> <!-- boolean --> <p:option name =" cdata-section-elements " select =" '' " /> <!-- ListOfQNames --> <p:option name =" doctype-public " /> <!-- string --> <p:option name =" doctype-system " /> <!-- anyURI --> <p:option name =" encoding " /> <!-- string --> <p:option name =" escape-uri-attributes " select =" 'false' " /> <!-- boolean --> <p:option name =" include-content-type " select =" 'true' " /> <!-- boolean --> <p:option name =" indent " select =" 'false' " /> <!-- boolean --> <p:option name =" media-type " /> <!-- string --> <p:option name =" method " select =" 'xml' " /> <!-- QName --> <p:option name =" normalization-form " select =" 'none' " /> <!-- NormalizationForm --> <p:option name =" omit-xml-declaration " select =" 'true' " /> <!-- boolean --> <p:option name =" standalone " select =" 'omit' " /> <!-- "true" | "false" | "omit" --> <p:option name =" undeclare-prefixes " /> <!-- boolean --> <p:option name =" version " select =" '1.0' " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:hash " > <p:input port =" source " primary =" true " /> <p:output port =" result " /> <p:input port =" parameters " kind =" parameter " /> <p:option name =" value " required =" true " /> <!-- string --> <p:option name =" algorithm " required =" true " /> <!-- QName --> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" version " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:uuid " > <p:input port =" source " primary =" true " /> <p:output port =" result " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> <p:option name =" version " /> <!-- integer --> </p:declare-step> <p:declare-step type =" p:validate-with-relax-ng " > <p:input port =" source " primary =" true " /> <p:input port =" schema " /> <p:output port =" result " /> <p:option name =" dtd-attribute-values " select =" 'false' " /> <!-- boolean --> <p:option name =" dtd-id-idref-warnings " select =" 'false' " /> <!-- boolean --> <p:option name =" assert-valid " select =" 'true' " /> <!-- boolean --> </p:declare-step> <p:declare-step type =" p:validate-with-schematron " > <p:input port =" parameters " kind =" parameter " /> <p:input port =" source " primary =" true " /> <p:input port =" schema " /> <p:output port =" result " primary =" true " /> <p:output port =" report " sequence =" true " /> <p:option name =" phase " select =" '#ALL' " /> <!-- string --> <p:option name =" assert-valid " select =" 'true' " /> <!-- boolean --> </p:declare-step> <p:declare-step type =" p:validate-with-xml-schema " > <p:input port =" source " primary =" true " /> <p:input port =" schema " sequence =" true " /> <p:output port =" result " /> <p:option name =" use-location-hints " select =" 'false' " /> <!-- boolean --> <p:option name =" try-namespaces " select =" 'false' " /> <!-- boolean --> <p:option name =" assert-valid " select =" 'true' " /> <!-- boolean --> <p:option name =" mode " select =" 'strict' " /> <!-- "strict" | "lax" --> </p:declare-step> <p:declare-step type =" p:www-form-urldecode " > <p:output port =" result " /> <p:option name =" value " required =" true " /> <!-- string --> </p:declare-step> <p:declare-step type =" p:www-form-urlencode " > <p:input port =" source " primary =" true " /> <p:output port =" result " /> <p:input port =" parameters " kind =" parameter " /> <p:option name =" match " required =" true " /> <!-- XSLTMatchPattern --> </p:declare-step> <p:declare-step type =" p:xquery " > <p:input port =" source " sequence =" true " primary =" true " /> <p:input port =" query " /> <p:input port =" parameters " kind =" parameter " /> <p:output port =" result " sequence =" true " /> </p:declare-step> <p:declare-step type =" p:xsl-formatter " > <p:input port =" source " /> <p:input port =" parameters " kind =" parameter " /> <p:output port =" result " primary =" false " /> <p:option name =" href " required =" true " /> <!-- anyURI --> <p:option name =" content-type " /> <!-- string --> </p:declare-step> And the step vocabulary elements. <c:param name QName anyURI value string <c:param-set> c:param <c:data string string string string <c:result> string <c:directory name string c:file c:directory c:other <c:file name string <c:other name string <c:request method NCName anyURI boolean boolean string string string boolean string c:header c:multipart c:body <c:header name string value string <c:multipart content-type string boundary string c:body <c:body content-type string string string string string anyElement <c:response integer c:header c:multipart c:body <c:line> string <c:query> string The following error codes are defined by this specification. The following static errors Static Errors err:XS0001 It is a static error if there are any loops in the connections between steps: no step can be connected to itself nor can there be any sequence of connections through other steps that leads back to itself. See: Connections err:XS0002 All 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 connected. See: Inputs and Outputs err:XS0004 It is a static error if an option or variable declaration duplicates the name of any other option or variable in the same environment. See: Scoping of Names p:option p:with-option err:XS0005 It is a static error if the primary output port of any step is not connected. See: Inputs and Outputs err:XS0006 It is a static error if the primary output port has no explicit connection 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 specification unless they are extension attributes. See: Common 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 contains a step whose specified inputs, outputs, and options do not match the signature for steps of that type. See: Extension Steps err:XS0011 It is a static error to identify two ports with the same name on the same step. See: Document Inputs Parameter Inputs p:output err:XS0014 It is a static error to identify more than one output port as primary. See: p:output err:XS0015 It is a static error if a compound step has no contained steps. See: Common errors err:XS0017 It is a static error to specify that an option is both required and has a default value. See: p:option err:XS0018 If an option is required, it is a static error to invoke the step without specifying a value for that option. See: p:option err:XS0019 it is a static error for a variable's document connection to refer to the output port of any step in the surrounding container's contained steps See: p:variable err:XS0020 It is a static error if the binding attribute on p:namespaces is specified and its value is not the name of an in-scope binding. See: Namespaces on variables, options, and parameters err:XS0022 In all cases except the p:output of a compound step, it is a static error if the port identified by a p:pipe is not in the readable ports of the step that contains the p:pipe. See: p:pipe err:XS0024 It is a static error if the content of the p:inline element does not consist of exactly one element, optionally preceded and/or followed by any number of processing instructions, comments or whitespace characters. See: p:inline 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 on the p:log is not the name of an output port on the step in which it appears or if more than one p:log element is applied to the same port. See: p:log err:XS0027 It is a static error if an option is specified with both the shortcut form and the long form. See: Syntactic Shortcut for Option Values err:XS0028 It is a static error to declare an option or variable in the XProc namespace. See: p:variable p:option err:XS0029 It is a static error to specify a connection 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 one input port is the primary. See: Document Inputs Parameter Inputs err:XS0031 It is a static error to use an option on an atomic step that is not declared on steps of that type. See: Syntactic Shortcut for Option Values p:with-option err:XS0032 It is a static error if no connection is provided and the default readable port is undefined. See: Document Inputs err:XS0033 It is a static error to specify any kind of input other than “document” or “parameter”. See: Parameter Inputs err:XS0034 It is a static error if the specified port is not a parameter input port or if no port is specified and the step does not have a primary parameter input port. See: p:with-param err:XS0035 It is a static error if the declaration of a parameter input port contains a connection; parameter input port declarations must be empty. See: Parameter Inputs 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 once in the same scope. See: Scoping of Names Handling Circular and Re-entrant Library Imports (Non-Normative) Handling Circular and Re-entrant Library Imports (Non-Normative) Handling Circular and Re-entrant Library Imports (Non-Normative) err:XS0037 It is a static error if any step directly contains text nodes that do not consist entirely of whitespace. See: Common errors err:XS0038 It is a static error if any required attribute is not provided. See: Common errors err:XS0039 It is a static error if the port specified on the p:serialization is not the name of an output port on the pipeline in which it appears or if more than one p:serialization element is applied to the same port. See: p:serialization err:XS0040 It is a static error to specify any value other than true. See: Parameter Inputs err:XS0041 It is a static error to specify both binding and element on the same p:namespaces element. See: Namespaces on variables, options, and parameters err:XS0042 It is a static error to attempt to provide a connection for an input port on the declaration of an atomic step. See: Document Inputs err:XS0044 It is a static error if any element in the XProc namespace or any step has element children other than those specified for it by this specification. In particular, the presence of atomic steps for which there is no visible declaration may raise this error. See: Common errors err:XS0048 It is a static error to use a declared step as a compound step. See: Extension Steps err:XS0051 It is a static error if the except-prefixes attribute on p:namespaces does not contain 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 on variables, options, and parameters err:XS0052 It is a static error if the URI of a p:import cannot be retrieved or if, once 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:XS0055 It is a static error if a primary parameter input port is unconnected and the pipeline that contains the step has no primary parameter input port unless at least one explicit p:with-param is provided for that port. See: Parameter Inputs err:XS0057 It is a static error if the exclude-inline-prefixes attribute does not contain 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 on 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: Common errors err:XS0060 It is a static error if the processor encounters an explicit request for a previous version 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 expression refers to the context or attempts to refer to any documents or collections. See: Conditional Element Exclusion err:XS0062 It is a static error if a required version attribute is not present. See: Versioning Considerations err:XS0063 It is a static error if the value of the version attribute is not a xs:decimal. See: Versioning Considerations The following dynamic errors Dynamic Errors err:XD0001 It is a dynamic error if a non-XML resource is produced on a step output or arrives on a step input. See: Inputs and Outputs err:XD0003 It is a dynamic error if the viewport source does not provide exactly one 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 one document appears on the connection for the xpath-context. See: p:xpath-context err:XD0006 If sequence is not specified, or has the value false, then it is a dynamic error unless exactly one document appears on the declared port. See: Document Inputs p:exec err:XD0007 If sequence is not specified on p:output, or has the value false, then it is a dynamic error if the step does not produce exactly one document on the declared port. See: p:output err:XD0008 It is a dynamic error if a document sequence appears where a document to be used as the context node is expected. See: Processor XPath Context Processor XPath Context p:variable p:with-option p:with-param err:XD0009 It is a dynamic error if the element attribute on p:namespaces is specified and it does not identify a single element node. See: Namespaces on variables, options, and parameters err:XD0010 It is a dynamic error if the match expression on 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 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: Common errors err:XD0013 It is a dynamic error if the specified namespace bindings are inconsistent; that is, if the same prefix is bound to two different namespace names. See: Namespaces on variables, options, and parameters err:XD0014 It is a dynamic error for any unqualified attribute names other than “name”, “namespace”, or “value” to appear on a c:param element. See: The c:param element The c:param-set element err:XD0015 It is a dynamic error if the specified QName cannot be resolved with the in-scope namespace declarations. See: System Properties err:XD0016 It is a dynamic error if the select expression on a p:input returns atomic values or anything other than element or document nodes (or an empty sequence). See: Document Inputs err:XD0017 It is a dynamic error if the running pipeline attempts to invoke a step which the processor does not know how to perform. See: Extension Steps err:XD0018 It is a dynamic error if the parameter list contains any elements other than c:param. See: The c:param-set element err:XD0019 It is a dynamic error if any option value does not satisfy the type required for that option. See: Common errors err:XD0020 It is a dynamic error if the combination of serialization options specified or defaulted is not allowed. See: p:serialization 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 Considerations err:XD0022 It is a dynamic error if a processor that does not support PSVI annotations attempts to invoke a step which asserts that they are required. See: PSVIs in XProc err:XD0023 It is a dynamic error if an XPath expression is encountered which cannot be evaluated (because it is syntactically incorrect, contains references to unbound variables or unknown functions, or for any other reason). See: XPaths in XProc err:XD0024 It is a dynamic error if a 2.0 processor encounters an XPath 1.0 expression and it does not support XPath 1.0 compatibility mode. See: XPaths in XProc err:XD0025 It is a dynamic error if the namespace attribute is specified, the name contains a colon, and the specified namespace is not the same as the in-scope namespace binding for the specified prefix. See: The c:param element err:XD0026 It is a dynamic error if the select expression makes reference to the context node, size, or position when the context item is undefined. See: p:variable p:option p:with-option p:with-param err:XD0027 It is a dynamic error if the processor encounters an xpath-version that it does not support. See: XPaths in XProc err:XD0028 It is a dynamic error if any attribute value does not satisfy the type required for that attribute. See: Common errors err:XD0029 It is a dynamic error if the document referenced by a p:data element does not exist, cannot be accessed, or cannot be encoded as specified. See: p:data err:XD0030 It is a dynamic error if a step is unable or incapable of performing its function. See: Common errors err:XD0031 It is a dynamic error to use the XProc namespace in the name of a parameter. See: p:with-param err:XD0033 It is a dynamic error if the name specified is not the name of an in-scope option or variable. See: Value Available err:XD0034 It is a dynamic error to specify a new namespace or prefix if the lexical value of the specified name contains a colon (or if no wrapper is explicitly specified). See: p:data p:add-attribute p:error p:label-elements p:pack p:rename p:wrap p:wrap-sequence The following dynamic errors Step Errors err:XC0002 It is a dynamic error if the value starts with the string “--”. See: Request Entity body conversion err:XC0003 It is a dynamic error if a username or password is specified without specifying an auth-method, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported. See: Specifying a request err:XC0004 It is a dynamic error if the status-only attribute has the value true and the detailed attribute does not have the value true. See: Specifying a request err:XC0005 It is a dynamic error if the request contains a c:body or c:multipart but the method does not allow for an entity body being sent with the request. See: Specifying a request err:XC0006 It is a dynamic error if the method is not specified on a c:request. See: Specifying a request err:XC0010 It is a dynamic error if an encoding of base64 is specified and the character set is not specified or if the specified character set is not supported by the implementation. See: p:unescape-markup err:XC0012 It is a dynamic error if the contents of the directory path are not available to the step due to access restrictions in the environment in which the pipeline is run. See: p:directory-list err:XC0013 It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace. See: p:rename err:XC0014 It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option. See: p:namespace-rename err:XC0017 It is a dynamic error if the absolute path does not identify a directory. See: p:directory-list err:XC0019 It is a dynamic error if the documents are not equal, and the value of the fail-if-not-equal option is true. See: p:compare err:XC0020 It is a dynamic error if the the user specifies a value or values that are inconsistent with each other or with the requirements of the step or protocol. See: Specifying a request err:XC0022 it is a dynamic error if the content of the c:body element does not consist of exactly one element, optionally preceded and/or followed by any number of processing instructions, comments or whitespace characters See: Request Entity body conversion err:XC0023 It is a dynamic error if a select expression or match pattern returns a node type that is not allowed by the step. See: Common errors p:add-attribute p:insert p:label-elements p:make-absolute-uris p:rename p:replace p:set-attributes p:unwrap p:wrap err:XC0025 It is a dynamic error if the match pattern matches anything other than an element node and the value of the position option is “first-child” or “last-child”. See: p:insert err:XC0027 It is a dynamic error if the document is not valid or the step doesn't support DTD validation. See: p:load err:XC0028 it is a dynamic error if the content of the c:body element does not consist entirely of characters See: Request Entity body conversion err:XC0029 It is a dynamic error if an XInclude error occurs during processing. See: p:xinclude err:XC0030 It is a dynamic error if the override-content-type value cannot be used (e.g. text/plain to override image/png). See: Managing the response err:XC0033 It is a dynamic error if the command cannot be run. See: p:exec err:XC0034 It is a dynamic error if the current working directory cannot be changed to the value of the cwd option. See: p:exec err:XC0035 It is a dynamic error to specify both result-is-xml and wrap-result-lines. See: p:exec err:XC0036 It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm. See: p:hash err:XC0037 It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value. See: p:www-form-urldecode err:XC0038 It is a dynamic error if the specified version of XSLT is not available. See: p:xslt err:XC0039 It is a dynamic error if a sequence of documents (including an empty sequence) is provided to an XSLT 1.0 step. See: p:xslt err:XC0040 It is a dynamic error if the document element of the document that arrives on the source port is not c:request. See: p:http-request err:XC0050 It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location. See: p:store err:XC0051 It is a dynamic error if the content-type specified is not supported by the implementation. See: p:unescape-markup err:XC0052 It is a dynamic error if the encoding specified is not supported by the implementation. See: Request Entity body conversion p:unescape-markup err:XC0053 It is a dynamic error if the assert-valid option is true and the input document is not valid. See: p:validate-with-relax-ng p:validate-with-xml-schema err:XC0054 It is a dynamic error if the assert-valid option is true and any Schematron assertions fail. See: p:validate-with-schematron err:XC0055 It is a dynamic error if the implementation does not support the specified mode. See: p:validate-with-xml-schema err:XC0056 It is a dynamic error if the specified initial mode or named template cannot be applied to the specified stylesheet. See: p:xslt err:XC0057 It is a dynamic error if the sequence that results from evaluating the XQuery contains items other than documents and elements. See: p:xquery err:XC0058 It is a dynamic error if the all and relative options are both true. See: p:add-xml-base err:XC0059 It is a dynamic error if the QName value in the attribute-name option uses the prefix “xmlns” or any other prefix that resolves to the namespace name “http://www.w3.org/2000/xmlns/”. See: p:add-attribute err:XC0060 It is a dynamic error if the processor does not support the specified version of the UUID algorithm. See: p:uuid err:XC0061 It is a dynamic error if the name of any encoded parameter name is not a valid xs:NCName. See: p:www-form-urldecode err:XC0062 It is a dynamic error if the match option matches a namespace node. See: p:delete err:XC0063 It is a dynamic error if the path-separator option is specified and is not exactly one character long. See: p:exec err:XC0064 It is a dynamic error if the exit code from the command is greater than the specified failure-threshold value. See: p:exec err:XC0066 It is a dynamic error if the arg-separator option is specified and is not exactly one character long. See: p:exec An XProc processor may find it necessary to add missing namespace declarations to ensure that a document can be serialized. While this process is implementation defined, the purpose of this appendix is to provide guidance as to what an implementation might do to either prevent such situations or fix them as before serialization. When a namespace binding is generated, the prefix associated with the QName of the element or attribute in question should be used. From an Infoset perspective, this is accomplished by setting the [prefix] An implementation can avoid namespace fixup by making sure that the standard step library does not output documents that require fixup. The following list contains suggestions as to how to accomplish this within the steps: Any step that outputs an element in the step vocabulary namespace http://www.w3.org/ns/xproc-step c When attributes are added by p:add-attribute p:set-attributes When an element is renamed by p:rename 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 declaration must be preserved by adding a default namespace declaration unless the child element has a different default namespace. When an attribute is renamed by p:rename When an element wraps content via p:wrap If the prefix used by the QName is not in the in-scope namespaces of the wrapper element, the step must add a namespace declaration of the prefix to the in-scope namespaces. If the prefix is amongst 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 declaration must be preserved by adding a default namespace declaration unless the child element has a different default namespace. When the wrapper element is added for p:wrap-sequence p:pack When a element is removed via p:unwrap In the output from p:xslt When handling imports, an implementation needs to be able to detect the following situations, and distinguish them from cases where multiple import chains produce genuinely conflicting step definitions: Circular imports: A imports B, B imports A. Re-entrant imports: A imports B and C, B imports D, C imports D. One way to achieve this is as follows: [Definition: The step type exports Visited The step type exports p:pipeline, p:declare-step A singleton bag containing the type p:library The bag-merger step type exports p:import Let RU href RU Visited Visited RU step type exports all other elements An empty bag The changes to Visited p:import Visited returning Given a pipeline library document with actual resolved URI DU static error err:XS0036 step type exports DU Visited Given a top-level pipeline document with actual resolved URI DU static error err:XS0036 bag-merger step type exports step type exports DU Visited Given a non-top-level p:pipeline p:declare-step static error err:XS0036 bag-merger step type exports step type exports Visited Visited The phrase "a copy of the Visited p:pipeline p:declare-step not Visited and p:import down p:pipeline p:declare-step [Definition: The bag-merger XProc imposes as few constraints on the order in which steps must be evaluated as possible and almost no constraints on parallel execution. In the simple, and we believe overwhelmingly common case, inputs flow into the pipeline, through the pipeline from one step to the next, and results are produced at the end. The order of the steps is constrained by the input/output connections between them. Implementations are free to execute them in a purely sequential fashion or in parallel, as they see fit. The results are the same in either case. This is not true for pipelines which rely on side effects, such as the state of the filesystem or the state of the web. Consider the following pipeline: <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="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 solution is straightforward. Even if you need the saved stylesheet, you don't need to rely on it in your pipeline: <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="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 implementation strategy. Implementations are free to invent additional control structures using p:pipeinfo extension attributes application/xproc+xml This appendix registers a new MIME media type, “ application/xproc+xml MIME media type name: application MIME subtype name: xproc+xml Required parameters: None. Optional parameters: charset This parameter has identical semantics to the charset application/xml RFC 3023 Encoding considerations: By virtue of XProc content being XML, it has the same considerations when sent as “ application/xproc+xml RFC 3023 Security considerations: Several XProc elements may refer to arbitrary URIs. In this case, the security issues of [ RFC 2396 In addition, because of the extensibility features of XProc, it is possible that “application/xproc+xml” may describe content that has security implications beyond those described here. However, only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements. Because XProc is extensible, conformant "application/xproc+xml" processors can expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid XProc or that the processor will recognize all of the elements and attributes in the document. Published specification: This media type registration is for XProc documents as described by this specification which is located at http://www.w3.org/TR/xproc Applications which use this media type: There is no experimental, vendor specific, or personal tree predecessor to “ application/xproc+xml Additional information: Magic number(s): There is no single initial octet sequence that is always present in XProc documents. File extension(s): XProc documents are most often identified with the extension “ .xpl Macintosh File Type Code(s): TEXT Person & email address to contact for further information: Norman Walsh, < [email protected] Intended usage: COMMON Author/Change controller: The XProc specification is a work product of the World Wide Web Consortium's XML Processing Model Working Group. The W3C has change control over these specifications. For documents labeled as “ application/xproc+xml application/xml RFC 3023

Related documents

• latn gap#649807
• grek gap#649808
• mong gap#649809
• nkoo gap#649810
• osge osa gap#649811