XProc 3.0: Standard Step Library

The p:add-attribute step adds a single attribute to a set of matching elements. The input document specified on the source is processed for matches specified by the match pattern in the match option. For each of these matches, the attribute whose name is specified by the attribute-name option is set to the attribute value specified by the attribute-value option.

The resulting document is produced on the result output port and consists of a exact copy of the input with the exception of the matched elements. Each of the matched elements is copied to the output with the addition of the specified attribute with the specified value.

<p:declare-step type="p:add-attribute">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" select="'/*'" as="xs:string"/>         <!-- XSLTMatchPattern -->
     <p:option name="attribute-name" required="true" as="xs:QName"/>
     <p:option name="attribute-prefix" as="xs:NCName"/>            
     <p:option name="attribute-namespace" as="xs:anyURI"/>         
     <p:option name="attribute-value" required="true" as="xs:string"/>
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if the match pattern matches a node which is not an element.

The value of the attribute-name option must be a QName. If the lexical value does not contain a colon, then the attribute-namespace may be used to specify the namespace of the attribute. In that case, the attribute-prefix may be specified to suggest a prefix for the attribute name. It is a dynamic error (err:XD0034) to specify a new namespace or prefix if the lexical value of the specified name contains a colon. The corresponding expanded name is used to construct the attribute.

The value of the attribute-value option must be a legal attribute value according to XML.

If an attribute with the same name as the expanded name from the attribute-name option exists on the matched element, the value specified in the attribute-value option is used to set the value of that existing attribute. That is, the value of the existing attribute is changed to the attribute-value value.

This step cannot be used to add namespace declarations. It is a dynamic error (err:XC0059) 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/. Note, however, that while namespace declarations cannot be added explicitly by this step, adding an attribute whose name is in a namespace for which there is no namespace declaration in scope on the matched element may result in a namespace binding being added by namespace fixup.

If an attribute named xml:base is added or changed, the base URI of the element must also be amended accordingly.

The p:add-xml-base step exposes the base URI via explicit xml:base attributes. The input document from the source port is replicated to the result port with xml:base attributes added to or corrected on each element as specified by the options on this step.

<p:declare-step type="p:add-xml-base">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="all" select="false()" as="xs:boolean"/>       
     <p:option name="relative" select="true()" as="xs:boolean"/>   
</p:declare-step>

The value of the all option must be a boolean.

The value of the relative option must be a boolean.

It is a dynamic error (err:XC0058) if the all and relative options are both true.

The p:add-xml-base step modifies its input as follows:

The p:cast-content-type step changes the media type of its input.

<p:declare-step type="p:cast-content-type">
     <p:input port="source" content-types="*/*"/>
     <p:output port="result" content-types="*/*"/>
     <p:option name="content-type" as="xs:string"/>                
     <p:option name="parameters" as="map(*)"/>                     
</p:declare-step>

The input document is transformed from one media type to another. It is a dynamic error (err:XC0070) if the supplied content-type is not a valid media type of the form “type/subtype+ext”.

The parameters can be used to supply parameters to control casting. The semantics of the keys and the allowed values for these keys are implementation-defined. It is a dynamic error (err:XC0079) if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

In all cases except when the input document is a c:data element, it is a dynamic error (err:XC075) if the content-type is not supplied.

The p:compare step compares two documents for equality.

<p:declare-step type="p:compare">
     <p:input port="source" primary="true" content-types="*/*"/>
     <p:input port="alternate" content-types="*/*"/>
     <p:output port="result" content-types="application/xml"/>
     <p:output port="differences" content-types="*/*" sequence="true"/>
     <p:option name="method" as="xs:QName"/>                       
     <p:option name="fail-if-not-equal" select="false()" as="xs:boolean"/>
     <p:option name="parameters" as="map(xs:QName,item())"/>       
</p:declare-step>

This step takes single documents on each of two ports and compares them. If method is not specified, or if deep-equal is specified, the comparison uses fn:deep-equal (as defined in [XPath and XQuery Functions and Operators 3.1]). Implementations of p:compare must support the deep-equal method; other supported methods are implementation-defined. It is a dynamic error (err:XC0076) if the comparison method specified in p:compare is not supported by the implementation. It is a dynamic error (err:XC0077) if the media types of the documents supplied are incompatible with the comparison method.

It is a dynamic error (err:XC0019) if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true. If the documents are equal, or if the value of the fail-if-not-equal option is false, a c:result document is produced with contents true if the documents are equal, otherwise false.

If fail-if-not-equal is false, and the documents differ, an implementation-defined summary of the differences between the two documents may appear on the differences port.

The p:count step counts the number of documents in the source input sequence and returns a single document on result containing that number. The generated document contains a single c:result element whose contents is the string representation of the number of documents in the sequence.

<p:declare-step type="p:count">
     <p:input port="source" content-types="*/*" sequence="true"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="limit" select="0" as="xs:integer"/>           
</p:declare-step>

If the limit option is specified and is greater than zero, the p:count step will count at most that many documents. This provides a convenient mechanism to discover, for example, if a sequence consists of more than 1 document, without requiring every single document to be buffered before processing can continue.

The p:delete step deletes items specified by a match pattern from the source input document and produces the resulting document, with the deleted items removed, on the result port.

<p:declare-step type="p:delete">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" required="true" as="xs:string"/>       <!-- XSLTMatchPattern -->
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. A match pattern may match multiple items to be deleted.

If an element is selected by the match option, the entire subtree rooted at that element is deleted.

This step cannot be used to remove namespaces. It is a dynamic error (err:XC0062) if the match option matches a namespace node. Also, note that deleting an attribute named xml:base does not change the base URI of the element on which it occurred.

The p:directory-list step produces a list of the contents of a specified directory.

<p:declare-step type="p:directory-list">
     <p:output port="result" content-type="application/xml"/>
     <p:option name="path" required="true" as="xs:anyURI"/>        
     <p:option name="include-filter" as="xs:string"/>              <!-- RegularExpression -->
     <p:option name="exclude-filter" as="xs:string"/>              <!-- RegularExpression -->
</p:declare-step>

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. Implementations should support “globbing”. See Appendix B, URI globbing.

It is a dynamic error (err:XC0017) if the absolute path does not identify a directory. It is a dynamic error (err:XC0012) 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.

If present, the value of the include-filter or exclude-filter option must be a regular expression as specified in [XPath and XQuery Functions and Operators 3.1], section 7.61 “Regular Expression Syntax”.

If the include-filter pattern matches a directory entry's name, the entry is included in the output. If the exclude-filter pattern matches a directory entry's name, the entry is excluded in the output. If both options are provided, the include filter is processed first, then the exclude filter.

The result document produced for the specified directory path has a c:directory document element whose base URI is the directory path and whose name attribute is the last segment of the directory path (that is, the directory's (local) name).

<c:directory
  name = string>
    (c:file |
     c:directory |
     c:other)*
</c:directory>

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 was specified, or the (local) name of the entry matches the filter pattern, a c:file, a c:directory, or a c:other element is produced, as follows:

When a directory entry is a subdirectory, that directory's entries are not output as part of that entry's c:directory. A user must apply this step again to the subdirectory to list subdirectory contents.

Each of the elements c:file, c:directory, and c:other has a name attribute when it appears within the top-level c:directory element, whose value is a relative IRI reference, giving the (local) file or directory name.

Any attributes other than name on c:file, c:directory, or c:other are implementation-defined.

The p:error step generates a dynamic error using the input provided to the step.

<p:declare-step type="p:error">
     <p:input port="source" sequence="true" content-types="*/*"/>
     <p:output port="result" sequence="true" content-types="*/*"/>
     <p:option name="code" required="true" as="xs:QName"/>         
     <p:option name="code-prefix" as="xs:NCName"/>                 
     <p:option name="code-namespace" as="xs:anyURI"/>              
</p:declare-step>

The value of the code option must be a QName. If the lexical value does not contain a colon, then the code-namespace may be used to specify the namespace of the code. In that case, the code-prefix may be specified to suggest a prefix for the code. It is a dynamic error (err:XD0034) to specify a new namespace or prefix if the lexical value of the specified name contains a colon.

This step uses the document provided on its input as the content of the error raised. An instance of the c:errors element will be produced on the error output port, as is always the case for dynamic errors. The error generated can be caught by a p:try just like any other dynamic error.

For authoring convenience, the p:error step is declared with a single, primary output port. With respect to connections, this port behaves like any other output port even though nothing can ever appear on it since the step always fails.

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 and column, or offset, might also be present on the c:error to identify the location of the p:error element in the pipeline.

The p:escape-markup step applies XML serialization to the children of the document element and replaces those children with their serialization. The outcome is a single element with text content that represents the "escaped" syntax of the children as they were serialized.

<p:declare-step type="p:escape-markup">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="serialization" as="map(xs:string,xs:anyAtomicValue)"/>
</p:declare-step>

This step supports the standard serialization options as specified in [Serialization]. These options control how the output markup is produced before it is escaped.

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>

By default, this step must not generate an XML declaration in the escaped result.

The p:filter step selects portions of the source document based on a (possibly dynamically constructed) XPath select expression.

<p:declare-step type="p:filter">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" sequence="true" content-types="application/xml"/>
     <p:option name="select" required="true" as="xs:string"/>      <!-- XPathExpression -->
</p:declare-step>

This step behaves just like an p:input with a select expression except that the select expression is computed dynamically.

The p:hash step generates a hash, or digital “fingerprint”, for some value and injects it into the source document.

<p:declare-step type="p:hash">
     <p:input port="source" primary="true" content-types="*/*"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="parameters" as="map(xs:QName,item())"/>       
     <p:option name="value" required="true" as="xs:string"/>       
     <p:option name="algorithm" required="true" as="xs:QName"/>    
     <p:option name="match" select="'/*'" as="xs:string"/>         <!-- XSLTMatchPattern -->
     <p:option name="version" as="xs:string"/>                     
</p:declare-step>

The value of the algorithm option must be a QName. If it does not have a prefix, then it must be one of the following values: “crc”, “md”, or “sha”.

If a version is not specified, the default version is algorithm-defined. For “crc” it is 32, for “md” it is 5, for “sha” it is 1.

A hash is constructed from the string specified in the value option using the specified algorithm and version. Implementations must support [CRC32], [MD5], and [SHA1] hashes. It is implementation-defined what other algorithms are supported. The resulting hash should be returned as a string of hexadecimal characters.

The value of the match option must be an XSLTMatchPattern.

The hash of the specified value is computed using the algorithm and parameters specified. It is a dynamic error (err:XC0036) if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.

The matched nodes are specified with the match pattern in the match option. For each matching node, the string value of the computed hash is used in the output (if more than one node matches, the same hash value is used in each match). Nodes that do not match are copied without change.

If the expression given in the match option matches an attribute, the hash is used as the new value of the attribute in the output. If the attribute is named “xml:base”, the base URI of the element must also be amended accordingly.

If the expression matches any other kind of node, the entire node (and not just its contents) is replaced by the hash.

The p:http-request step provides for interaction with resources over HTTP or related protocols. The input document provided on the source port specifies a request by a single c:request element. This element specifies the method, resource, and other request properties as well as possibly including an entity body (content) for the request.

<p:declare-step type="p:http-request">
     <p:input port="source" content-types="*/*"/>
     <p:output port="result" sequence="true" content-types="*/*"/>
     <p:option name="serialization" as="map(xs:string,xs:anyAtomicValue)"/>
</p:declare-step>

The serialization option is provided to control the serialization of any content which is sent as part of the request. The effect of these options is as specified in [XProc 3.0]. See Section 2.12.3, “Request Entity body conversion” for a discussion of when serialization occurs in constructing a request.

It is a dynamic error (err:XC0040) if the document element of the document that arrives on the source port is not c: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>

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>

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

<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 step makes a verbatim copy of its input available on its output.

<p:declare-step type="p:identity">
     <p:input port="source" content-types="*/*" sequence="true"/>
     <p:output port="result" sequence="true" content-types="*/*"/>
</p:declare-step>

If the implementation supports passing PSVI annotations between steps, the p:identity step must preserve any annotations that appear in the input.

The p:in-scope-names step exposes all of the in-scope variables and options as a set of parameters in a c:param-set document.

<p:declare-step type="p:in-scope-names">
     <p:output port="result" primary="false" content-types="application/xml"/>
</p:declare-step>

Each in-scope variable and option is converted into a c:param element. The resulting c:param elements are wrapped in a c:param-set and the parameter set document is written to the result port. The order in which c:param elements occur in the c:param-set is implementation-dependent.

For consistency and user convenience, if any of the variables or options have names that are in a namespace, the namespace attribute on the c:param element must be used. Each name must be an NCName.

The base URI of the output document is the URI of the pipeline document that contains the step.

For consistency with the p:parameters step, the result port is not primary.

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
                name="main" version="1.0">
<p:output port="result">
  <p:pipe step="vars" port="result"/>
</p:output>

<p:option name="username" required="true"/>
<p:option name="password" required="true"/>
<p:variable name="host" select="'http://example.com/'"/>

<p:in-scope-names name="vars"/>

</p:declare-step>

<c:param-set xmlns:c="http://www.w3.org/ns/xproc-step">
  <c:param name="username" namespace="" value="user"/>
  <c:param name="host" namespace="" value="http://example.com/"/>
  <c:param name="password" namespace="" value="pass"/>
</c:param-set>

The p:insert step inserts the insertion port's document into the source port's document relative to the matching elements in the source port's document.

<p:declare-step type="p:insert">
     <p:input port="source" primary="true" content-types="application/xml text/xml */*+xml"/>
     <p:input port="insertion" sequence="true" content-types="application/xml text/* */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" select="'/*'" as="xs:string"/>         <!-- XSLTMatchPattern -->
     <p:option name="position" required="true" as="xs:token"/>     <!-- "first-child" | "last-child" | "before" | "after" -->
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if that pattern matches an attribute or a namespace node. Multiple matches are allowed, in which case multiple copies of the insertion documents will occur. If no elements match, then the document is unchanged.

The value of the position option must be an NMTOKEN in the following list:

It is a dynamic error (err:XC0025) if the match pattern matches anything other than an element or a document node and the value of the position option is “first-child” or “last-child”. It is a dynamic error (err:XC0024) if the match pattern matches a document node and the value of the position is “before” or “after”.

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 port, the result will be the same as the source.

The p:label-elements step generates a label for each matched element and stores that label in the specified attribute.

<p:declare-step type="p:label-elements">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="attribute" select="'xml:id'" as="xs:QName"/>  
     <p:option name="attribute-prefix" as="xs:NCName"/>            
     <p:option name="attribute-namespace" as="xs:anyURI"/>         
     <p:option name="label" select="'concat("_",$p:index)'" as="xs:string"/><!-- XPathExpression -->
     <p:option name="match" select="'*'" as="xs:string"/>          <!-- XSLTMatchPattern -->
     <p:option name="replace" select="'true'" as="xs:boolean"/>    
</p:declare-step>

The value of the attribute option must be a QName. If the lexical value does not contain a colon, then the attribute-namespace may be used to specify the namespace of the attribute name. In that case, the attribute-prefix may be specified to suggest a prefix for the attribute name. It is a dynamic error (err:XD0034) to specify a new namespace or prefix if the lexical value of the specified name contains a colon.

The value of the label option is an XPath expression used to generate the value of the attribute label.

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if that expression matches anything other than element nodes.

The value of the replace must be a boolean value and is used to indicate whether existing attribute values are replaced.

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 option and the string value of result of evaluating the expression. If the attribute already exists on the matched element, the value is replaced with the string value only if the replace option has the value of true.

If this step is used to add or change the value of an attribute named “xml:base”, the base URI of the element must also be amended accordingly.

An implementation must bind the variable “p:index” in the static context of each evaluation of the XPath expression to the position of the element in the sequence of matched elements. In other words, the first element (in document order) matched gets the value “1”, the second gets the value “2”, the third, “3”, etc.

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 step has no inputs but produces as its result a document (or documents) specified by an IRI. If it is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:load in the case of a syntactic shortcut value).

<p:declare-step type="p:load">
     <p:output port="result" sequence="true" content-types="*/*"/>
     <p:option name="href" required="true" as="xs:anyURI"/>        
     <p:option name="parameters" as="map(xs:QName,item())"/>       
     <p:option name="document-properties" as="map(xs:QName, item())"/>
</p:declare-step>

The document or documents identified by the href URI are loaded and returned. If the URI protocol supports redirection, then redirects must be followed. Implementations should support “globbing”. See Appendix B, URI globbing.

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

The behavior of this step depends on the content type of the document or documents loaded. The content type of each document is determined as follows:

The parameters map contains additional, optional parameters that may influence the way that content is loaded. The interpretation of this map varies according to the content type. Parameter names that are in no namespace are treated as strings using only the local-name where appropriate.

Broadly speaking, there are four categories of data that might be loaded: XML, text, JSON, and “other” binary data.

The p:make-absolute-uris step makes an element or attribute's value in the source document an absolute IRI value in the result document.

<p:declare-step type="p:make-absolute-uris">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" required="true" as="xs:string"/>       <!-- XSLTMatchPattern -->
     <p:option name="base-uri" as="xs:anyURI"/>                    
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if the pattern matches anything other than element or attribute nodes.

The value of the base-uri option must be an anyURI. It is interpreted as an IRI reference. If it is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:make-absolute-uris in the case of a syntactic shortcut value).

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 option is specified. When the base-uri option is specified, the option value is used as the base URI regardless of any contextual base URI value in the document. This option value is resolved against the base URI of the p:option element used to set the option.

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.

The p:namespace-rename step renames any namespace declaration or use of a namespace in a document to a new IRI value.

<p:declare-step type="p:namespace-rename">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="from" as="xs:anyURI"/>                        
     <p:option name="to" as="xs:anyURI"/>                          
     <p:option name="apply-to" select="'all'" as="xs:token"/>      <!-- "all" | "elements" | "attributes" -->
</p:declare-step>

The value of the from option must be an anyURI. It should be either empty or absolute, but will not be resolved in any case.

The value of the to option must be an anyURI. It should be empty or absolute, but will not be resolved in any case.

The value of the apply-to option must be one of “all”, “elements”, or “attributes”. If the value is “elements”, only elements will be renamed, if the value is “attributes”, only attributes will be renamed, if the value is “all”, both elements and attributes will be renamed.

It is a dynamic error (err:XC0014) 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.

If the value of the from option is the same as the value of the to option, the input is reproduced unchanged on the output. Otherwise, namespace bindings, namespace attributes and element and attribute names are changed as follows:

The p:pack step merges two document sequences in a pair-wise fashion.

<p:declare-step type="p:pack">
     <p:input port="source" content-types="application/xml text/xml */*+xml" sequence="true" primary="true"/>
     <p:input port="alternate" sequence="true" content-types="application/xml"/>
     <p:output port="result" sequence="true"/>
     <p:option name="wrapper" required="true" as="xs:QName"/>      
     <p:option name="wrapper-prefix" as="xs:NCName"/>              
     <p:option name="wrapper-namespace" as="xs:anyURI"/>           
</p:declare-step>

The value of the wrapper option must be a QName. If the lexical value does not contain a colon, then the wrapper-namespace may be used to specify the namespace of the wrapper. In that case, the wrapper-prefix may be specified to suggest a prefix for the wrapper element. It is a dynamic error (err:XD0034) to specify a new namespace or prefix if the lexical value of the specified name contains a colon.

The step takes each pair of documents, in order, one from the source port and one from the alternate port, wraps them with a new element node whose QName is the value specified in the wrapper option, and writes that element to the result port as a document.

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.

The p:parameters step exposes a set of parameters as a c:param-set document.

<p:declare-step type="p:parameters">
     <p:output port="result" content-types="application/xml"/>
     <p:option name="parameters" as="map(xs:QName,item())"/>       
</p:declare-step>

Each parameter in the parameters map is converted into a c:param element. The resulting c:param elements are wrapped in a c:param-set and the parameter set document is written to the result port. The order in which c:param elements occur in the c:param-set is implementation-dependent.

For consistency and user convenience, if any of the parameters have names that are in a namespace, the namespace attribute on the c:param element must be used. Each name must be an NCName.

The base URI of the output document is the URI of the pipeline document that contains the step.

The p:rename step renames elements, attributes, or processing-instruction targets in a document.

<p:declare-step type="p:rename">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" select="'/*'" as="xs:string"/>         <!-- XSLTMatchPattern -->
     <p:option name="new-name" required="true" as="xs:QName"/>     
     <p:option name="new-prefix" as="xs:NCName"/>                  
     <p:option name="new-namespace" as="xs:anyURI"/>               
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if the pattern matches anything other than element, attribute or processing instruction nodes.

The value of the new-name option must be a QName. If the lexical value does not contain a colon, then the new-namespace may be used to specify the namespace of the new name. In that case, the new-prefix may be specified to suggest a prefix for the new name. It is a dynamic error (err:XD0034) to specify a new namespace or prefix if the lexical value of the specified name contains a colon.

Each element, attribute, or processing-instruction in the input matched by the match pattern specified in the match option is renamed in the output to the name specified by the new-name option.

If the match option matches an attribute and if the element on which it occurs already has an attribute whose expanded name is the same as the expanded name of the specified new-name, then the results is as if the current attribute named “new-name” was deleted before renaming the matched attribute.

With respect to attributes named “xml:base”, the following semantics apply: renaming an from “xml:base” to something else has no effect on the underlying base URI of the element; however, if an attribute is renamed from something else to “xml:base”, the base URI of the element must also be amended accordingly.

If the pattern matches processing instructions, then it is the processing instruction target that is renamed. It is a dynamic error (err:XC0013) if the pattern matches a processing instruction and the new name has a non-null namespace.

The p:replace step replaces matching nodes in its primary input with the document element of the replacement port's document.

<p:declare-step type="p:replace">
     <p:input port="source" primary="true" content-types="application/xml text/xml */*+xml"/>
     <p:input port="replacement" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" required="true" as="xs:string"/>       <!-- XSLTMatchPattern -->
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if that pattern matches anything other than element, text, processing-instruction, or comment nodes. Multiple matches are allowed, in which case multiple copies of the replacement document will occur.

Every node in the primary input matching the specified pattern is replaced in the output is replaced by the document element of the replacement document. Only non-nested matches are replaced. That is, once a node is replaced, its descendants cannot be matched.

The p:set-attributes step sets attributes on matching elements.

<p:declare-step type="p:set-attributes">
     <p:input port="source" primary="true" content-types="application/xml text/xml */*+xml"/>
     <p:input port="attributes" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" select="'/*'" as="xs:string"/>         <!-- XSLTMatchPattern -->
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if that pattern matches anything other than element nodes.

Each attribute on the document element of the document that appears on the attributes port is copied to each element that matches the match expression.

If an attribute with the same name as one of the attributes to be copied already exists, the value specified on the attribute port's document is used. The result port of this step produces a copy of the source port's document with the matching elements' attributes modified.

The matching elements are specified by the match pattern in the match option. All matching elements are processed. If no elements match, the step will not change any elements.

This step must not copy namespace declarations. If the attributes copied from the attributes use namespaces, prefixes, or prefixes bound to different namespaces, the document produced on the result output port will require namespace fixup.

If an attribute named xml:base is added or changed, the base URI of the element must also be amended accordingly.

The p:set-properties step sets document properties on the source document.

<p:declare-step type="p:set-properties">
     <p:input port="source" content-types="*/*"/>
     <p:output port="result" content-types="*/*"/>
     <p:option name="properties" required="true" as="map(xs:QName,item())"/>
     <p:option name="merge" default="false()" as="xs:boolean"/>    
</p:declare-step>

The document properties of the document on the source port are augmented with the values specified in the properties option. The document produced on the result port has the same representation but the adjusted property values.

If the merge option is true, then the supplied properties are added to the existing properties. If it is false, the document’s properties are replaced by the new set.

It is a dynamic error (err:XC0069) if the properties map contains a key equal to the string “content-type”.

The p:sink step accepts a sequence of documents and discards them. It has no output.

<p:declare-step type="p:sink">
     <p:input port="source" content-types="*/*" sequence="true"/>
</p:declare-step>

The p:split-sequence step accepts a sequence of documents and divides it into two sequences.

<p:declare-step type="p:split-sequence">
     <p:input port="source" content-types="application/xml text/xml */*+xml" sequence="true"/>
     <p:output port="matched" sequence="true" primary="true" content-types="application/xml"/>
     <p:output port="not-matched" sequence="true" content-types="application/xml"/>
     <p:option name="initial-only" select="false()" as="xs:boolean"/>
     <p:option name="test" required="true" as="xs:string"/>        <!-- XPathExpression -->
</p:declare-step>

The value of the test option must be an XPathExpression.

The XPath expression in the test option is applied to each document in the input sequence. If the effective boolean value of the expression is true, the document is copied to the matched port; otherwise it is copied to the not-matched port.

If the initial-only option is true, then when the first document that does not satisfy the test expression is encountered, it and all the documents that follow it are written to the not-matched port. In other words, it only writes the initial series of matched documents (which may be empty) to the matched port. All other documents are written to the not-matched port, irrespective of whether or not they match.

The XPath context for the test option changes over time. For each document that appears on the source port, the expression is evaluated with that document as the context document. The context position (position()) is the position of that document within the sequence and the context size (last()) is the total number of documents in the sequence.

If the implementation supports passing PSVI annotations between steps, the p:split-sequence step must preserve any annotations that appear in the input.

The p:store step stores (a possibly serialized version of) its input to a URI. This step outputs a reference to the location of the stored document.

<p:declare-step type="p:store">
     <p:input port="source" content-types="*/*"/>
     <p:output port="result" content-types="application/xml" primary="true"/>
     <p:option name="href" required="true" as="xs:anyURI"/>        
     <p:option name="serialization" as="map(xs:string,xs:anyAtomicValue)"/>
</p:declare-step>

The value of the href option must be an anyURI. If it is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:store in the case of a syntactic shortcut value).

The step attempts to store the XML document to the specified URI. It is a dynamic error (err:XC0050) if the URI scheme is not supported or the step cannot store to the specified location.

The output of this step is a document containing a single c:result element whose content is the absolute URI of the document stored by the step.

The serialization option is provided to control the serialization of content when it is stored. Serialization is described in [XProc 3.0].

The p:string-replace step matches nodes in the document provided on the source port and replaces them with the string result of evaluating an XPath expression.

<p:declare-step type="p:string-replace">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" required="true" as="xs:string"/>       <!-- XSLTMatchPattern -->
     <p:option name="replace" required="true" as="xs:string"/>     <!-- XPathExpression -->
</p:declare-step>

The value of the match option must be an XSLTMatchPattern.

The value of the replace option must be an XPathExpression.

The matched nodes are specified with the match pattern in the match option. For each matching node, the XPath expression provided by the replace option is evaluated with the matching node as the XPath context node. The string value of the result is used in the output. Nodes that do not match are copied without change.

If the expression given in the match option matches an attribute, the string value of the replace expression is used as the new value of the attribute in the output. If the attribute is named “xml:base”, the base URI of the element must also be amended accordingly.

If the expression matches any other kind of node, the entire node (and not just its contents) is replaced by the string value of the replace expression.

The p:unescape-markup step takes the string value of the document element and parses the content as if it was a Unicode character stream containing serialized XML. The output consists of the same document element with children that result from the parse. This is the reverse of the p:escape-markup step.

<p:declare-step type="p:unescape-markup">
     <p:input port="source" content-types="application/xml text/xml */*+xml text/*"/>
     <p:output port="result" content-types="application/xml text/xml */*+xml"/>
     <p:option name="namespace" as="xs:anyURI"/>                   
     <p:option name="content-type" select="'application/xml'" as="xs:string"/>
     <p:option name="encoding" as="xs:string"/>                    
     <p:option name="charset" as="xs:string"/>                     
</p:declare-step>

The value of the namespace option must be an anyURI. It should be absolute, but will not be resolved.

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 option specifies a default namespace. Elements that are in no namespace in the unescaped content will be placed into this namespace unless there is an in-scope namespace declaration that specifies a different namespace (or explicitly undeclares the default namespace).

The content-type option may be used to specify an alternate content type for the string value. An implementation may use a different parser to produce XML content depending on the specified content-type. For example, an implementation might provide an HTML to XHTML parser (e.g. [HTML Tidy] or [TagSoup]) for the content type 'text/html'.

All implementations must support the content type application/xml, and must use a standard XML parser for it. It is a dynamic error (err:XC0051) if the content-type specified is not supported by the implementation. Behavior of p:unescape-markup for content-types other than application/xml is implementation-defined.

The encoding option specifies how the data is encoded. All implementations must support the base64 encoding (and the absence of an encoding option, which implies that the content is plain Unicode text). It is a dynamic error (err:XC0052) if the encoding specified is not supported by the implementation.

If an encoding is specified, a charset may also be specified. The character set may be specified as a parameter on the content-type or via the separate charset option. If it is specified in both places, the value of the charset option must be used.

If the specified encoding is base64, then the character set must be specified. It is a dynamic error (err:XC0010) 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.

The octet-stream that results from decoding the text must be interpreted using the character encoding named by the value of the charset option to produce a sequence of Unicode characters to parse.

If no encoding is specified, the character set is ignored, irrespective of where it was specified.

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 step replaces matched elements with their children.

<p:declare-step type="p:unwrap">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" select="'/*'" as="xs:string"/>         <!-- XSLTMatchPattern -->
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if that pattern matches anything other than element nodes.

Every element in the source document that matches the specified match pattern is replaced by its children, effectively “unwrapping” the children from their parent. Non-element nodes and unmatched elements are passed through unchanged.

This step produces a single document; if the document element is unwrapped, the result might not be well-formed XML.

The p:uuid step generates a [UUID] and injects it into the source document.

<p:declare-step type="p:uuid">
     <p:input port="source" primary="true" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="match" select="'/*'" as="xs:string"/>         <!-- XSLTMatchPattern -->
     <p:option name="version" as="xs:integer"/>                    
</p:declare-step>

The value of the match option must be an XSLTMatchPattern. The value of the version option must be an integer.

If the version is specified, that version of UUID must be computed. It is a dynamic error (err:XC0060) if the processor does not support the specified version of the UUID algorithm. If the version is not specified, the version of UUID computed is implementation-defined.

Implementations must support version 4 UUIDs. Support for other versions of UUID, and the mechanism by which the necessary inputs are made available for computing other versions, is implementation-defined.

The matched nodes are specified with the match pattern in the match option. For each matching node, the generated UUID is used in the output (if more than one node matches, the same UUID is used in each match). Nodes that do not match are copied without change.

If the expression given in the match option matches an attribute, the UUID is used as the new value of the attribute in the output. If the attribute is named “xml:base”, the base URI of the element must also be amended accordingly.

If the expression matches any other kind of node, the entire node (and not just its contents) is replaced by the UUID.

The p:wrap-sequence step accepts a sequence of documents and produces either a single document or a new sequence of documents.

<p:declare-step type="p:wrap-sequence">
     <p:input port="source" content-types="application/xml */*+xml text/*" sequence="true"/>
     <p:output port="result" sequence="true" content-types="application/xml"/>
     <p:option name="wrapper" required="true" as="xs:QName"/>      
     <p:option name="wrapper-prefix" as="xs:NCName"/>              
     <p:option name="wrapper-namespace" as="xs:anyURI"/>           
     <p:option name="group-adjacent" as="xs:string"/>              <!-- XPathExpression -->
</p:declare-step>

The value of the wrapper option must be a QName. If the lexical value does not contain a colon, then the wrapper-namespace may be used to specify the namespace of the wrapper. In that case, the wrapper-prefix may be specified to suggest a prefix for the wrapper element. It is a dynamic error (err:XD0034) to specify a new namespace or prefix if the lexical value of the specified name contains a colon.

The value of the group-adjacent option must be an XPathExpression.

In its simplest form, p:wrap-sequence takes a sequence of documents and produces a single, new document by placing each document in the source sequence inside a new document element as sequential siblings. The name of the document element is the value specified in the wrapper option.

The group-adjacent option can be used to group adjacent documents. The XPath context for the group-adjacent option changes over time. For each document that appears on the source port, the expression is evaluated with that document as the context document. The context position (position()) is the position of that document within the sequence and the context size (last()) is the total number of documents in the sequence. Whenever two or more sequentially adjacent documents have the same “group adjacent” value, they are wrapped together in a single wrapper element.

The p:wrap step wraps matching nodes in the source document with a new parent element.

<p:declare-step type="p:wrap">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="wrapper" required="true" as="xs:QName"/>      
     <p:option name="wrapper-prefix" as="xs:NCName"/>              
     <p:option name="wrapper-namespace" as="xs:anyURI"/>           
     <p:option name="match" required="true" as="xs:string"/>       <!-- XSLTMatchPattern -->
     <p:option name="group-adjacent" as="xs:string"/>              <!-- XPathExpression -->
</p:declare-step>

The value of the wrapper option must be a QName. If the lexical value does not contain a colon, then the wrapper-namespace may be used to specify the namespace of the wrapper. In that case, the wrapper-prefix may be specified to suggest a prefix for the wrapper element. It is a dynamic error (err:XD0034) to specify a new namespace or prefix if the lexical value of the specified name contains a colon.

The value of the match option must be an XSLTMatchPattern. It is a dynamic error (err:XC0023) if the pattern matches anything other than document, element, text, processing instruction, and comment nodes.

The value of the group-adjacent option must be an XPathExpression.

If the node matched is the document node (match="/"), the result is a new document where the document element is a new element node whose QName is the value specified in the wrapper option. That new element contains copies of all of the children of the original document node.

When the match pattern does not match the document node, every node that matches the specified match pattern is replaced with a new element node whose QName is the value specified in the wrapper option. The content of that new element is a copy of the original, matching node. The p:wrap step performs a "deep" wrapping, the children of the matching node and their descendants are processed and wrappers are added to all matching nodes.

The group-adjacent option can be used to group adjacent matching nodes in a single wrapper element. The specified XPath expression is evaluated for each matching node with that node as the XPath context node. Whenever two or more adjacent matching nodes have the same “group adjacent” value, they are wrapped together in a single wrapper element.

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:www-form-urldecode step decodes a x-www-form-urlencoded string into an XML representation.

<p:declare-step type="p:www-form-urldecode">
     <p:output port="result" content-types="application/xml"/>
     <p:option name="value" required="true" as="xs:string"/>       
</p:declare-step>

The value option is interpreted as a string of parameter values encoded using the x-www-form-urlencoded algorithm. Each name/value pair is written in a c:param element. The entire set of parameters is written (as a c:param-set) on the result output port.

It is a dynamic error (err:XC0037) if the value provided is not a properly x-www-form-urlencoded value. It is a dynamic error (err:XC0061) if the name of any encoded parameter name is not a valid xs:NCName. In other words, this step can only decode simple name/value pairs where the names do not contain colons or any characters that cannot be used in XML names.

The order of the c:param elements in the result is the same as the order of the encoded parameters, reading from left to right.

If any parameter name occurs more than once in the encoded string, the resulting parameter set will contain a c:param for each instance.

The p:www-form-urlencode step encodes a set of parameter values as a x-www-form-urlencoded string and injects it into the source document.

<p:declare-step type="p:www-form-urlencode">
     <p:input port="source" primary="true" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml"/>
     <p:option name="parameters" as="map(xs:QName,item())"/>       
     <p:option name="match" required="true" as="xs:string"/>       <!-- XSLTMatchPattern -->
</p:declare-step>

The value of the match option must be an XSLTMatchPattern.

The set of parameters is encoded as a single x-www-form-urlencoded string of name/value pairs. When parameters are encoded into name/value pairs, only the local name of each parameter is used. The namespace name is ignored and no prefix or colon appears in the name.

The order of the parameters is is implementation-dependent.

The matched nodes are specified with the match pattern in the match option. For each matching node, the encoded string is used in the output. Nodes that do not match are copied without change.

If the expression given in the match option matches an attribute, the encoded string is used as the new value of the attribute in the output. If the expression matches any other kind of node, the entire node (and not just its contents) is replaced by the encoded string.

The p:xinclude step applies [XInclude] processing to the source document.

<p:declare-step type="p:xinclude">
     <p:input port="source" content-types="application/xml text/xml */*+xml"/>
     <p:output port="result" content-types="application/xml text/xml */*+xml"/>
     <p:option name="fixup-xml-base" select="'false'" as="xs:boolean"/>
     <p:option name="fixup-xml-lang" select="'false'" as="xs:boolean"/>
</p:declare-step>

The value of the fixup-xml-base option must be a boolean. If it is true, base URI fixup will be performed as per [XInclude].

The value of the fixup-xml-lang option must be a boolean. If it is true, language fixup will be performed as per [XInclude].

The included documents are located with the base URI of the input document and are not provided as input to the step.

It is a dynamic error (err:XC0029) if an XInclude error occurs during processing.

The p:xslt step applies an [XSLT 1.0] or [XSLT 2.0] stylesheet to a document.

<p:declare-step type="p:xslt">
     <p:input port="source" content-types="application/xml text/xml */*+xml" sequence="true" primary="true"/>
     <p:input port="stylesheet" content-types="application/xml text/xml */*+xml"/>
     <p:option name="parameters" as="map(xs:QName,item())"/>       
     <p:output port="result" primary="true" sequence="true" content-types="*/*"/>
     <p:output port="secondary" sequence="true"/>
     <p:option name="initial-mode" as="xs:QName"/>                 
     <p:option name="template-name" as="xs:QName"/>                
     <p:option name="output-base-uri" as="xs:anyURI"/>             
     <p:option name="version" as="xs:string"/>                     
</p:declare-step>

If present, the value of the initial-mode option must be a QName.

If present, the value of the template-name option must be a QName.

If present, the value of the output-base-uri option must be an anyURI. If it is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:xslt in the case of a syntactic shortcut value).

If the step specifies a version, then that version of XSLT must be used to process the transformation. It is a dynamic error (err:XC0038) if the specified version is not available. If the step does not specify a version, the implementation may use any version it has available and may use any means to determine what version to use, including, but not limited to, examining the version of the stylesheet.

The XSLT stylesheet provided on the stylesheet port is applied to the document on the source port. Any parameters passed in the parameters option are used to define top-level stylesheet parameters. The primary result document of the transformation, if there is one, appears on the result port. At most one document can appear on the result port. All other result documents appear on the secondary port. The order in which result documents appear on the secondary port is implementation-dependent. If XSLT 1.0 is used, an empty sequence of documents must appear on the secondary port.

If a sequence of documents is provided on the source port, the first document is used as the primary input document. The whole sequence is also the default collection. If no documents are provided on the source port, the primary input document is undefined and the default collection is empty. It is a dynamic error (err:XC0039) if a sequence of documents (including an empty sequence) is provided to an XSLT 1.0 step.

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 instruction with a terminate attribute value of “yes”. How XSLT message termination errors are reported to the XProc processor is implementation-dependent.

The invocation of the transformation is controlled by the initial-mode and template-name options that set the initial mode and/or named template in the XSLT transformation where processing begins. It is a dynamic error (err:XC0056) if the specified initial mode or named template cannot be applied to the specified stylesheet.

The output-base-uri option sets the context's output base URI per the XSLT 2.0 specification, otherwise the base URI of the result document is the base URI of the first document in the source port's sequence. If the value of the output-base-uri option is not absolute, it will be resolved using the base URI of its p:option element. An XSLT 1.0 step should use the value of the output-base-uri as the base URI of its output, if the option is specified.

If XSLT 2.0 is used, the outputs of this step may include PSVI annotations.

The static and initial dynamic contexts of the XSLT processor are the contexts defined in the step XPath context with the following adjustments.

The dynamic context is augmented as follows: