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 selection 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-steptype="p:add-attribute">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern -->
     <p:optionname="attribute-name"required="true"as="xs:QName"/>
     <p:optionname="attribute-value"required="true"as="xs:string"/>
</p:declare-step>

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

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-steptype="p:add-xml-base">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="all"as="xs:boolean"select="false()"/>       
     <p:optionname="relative"as="xs:boolean"select="true()"/>   
</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 bothtrue.

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

The p:archive step outputs on its result port an archive (usually binary) document, for instance a ZIP file. A specification of the contents of the archive may be specified in a manifest XML document on the manifest port. The step produces a report on the report port, which contains the manifest, amended with additional information about the archiving.

<p:declare-steptype="p:archive">
     <p:inputport="source"primary="true"content-types="any"sequence="true"/>
     <p:inputport="manifest"content-types="xml"sequence="true">
          <p:empty/>
     </p:input>
     <p:inputport="archive"content-types="any"sequence="true">
          <p:empty/>
     </p:input>
     <p:outputport="result"primary="true"content-types="any"sequence="false"/>
     <p:outputport="report"content-types="application/xml"sequence="false"/>
     <p:optionname="format"as="xs:QName"select="'zip'"/>        
     <p:optionname="relative-to"as="xs:anyURI?"/>                
     <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
</p:declare-step>

The p:archive step can perform several different operations on archives. The most common one will likely be creating an archive, but it could also, depending on the archive format, provide services like update, freshen or even merge. The only format implementations must support is [ZIP]. The list of formats supported by the p:archive step is implementation-defined.

The p:archive step has the following input ports:

The p:archive step has the following output ports:

The p:archive step has the following options:

The format of the archive is determined as follows:

It is a dynamic error (err:XC0085) if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.

The p:archive-manifest creates an XML manifest file describing the contents of the archive appearing on its source port.

<p:declare-steptype="p:archive-manifest">
     <p:inputport="source"primary="true"content-types="any"sequence="false"/>
     <p:outputport="result"primary="true"content-types="application/xml"sequence="false"/>
     <p:optionname="format"as="xs:QName?"/>                      
     <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
     <p:optionname="relative-to"as="xs:anyURI?"/>                
     <p:optionname="override-content-types"as="array(array(xs:string))?"/>
</p:declare-step>

The p:archive-manifest step inspects the archive appearing on its source port and outputs a manifest describing the contents of the archive on its result port.

The format of the archive is determined as follows:

It is a dynamic error (err:XC0085) if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.

The parameters option can be used to supply parameters to control the archive manifest generation. 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.

The relative-to option, when present, is used in creating the value of the manifest's c:entry/@href attribute. If the option is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or the step in case of a syntactic shortcut value). It is a dynamic error (err:XD0064) if the base URI is not both absolute and valid according to [RFC 3986].

The generated manifest has the format as described in Section 2.3.1, “The archive manifest”. Implementations must supply an c:entry element and its name and content-type attributes for every entry in the archive. The value of the generated manifest's c:entry/@href attribute will be determined in the same way as a base URI of an unarchived document by Section 2.38, “p:unarchive”. It is a dynamic error (err:XC0120) if the relative-to option is not present and the document on the source port does not have a base URI. Additional information provided for entries in p:archive-manifest is implementation-defined.

The p:cast-content-type step creates a new document by changing the media type of its input. If the value of the content-type option and the current media type of the document on source port are the same, this document will appear unchanged on result port.

<p:declare-steptype="p:cast-content-type">
     <p:inputport="source"content-types="any"/>
     <p:outputport="result"content-types="any"/>
     <p:optionname="content-type"required="true"as="xs:string"/>
     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
</p:declare-step>

The input document is transformed from one media type to another. It is a dynamic error (err:XD0079) if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”. It is a dynamic error (err:XC0071) if the p:cast-content-type step cannot perform the requested cast.

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.

The p:compare step compares two documents for equality.

<p:declare-steptype="p:compare">
     <p:inputport="source"primary="true"content-types="any"/>
     <p:inputport="alternate"content-types="any"/>
     <p:outputport="result"content-types="application/xml"/>
     <p:outputport="differences"content-types="any"sequence="true"/>
     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
     <p:optionname="method"as="xs:QName?"/>                      
     <p:optionname="fail-if-not-equal"as="xs:boolean"select="false()"/>
</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:comparemust support the deep-equalmethod; 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:compress step serializes the document appearing on its source port and outputs a compressed version of this on its result port.

<p:declare-steptype="p:compress">
     <p:inputport="source"primary="true"content-types="any"sequence="false"/>
     <p:outputport="result"primary="true"content-types="any"sequence="false"/>
     <p:optionname="format"as="xs:QName"select="'gzip'"/>       
     <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
     <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
</p:declare-step>

The p:compress step first serializes the document appearing on its source. It then compresses the outcome of this serialization and outputs the result on its result port.

The p:compress step has the following options:

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-steptype="p:count">
     <p:inputport="source"content-types="any"sequence="true"/>
     <p:outputport="result"content-types="application/xml"/>
     <p:optionname="limit"as="xs:integer"select="0"/>           
</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 selection pattern from the source input document and produces the resulting document, with the deleted items removed, on the result port.

<p:declare-steptype="p:delete">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="text xml html"/>
     <p:optionname="match"required="true"as="xs:string"/>       <!-- XSLTSelectionPattern -->
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern. A selection 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.

It is a dynamic error (err:XC0023) if the match option matches the document node.

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:error step generates a dynamic error using the input provided to the step.

<p:declare-steptype="p:error">
     <p:inputport="source"sequence="true"content-types="text xml"/>
     <p:outputport="result"sequence="true"content-types="any"/>
     <p:optionname="code"required="true"as="xs:QName"/>         
</p:declare-step>

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:with-input port="source"> <message>The document element is unknown.</message> </p:with-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:filter step selects portions of the source document based on a (possibly dynamically constructed) XPath select expression.

<p:declare-steptype="p:filter">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"sequence="true"content-types="text xml html"/>
     <p:optionname="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-steptype="p:hash">
     <p:inputport="source"primary="true"content-types="xml html"/>
     <p:outputport="result"content-types="text xml html"/>
     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
     <p:optionname="value"required="true"as="xs:string"/>       
     <p:optionname="algorithm"required="true"as="xs:QName"/>    
     <p:optionname="match"as="xs:string"select="'/*/node()'"/>  <!-- XSLTSelectionPattern -->
     <p:optionname="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], [RFC 1321], 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 XSLTSelectionPattern.

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 selection 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 document node is matched, the entire document is replaced by a text node with the hash. What appears on port result is a text document with the text node wrapped in a document node.

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 allows authors to interact with resources over HTTP or related protocols. Implementations must support the http and https protocols. (Implementors are encouraged to support as many protocols as practical. In particular, pipeline authors may attempt to use p:http-request to load documents with computed URIs using the file: scheme.)

<p:declare-steptype="p:http-request">
     <p:inputport="source"content-types="any"sequence="true"/>
     <p:outputport="result"primary="true"content-types="any"sequence="true"/>
     <p:outputport="report"content-types="application/json"/>
     <p:optionname="href"as="xs:anyURI"required="true"/>        
     <p:optionname="method"as="xs:string?"select="'GET'"/>      
     <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
     <p:optionname="headers"as="map(xs:string, xs:string)?"/>    
     <p:optionname="auth"as="map(xs:string, item()+)?"/>         
     <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
     <p:optionname="assert"as="xs:string"select="'.?status-code lt 400'"/>
</p:declare-step>

The p:http-request step performs the HTTP request specified by the method option against the URI specified in the href option. In simple cases, for example, a GET request on an unauthenticated URI, nothing else is necessary to form a complete request.

If the method, for example, POST, supports a body, the request body is constructed using the document(s) appearing on the source port. For the convenience of pipeline authors, documents may appear on the source port even when the request method (such as GET or HEAD) does not define the semantics of a payload. If the semantics are undefined, the documents are ignored when constructing the request unless the parameters option specifies “send-body-anyway” as true().

The headers for the request come from the headers option (see below). If exactly one document appears on the source port, its document properties also contribute to the overall request headers.

The response from the HTTP request appears on the result and report ports. Any documents contained in the response body will appear on the result port. Each document in the response will be parsed according to its content-type (but see “override-content-type” in the parameters option). Details about the outcome of the request will appear as a map on the report port. The map will always contain “status-code” (an xs:integer) and “headers” (a map(xs:string, xs:string)). The header map may be empty. Header names are converted to lowercase.

The p:http-request step has the following options:

The p:identity step makes a verbatim copy of its input available on its output.

<p:declare-steptype="p:identity">
     <p:inputport="source"sequence="true"content-types="any"/>
     <p:outputport="result"sequence="true"content-types="any"/>
</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: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-steptype="p:insert">
     <p:inputport="source"primary="true"content-types="xml html"/>
     <p:inputport="insertion"sequence="true"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern -->
     <p:optionname="position"as="xs:token"values="('first-child','last-child','before','after')"select="'after'"/>
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern. 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 selection 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 selection 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:json-join step joins the sequence of documents on port source into a single JSON document (an array) appearing on port result. If the sequence on port source is empty, the empty sequence is returned on port result.

<p:declare-steptype="p:json-join">
     <p:inputport="source"sequence="true"content-types="any"/>
     <p:outputport="result"content-types="application/json"/>
     <p:optionname="flatten-to-depth"as="xs:string?"select="'0'"/>
</p:declare-step>

The step inspects the documents on port source in turn to create the resulting array:

The option flatten-to-depth controls whether and to which depth members of an array appearing on port source are flattened. It is a dynamic error (err:XC0119) if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer. An integer value of 0, which is the default, means that no flattening takes place, so the array appearing on port source will be contained as an array in the resulting array. An integer value of 1 means that an array on port source is flattened, i.e. the members of that array will appear as individual members in the resulting array. Any value greater than 1 means that the flattening is applied recursively to arrays in arrays up to the given depth. A value of “unbounded” means that all arrays in arrays will be flattened. As a consequence, the resulting array appearing on port result will not have any arrays as members.

The p:json-merge step merges the sequence of appearing on port source into a single JSON object appearing on port result. If the sequence on port source is empty, the empty sequence is returned on port result.

<p:declare-steptype="p:json-merge">
     <p:inputport="source"sequence="true"content-types="any"/>
     <p:outputport="result"content-types="application/json"/>
     <p:optionname="duplicates"as="xs:token"values="('reject', 'use-first', 'use-last', 'use-any', 'combine')"select="'use-first'"/>
     <p:optionname="key"as="xs:string"select="'concat("_",$p:index)'"/><!-- XPathExpression -->
</p:declare-step>

The step inspects the documents on port source in turn to create the resulting map:

An implementation must bind the variable “p:index” in the static context of each evaluation of the XPath expression to the position of the document in the sequence of documents on port source, starting with “1”.

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

<p:declare-steptype="p:label-elements">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="attribute"as="xs:QName"select="'xml:id'"/>  
     <p:optionname="label"as="xs:string"select="'concat("_",$p:index)'"/><!-- XPathExpression -->
     <p:optionname="match"as="xs:string"select="'*'"/>          <!-- XSLTSelectionPattern -->
     <p:optionname="replace"as="xs:boolean"select="true()"/>    
</p:declare-step>

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 XSLTSelectionPattern. It is a dynamic error (err:XC0023) if that expression matches anything other than element nodes.

The value of the replacemust 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 specified by an IRI.

<p:declare-steptype="p:load">
     <p:outputport="result"content-types="any"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
     <p:optionname="content-type"as="xs:string?"/>               
     <p:optionname="document-properties"as="map(xs:QName, item()*)?"/>
</p:declare-step>

If the option is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or the step in case of a syntactic shortcut value). If the href 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). It is a dynamic error (err:XD0064) if the base URI is not both absolute and valid according to [RFC 3986].

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

It is a dynamic error (err:XD0011) if the resource referenced by a p:load element does not exist or cannot be accessed.

The behavior of this step depends on the content type of the document loaded. The content type of a 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 five categories of data that might be loaded: XML, text, JSON, HTML, 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-steptype="p:make-absolute-uris">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="match"required="true"as="xs:string"/>       <!-- XSLTSelectionPattern -->
     <p:optionname="base-uri"as="xs:anyURI?"/>                   
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern. 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). It is a dynamic error (err:XD0064) if the base URI is not both absolute and valid according to [RFC 3986].

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 absent and the input document has no base URI, the results are implementation-dependent.

The p:namespace-delete step deletes all of the namespaces identified by the specified prefixes from the document appearing on port source.

<p:declare-steptype="p:namespace-delete">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="prefixes"required="true"as="xs:string"/>    
</p:declare-step>

The value of option prefixes is taken as a space separated list of prefixes. It is a dynamic error (err:XC0108) if any prefix is not in-scope at the point where the p:namespace-delete occurs.

For any prefix the associated namespace is removed from the elements and attributes in the document appearing on port source. The respective elements or attributes in the document appearing on port result will be in no namespace.

It is a dynamic error (err:XC0109) if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.

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

<p:declare-steptype="p:namespace-rename">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="from"as="xs:anyURI?"/>                       
     <p:optionname="to"as="xs:anyURI?"/>                         
     <p:optionname="apply-to"as="xs:token"select="'all'"values="('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-steptype="p:pack">
     <p:inputport="source"content-types="text xml html"sequence="true"primary="true"/>
     <p:inputport="alternate"sequence="true"content-types="text xml html"/>
     <p:outputport="result"sequence="true"content-types="application/xml"/>
     <p:optionname="wrapper"required="true"as="xs:QName"/>      
</p:declare-step>

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:rename step renames elements, attributes, or processing-instruction targets in a document.

<p:declare-steptype="p:rename">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern -->
     <p:optionname="new-name"required="true"as="xs:QName"/>     
</p:declare-step>

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

Each element, attribute, or processing-instruction in the input matched by the selection 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 top-level node(s) of the replacement port's document.

<p:declare-steptype="p:replace">
     <p:inputport="source"primary="true"content-types="xml html"/>
     <p:inputport="replacement"content-types="text xml html"/>
     <p:outputport="result"content-types="text xml html"/>
     <p:optionname="match"required="true"as="xs:string"/>       <!-- XSLTSelectionPattern -->
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern. It is a dynamic error (err:XC0023) if that pattern matches an attribute or a namespace 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 by the top-level node(s) of the replacement document. Only non-nested matches are replaced. That is, once a node is replaced, its descendants cannot be matched.

If the document node is matched and port replacement contains a text document, the entire document is replaced by the text node. What appears on port result is a text document with the text node wrapped in a document node.

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

<p:declare-steptype="p:set-attributes">
     <p:inputport="source"primary="true"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern -->
     <p:optionname="attributes"required="true"as="map(xs:QName, xs:anyAtomicType)"/>
</p:declare-step>

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

A new attribute is created for each entry in the map appearing on the attributes option. The attribute name is taken from the entry's key while the attribute value is taken from the string value of the entry's value.

If an attribute with the same name as one of the attributes to be created already exists, the value specified on the attributes option 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 selection pattern in the match option. All matching elements are processed. If no elements match, the step will not change any elements.

If the attributes taken 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-steptype="p:set-properties">
     <p:inputport="source"content-types="any"/>
     <p:outputport="result"content-types="any"/>
     <p:optionname="properties"required="true"as="map(xs:QName,item()*)"/>
     <p:optionname="merge"select="true()"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, overwriting already existing values for a given key. If it is false, the document’s properties are replaced by the new set.

It is a dynamic error (err:XD0070) if a value is assigned to the serialization document property that cannot be converted into map(xs:QName, item()*) according to the rules in section “QName handling” of [XProc 3.0].

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

If the properties map contains a key equal to the string “base-uri” the associated value is taken as the new base URI of the resulting document. It is a dynamic error (err:XD0064) if the base URI is not both absolute and valid according to [RFC 3986].

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

<p:declare-steptype="p:sink">
     <p:inputport="source"content-types="any"sequence="true"/>
</p:declare-step>

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

<p:declare-steptype="p:split-sequence">
     <p:inputport="source"content-types="any"sequence="true"/>
     <p:outputport="matched"sequence="true"primary="true"content-types="any"/>
     <p:outputport="not-matched"sequence="true"content-types="any"/>
     <p:optionname="initial-only"as="xs:boolean"select="false()"/>
     <p:optionname="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. It is a dynamic error (err:XC0150) if evaluating the XPath expression in option test on a context document results in an error.

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. It outputs a reference to the location of the stored document on the result-uri port. Aside from these side-effects, it behaves like a p:identity step, copying its input to the result port.

<p:declare-steptype="p:store">
     <p:inputport="source"content-types="any"/>
     <p:outputport="result"content-types="any"primary="true"/>
     <p:outputport="result-uri"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
</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 document to the specified URI. If the URI scheme “file:” is supported, the processor should try to create all non existing folders in the URI’s path. 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 on the result-uri port 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. If the document to be stored has a “serialization” property, the serialization is controlled by the merger of the two maps where the entries in the “serialization” property take precedence. 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-steptype="p:string-replace">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="text xml html"/>
     <p:optionname="match"required="true"as="xs:string"/>       <!-- XSLTSelectionPattern -->
     <p:optionname="replace"required="true"as="xs:string"/>     <!-- XPathExpression -->
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern.

The value of the replace option must be an XPathExpression.

The matched nodes are specified with the selection 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 document node is matched, the entire document is replaced by the string value of the replace expression. What appears on port result is a text document with the text node wrapped in a document node.

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:text-count step counts the number of lines in a text document and returns a single XML document containing that number.

<p:declare-steptype="p:text-count">
     <p:inputport="source"primary="true"sequence="false"content-types="text"/>
     <p:outputport="result"primary="true"sequence="false"content-types="application/xml"/>
</p:declare-step>

The p:text-count step counts the number of lines in the text document appearing on its source port. It returns on its result port an XML document containing a single c:result element whose contents is the string representing this count.

Lines are identified as described in XML, 2.11 End-of-Line Handling. For the purpose of identifying lines, if the very last character in the text document is a newline (
), that newline is ignored. (It is not a separator between that line and a following line that contains no characters.)

The p:text-head step returns lines from the beginning of a text document.

<p:declare-steptype="p:text-head">
     <p:inputport="source"primary="true"sequence="false"content-types="text"/>
     <p:outputport="result"primary="true"sequence="false"content-types="text"/>
     <p:optionname="count"required="true"as="xs:integer"/>      
</p:declare-step>

The p:text-head step returns on its result port lines from the text document that appears on its source port:

Lines are identified as described in XML, 2.11 End-of-Line Handling. All lines returned by p:text-head are terminated with a single newline (
).

The p:text-join step concatenates text documents.

<p:declare-steptype="p:text-join">
     <p:inputport="source"sequence="true"content-types="text"/>
     <p:outputport="result"content-types="text"/>
     <p:optionname="separator"as="xs:string?"/>                  
     <p:optionname="prefix"as="xs:string?"/>                     
     <p:optionname="suffix"as="xs:string?"/>                     
     <p:optionname="override-content-type"as="xs:string?"/>      
</p:declare-step>

The p:text-join step concatenates the text documents appearing on its source port into a single document on its result port. The documents will be concatenated in order of appearance.

When the override-content-type option is specified, the document appearing on the port result will have this media type as part of its document properties. It is a dynamic error (err:XD0079) if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”. It is a dynamic error (err:XC0001) if the value of option override-content-type is not a text media type.

Concatenating text documents does not require identifying individual lines in each document, consequently no special end-of-line handling is performed.

The p:text-replace step replaces all occurrences of substrings in a text document that match a supplied regular expression with a given replacement string.

<p:declare-steptype="p:text-replace">
     <p:inputport="source"primary="true"sequence="false"content-types="text"/>
     <p:outputport="result"primary="true"sequence="false"content-types="text"/>
     <p:optionname="pattern"required="true"as="xs:string"/>     
     <p:optionname="replacement"required="true"as="xs:string"/> 
     <p:optionname="flags"as="xs:string?"/>                      
</p:declare-step>

The p:text-replace step replaces all occurrences of substrings in the text document appearing on its source port that match a supplied regular expression with a given replacement string. The result is returned (as another text document) on its result port.

This step is a convenience wrapper around the XPath fn:replace function to ease text replacements in the document flow of a pipeline.

The pattern, replacement and flags options are specified the same as the parameters with the same names of the fn:replace function. The pattern option must be a regular expression as specified in [XPath and XQuery Functions and Operators 3.1], section 7.61 “Regular Expression Syntax”. It is a dynamic error (err:XC0147) if the specified value is not a valid XPath regular expression.

Replacing strings in text documents does not require identifying individual lines in each document, consequently no special end-of-line handling is performed.

The p:text-sort step sorts lines in a text document.

<p:declare-steptype="p:text-sort">
     <p:inputport="source"primary="true"sequence="false"content-types="text"/>
     <p:outputport="result"primary="true"sequence="false"content-types="text"/>
     <p:optionname="sort-key"as="xs:string"select="'.'"/>       <!-- XPathExpression -->
     <p:optionname="order"as="xs:string"select="'ascending'"values="('ascending', 'descending')"/>
     <p:optionname="case-order"as="xs:string?"values="('upper-first', 'lower-first')"/>
     <p:optionname="lang"as="xs:language?"/>                     
     <p:optionname="collation"as="xs:string"select="'https://www.w3.org/2005/xpath-functions/collation/codepoint'"/>
     <p:optionname="stable"as="xs:boolean"select="true()"/>     
</p:declare-step>

The p:text-sort step sorts the lines in the text document appearing on its source port and returns the result as another text document on its result port. The sort key is obtained by applying the XPath expression in sort-key to each line in turn.

Lines are identified as described in XML, 2.11 End-of-Line Handling. For the purpose of identifying lines, if the very last character in the text document is a newline (
), that newline is ignored. (It is not a separator between that line and a following line that contains no characters.) All lines returned by p:text-sort are terminated with a single newline (
).

The sort process performed by this step is the same as described in The xsl:sort Element. Options lang and case-order are only taken into consideration if no value is selected for option collation.

The p:text-tail step returns lines from the end of a text document.

<p:declare-steptype="p:text-tail">
     <p:inputport="source"primary="true"sequence="false"content-types="text"/>
     <p:outputport="result"primary="true"sequence="false"content-types="text"/>
     <p:optionname="count"required="true"as="xs:integer"/>      
</p:declare-step>

The p:text-tail step returns on its result port lines from the text document that appears on its source port:

Lines are identified as described in XML, 2.11 End-of-Line Handling. All lines returned by p:text-tail are terminated with a single newline (
).

The p:unarchive step outputs on its result port specific entries in an archive (for instance from a zip file).

<p:declare-steptype="p:unarchive">
     <p:inputport="source"primary="true"content-types="any"sequence="false"/>
     <p:outputport="result"primary="true"content-types="any"sequence="true"/>
     <p:optionname="include-filter"as="xs:string*"/>             <!-- RegularExpression -->
     <p:optionname="exclude-filter"as="xs:string*"/>             <!-- RegularExpression -->
     <p:optionname="format"as="xs:QName?"/>                      
     <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
     <p:optionname="relative-to"as="xs:anyURI?"/>                
     <p:optionname="override-content-types"as="array(array(xs:string))?"/>
</p:declare-step>

The meaning and interpretation of the p:unarchive step's options is as follows:

The base URI of an unarchived document appearing on the result port is:

It is a dynamic error (err:XC0120) if the relative-to option is not present and the document on the source port does not have a base URI. It is a dynamic error (err:XD0064) if the option is not a valid URI according to [RFC 3986].

For instance, the base URI of an unarchived file called xyz.xml that resided in the specs subdirectory in an archive with base URI file:///a/b/c.zip will become:

The p:uncompress step expects on its source port a compressed document. It outputs an uncompressed version of this on its result port.

<p:declare-steptype="p:uncompress">
     <p:inputport="source"primary="true"content-types="any"sequence="false"/>
     <p:outputport="result"primary="true"content-types="any"sequence="false"/>
     <p:optionname="format"as="xs:QName?"/>                      
     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
     <p:optionname="content-type"as="xs:string"select="'application/octet-stream'"/>
</p:declare-step>

The compression format of the document appearing on the source port is determined as follows:

The parameters option can be used to supply parameters to control the uncompression. 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.

Identification of the uncompressed document's content-type is done as follows:

The p:unwrap step replaces matched elements with their children.

<p:declare-steptype="p:unwrap">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="application/xml text/plain"/>
     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern -->
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern. It is a dynamic error (err:XC0023) if that pattern matches anything other than the document node or 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. If the step produces a document node with a single text child, the result will have content type “text/plain”.

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

<p:declare-steptype="p:uuid">
     <p:inputport="source"primary="true"content-types="xml html"/>
     <p:outputport="result"content-types="text xml html"/>
     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern -->
     <p:optionname="version"as="xs:integer?"/>                   
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern. 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 selection 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 document node is matched, the entire document is replaced by a text node with the UUID. What appears on port result is a text document with the text node wrapped in a document node.

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-steptype="p:wrap-sequence">
     <p:inputport="source"content-types="text xml html"sequence="true"/>
     <p:outputport="result"sequence="true"content-types="application/xml"/>
     <p:optionname="wrapper"required="true"as="xs:QName"/>      
     <p:optionname="group-adjacent"as="xs:string?"/>             <!-- XPathExpression -->
</p:declare-step>

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. Two “group adjacent” values are the same if the standard XPath function deep-equal() returns true for them.

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

<p:declare-steptype="p:wrap">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="application/xml"/>
     <p:optionname="wrapper"required="true"as="xs:QName"/>      
     <p:optionname="match"required="true"as="xs:string"/>       <!-- XSLTSelectionPattern -->
     <p:optionname="group-adjacent"as="xs:string?"/>             <!-- XPathExpression -->
</p:declare-step>

The value of the match option must be an XSLTSelectionPattern. 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 selection 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 “group adjacent” values are the same if the standard XPath function deep-equal() returns true for them.

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 a JSON representation.

<p:declare-steptype="p:www-form-urldecode">
     <p:outputport="result"content-types="application/json"/>
     <p:optionname="value"required="true"as="xs:string"/>       
</p:declare-step>

A JSON object of the form “map(xs:string, xs:string+)” will appear on result port. The value option is interpreted as a string of parameter values encoded using the x-www-form-urlencoded algorithm. Each name/value pair is represented in the JSON object as key/value entry.

It is a dynamic error (err:XC0037) if the value provided is not a properly x-www-form-urlencoded value.

If any parameter name occurs more than once in the encoded string, a sequence will be associated with the respective key. The order in the sequence retains the order of name/value pairs in the encoded string.

The p:www-form-urlencode step encodes a set of parameter values as a x-www-form-urlencoded string.

<p:declare-steptype="p:www-form-urlencode">
     <p:outputport="result"content-types="text/plain"/>
     <p:optionname="parameters"required="true"as="map(xs:string,xs:untypedAtomic+)"/>
</p:declare-step>

The map entries of parameters option are encoded as a single x-www-form-urlencoded string of name/value pairs. This string is returned on the result port as a text document.

If more than one value is associated with a given key in parameters option, a name/value pair is created for each value.

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

<p:declare-steptype="p:xinclude">
     <p:inputport="source"content-types="xml html"/>
     <p:outputport="result"content-types="xml html"/>
     <p:optionname="fixup-xml-base"as="xs:boolean"select="false()"/>
     <p:optionname="fixup-xml-lang"as="xs:boolean"select="false()"/>
</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:xquery step applies an XQuery query to the sequence of documents provided on the source port.

<p:declare-steptype="p:xquery">
     <p:inputport="source"content-types="any"sequence="true"primary="true"/>
     <p:inputport="query"content-types="text xml"/>
     <p:outputport="result"sequence="true"content-types="any"/>
     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
     <p:optionname="version"as="xs:string?"/>                    
</p:declare-step>

If a sequence of documents is provided on the source port, the first document is used as the initial context item. The whole sequence is also the default collection. If no documents are provided on the source port, the initial context item is undefined and the default collection is empty.

The query port must receive a single document which is either an XML document or a text document. A text document must be treated as the query. For an XML document the following rules apply:

If the step specifies a version, then that version of XQuery must be used to process the transformation. It is a dynamic error (err:XC0009) if the specified XQuery 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 query.It is implementation defined which XQuery version(s) is/are supported.

The name/value pairs in option parameters are used to set the query’s external variables.

It is a dynamic error (err:XC0101) if a document appearing on port source cannot be represented in the XDM version associated with the chosen XQuery version, e.g. when a JSON document contains a map and XDM 3.0 is used. It is a dynamic error (err:XC0102) if any key in option parameters is associated to a value that cannot be represented in the XDM version associated with the chosen XQuery version, e.g. with a map, an array, or a function when XDM 3.0 is used.

It is a dynamic error (err:XC0103) if any error occurs during XQuery’s static analysis phase. It is a dynamic error (err:XC0104) if any error occurs during XQuery’s dynamic evaluation phase.

The output of this step may include PSVI annotations.

The static context of the XQuery processor is augmented in the following way:

The dynamic context of the XQuery processor is augmented in the following way:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:input port="source"/> <p:output port="result"/> <p:xinclude/> <p:validate-with-xml-schema name="validate"> <p:with-input port="schema" href="http://example.com/path/to/schema.xsd"/> </p:validate-with-xml-schema> <p:xquery> <p:with-input port="query" href="countp.xq"/> </p:xquery> </p:declare-step>

<count>{count(.//p)}</count>

The p:xslt step invokes an XSLT stylesheet.

<p:declare-steptype="p:xslt">
     <p:inputport="source"content-types="any"sequence="true"primary="true"/>
     <p:inputport="stylesheet"content-types="xml"/>
     <p:outputport="result"primary="true"sequence="true"content-types="any"/>
     <p:outputport="secondary"sequence="true"content-types="any"/>
     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
     <p:optionname="static-parameters"as="map(xs:QName,item()*)?"/>
     <p:optionname="global-context-item"as="item()?"/>           
     <p:optionname="populate-default-collection"as="xs:boolean?"select="true()"/>
     <p:optionname="initial-mode"as="xs:QName?"/>                
     <p:optionname="template-name"as="xs:QName?"/>               
     <p:optionname="output-base-uri"as="xs:anyURI?"/>            
     <p:optionname="version"as="xs:string?"/>                    
</p:declare-step>

If output-base-uri 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 xslt 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. It is implementation-defined which XSLT version(s) is/are supported.

The XSLT stylesheet provided on the stylesheet port is invoked. It is a dynamic error (err:XC0093) if a static error occurs during the static analysis of the XSLT stylesheet. Any parameters passed in the parameters option are used to define top-level stylesheet parameters.

Parameters passed in the static-parameters option are passed as static parameters to the XSLT invocation. Whether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher). If static parameters are not supported the option is ignored.

It is a dynamic error (err:XC0095) if an error occurred during the transformation. It is a dynamic error (err:XC0096) if the transformation is terminated by XSLT message termination. How XSLT message termination errors are reported to the XProc processor is implementation-dependent. Implementations should raise an error using the error code from the XSLT step (for example, the error-code specified on the xsl:message or Q{http://www.w3.org/2005/xqt-errors}XTTM9000 if no code is provided).

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

The interpretation of the input and output ports as well as for the other options depends on the selected XSLT version.