From 6722bccd321d6c5b22af3ac867d179357ef5d3a4 Mon Sep 17 00:00:00 2001 From: ndw Date: Thu, 15 Aug 2024 16:05:41 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20xproc/3.?= =?UTF-8?q?0-steps@b7552ef08d3390d0a8adf890b8c5b68d684ca76b=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- master/head/etc/step-validation/library.xml | 5 +- master/head/etc/step-validation/source.xml | 139 +++++++------ master/head/etc/step-validation/toc.xml | 17 +- master/head/file/diff.html | 2 +- master/head/file/index.html | 2 +- master/head/ixml/diff.html | 2 +- master/head/ixml/index.html | 2 +- master/head/mail/diff.html | 2 +- master/head/mail/index.html | 2 +- master/head/os/diff.html | 2 +- master/head/os/index.html | 2 +- master/head/paged-media/diff.html | 2 +- master/head/paged-media/index.html | 2 +- master/head/run/diff.html | 2 +- master/head/run/index.html | 2 +- master/head/steps/diff.html | 2 +- master/head/steps/index.html | 2 +- master/head/steps/lcdiff.html | 2 +- master/head/text/diff.html | 2 +- master/head/text/index.html | 2 +- master/head/validation/diff.html | 2 +- master/head/validation/index.html | 208 +++++++++----------- master/head/validation/specification.xml | 139 +++++++------ master/head/validation/steps.xpl | 5 +- 24 files changed, 261 insertions(+), 288 deletions(-) diff --git a/master/head/etc/step-validation/library.xml b/master/head/etc/step-validation/library.xml index 62b8adc71..8186e4f27 100644 --- a/master/head/etc/step-validation/library.xml +++ b/master/head/etc/step-validation/library.xml @@ -58,7 +58,10 @@ - + + + + diff --git a/master/head/etc/step-validation/source.xml b/master/head/etc/step-validation/source.xml index 6b7eaa139..6e934725c 100644 --- a/master/head/etc/step-validation/source.xml +++ b/master/head/etc/step-validation/source.xml @@ -67,8 +67,7 @@ step for This specification describes the p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, -p:validate-with-nvdl, p:validate-with-json-schema, -and p:validate-with-dtd +p:validate-with-nvdl, and p:validate-with-json-schema steps. Each is independently optional. A machine-readable description of these steps may be found in steps.xpl. @@ -130,9 +129,6 @@ validation steps and their semantics are xvrl:map-to-severity, and xvrl:xpath-notation. -
-Step library -
Validate with NVDL @@ -165,15 +161,20 @@ validation steps and their semantics are p:validate-with-nvdl is true and the input document is not valid. - The output from this step is a copy of the input. The output of this - step may include PSVI annotations. + The output from this step is a copy of the input. The output of this step may include PSVI + annotations. + + Should the step also provide the and + options for Relax NG validations? Is there a way to instruct Jing + to use these options, maybe in NVDL extension attributes? Probably not in the foreseeable future. + + Document properties - All document properties - on the source port are preserved on the result - port. No document properties are - preserved on the report port. + All document properties on the source port are preserved + on the result port. No document properties on the schemas and nvdl ports + are preserved. No document properties are preserved on the report port.
@@ -235,7 +236,7 @@ augmented by application of the Document properties All document properties on the source port are preserved on the result port. -No document +No document properties on the schema port are preserved. No document properties are preserved on the report port.
@@ -313,7 +314,7 @@ input. Document properties All document properties on the source port are preserved on the result port. -No document +No document properties on the schema port are preserved. No document properties are preserved on the report port. @@ -438,8 +439,7 @@ by the XML Schema recommendation. Document properties All document properties on the source port are preserved on the result port. -No document -properties are preserved on the report port. +No document properties on the schemas port are preserved. @@ -476,24 +476,30 @@ properties are preserved on the report port. if the option on p:validate-with-json-schema is true and the input document is not valid. - - The output from this step is a copy of the input. Document properties - All document properties on - the source port are preserved on the result port. - No document properties are preserved on the report port. + All document properties on the source port are preserved + on the result port. No document properties on the schemas are preserved. + No document properties are preserved on the report port. + +Errata, April 2024 +Corrected an error in the sequence type for the default-version option +to allow it to be optional. +
- Validate with DTD + Validate with a DTD The p:validate-with-dtd step validates XML with a DTD. - + + + + @@ -503,51 +509,46 @@ properties are preserved on the report port. DTD validation differs from the other XML validation technologies in that it is applied during parsing. It isn’t possible to validate an XML data model with -a DTD. This step necessarily serializes and reparses. - -The p:validate-with-dtd step serializes the document on the source -port and parses the serialization with a -validating XML parser. Any warning or error messages produced by the parser will -appear on the report port. - - -The serialization options must include at least the -doctype-system property (without a system identifier, the -document cannot be successfully parsed with a validating parser). - +a DTD. This step necessarily serializes the source document and then parses it +back into a new data model. + -It is a dynamic error -if the option on p:validate-with-dtd -is true -and the input document is not valid. +There are several possible approaches, with varying degrees of complexity. +The general model is that the contents of the doctype port and +the result of serializing the source are concatenated together. + -The output from this step is a copy of the input. If validation was -successful, the output may have been augmented by the DTD. (For example, default -attributes may have been added.) + + +In the simple case, the doctype is empty and source +document is simply serialized. In order to have any chance of being DTD-valid, +the serialization properties must include at least a doctype-system +property. + + +If an internal subset is required, it is provided on the doctype port. +In this case, the source document must be serialized without +a doctype-system property; both the internal and external declarations must appear +on the doctype port. + + +Finally, if a text document is provided on the source port, +it is simply concatenated with the doctype port. + + - -Using an internal subset +The resulting text is parsed using a validating XML parser. -To validate a document with an internal subset, construct a text document -that is a syntactically valid XML document with the internal -subset, use p:cast-content-type to create an XML document, -and then validate the resulting document with this step. - +Any warning or error messages produced by the parser will appear on the +report port. If validation succeeds, the validated document will appear on the +result port. - -Document properties -All document properties -on the source port are preserved on the result -port. No document properties are -preserved on the report port. -
-
Step Errors -These steps can raise +This step can raise dynamic errors. @@ -603,6 +604,14 @@ how implementation-defined features are
+ +
+Implementation-dependent features + +The following features are implementation-dependent: + + +
@@ -685,22 +694,6 @@ implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed. - -Change log - -This appendix catalogs recent non-editorial changes. - - - -Corrected an error in the sequence type for the default-version option -on p:validate-with-json-schema to allow it to be optional. - - -Added the p:validate-with-dtd step. - - - - Ancillary files diff --git a/master/head/etc/step-validation/toc.xml b/master/head/etc/step-validation/toc.xml index 943938e60..f47916abe 100644 --- a/master/head/etc/step-validation/toc.xml +++ b/master/head/etc/step-validation/toc.xml @@ -6,22 +6,19 @@ xmlns:xlink="http://www.w3.org/1999/xlink">XProc 3.0: validation steps Introduction Common Options and Outputs - - Step library - Validate with NVDL - Validate with RELAX NG - Validate with Schematron - Validate with XML Schema - Validate with JSON schema - Validate with DTD - + Validate with NVDL + Validate with RELAX NG + Validate with Schematron + Validate with XML Schema + Validate with JSON schema + Validate with a DTD Step Errors Conformance Implementation-defined features + Implementation-dependent features References Glossary - Change log Ancillary files diff --git a/master/head/file/diff.html b/master/head/file/diff.html index 831e4a3a4..86380a7c7 100644 --- a/master/head/file/diff.html +++ b/master/head/file/diff.html @@ -15,4 +15,4 @@ Previous Next -

XProc 3.0: file steps

Draft Community Group Report

Editor's Draft at (build 4547)
Latest editor’s draft:
https://spec.xproc.org/master/head/file/
Editors:
Norman Walsh
Achim Berndzen
Gerrit Imsieke
Erik Siegel
Participate:
GitHub xproc/3.0-steps
Report an issue
Changes:
Diff against current “status quo” draft
Commits for this specification

This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: file steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Abstract

This specification describes the file related steps for XProc 3.0: An XML Pipeline Language.

Status of this Document

This document is an editor's draft that has no official standing.

This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

1. Introduction

This specification describes the file related XProc steps. A machine-readable description of these steps may be found in steps.xpl.

Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

Some filesystems and some operating systems support “special” files. These may be interfaces to underlying block or character devices, or represent file system features such as linking two filenames so that they point to the same data. On many filesystems on Unix(-derived) operating systems, the files /dev/null, /dev/urandom, and /dev/zero are special, as are hard and soft symbolic links. Windows and Mac filesystems also support special files and other linking mechanisms.

How the file steps behave with respect to special files is implementation-defined. It may be an error to attempt to access them, or they may be ignored by some or all steps.

2. Step library

2.1. p:directory-list

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

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
pathxs:anyURI ✔ 
detailedxs:booleanfalse() 
exclude-filterxs:string*() 
include-filterxs:string*() 
max-depthxs:string?'1' 
override-content-typesarray(array(xs:string))?() 
Errors
Error codeDescription
err:C0012It is a dynamic error if the contents of the directory path are not available to the step due to access restrictions in the environment in which the pipeline is run.
err:C0017It is a dynamic error if the absolute path does not identify a directory.
err:C0090It is a dynamic error if an implementation does not support directory listing for a specified scheme.
err:C0147It is a dynamic error if a specified value is not a valid XPath regular expression.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant 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.
DefinedAny file or directory determined to be special by the p:directory-list step may be output using a c:other element but the criteria for marking a file as special are implementation-defined.
DefinedThe precise meaning of the detailed properties are implementation-defined and may vary according to the URI scheme of the path.
DefinedAny other attributes on c:file, c:directory, or c:other are implementation-defined
Declaration

<p:declare-steptype="p:directory-list">
     <p:outputport="result"content-types="application/xml"/>
     <p:optionname="path"required="true"as="xs:anyURI"/>        
     <p:optionname="detailed"as="xs:boolean"select="false()"/>  
     <p:optionname="max-depth"as="xs:string?"select="'1'"/>     
     <p:optionname="include-filter"as="xs:string*"/>             
     <p:optionname="exclude-filter"as="xs:string*"/>             
     <p:optionname="override-content-types"as="array(array(xs:string))?"/>
</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.It is a dynamic error (err:XC0090) if an implementation does not support directory listing for a specified scheme.

If path is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:directory-list 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]. 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 the detailed option is true, the pipeline author is requesting additional information about the matching entries, see the section called “Directory list details”.

The max-depth option may contain either the string “unbounded” or a string that may be cast to a non-negative integer. An integer value of 0 means that only information about the directory that is given in the path option is returned. A max-depth of 1, which is the default, will effect that also information about the top-level directory’s immediate children will be included. For larger values of max-depth, also the content of directories will be considered recursively up to the maximum depth, and it will be included as children of the corresponding c:directory elements.

If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions 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 a specified value is not a valid XPath regular expression.

The regular expressions will be matched against an item’s file system path relative to the top-level path that was given in the path option. If the item is a directory, a trailing slash will be appended. The matching is done unanchored: it is a match if the regular expression matches part of the relative item’s file system path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path, $regular-expression).

Examples: A file file.txt in the directory specified by path will remain file.txt, a relative path dir1/file.txt will remain dir1/file.txt, while a relative path dir1/dir2 will become dir1/dir2/ if dir2 is a directory.

Regular expressions that match a/a/b/file.txt are, for example, ^(\w+/){2,3}.+\.txt$, a/a/b/, or /file\.[^/]+$.

If any include-filter pattern matches the slash-augmented relative path, the entry is included in the output. Matching a directory doesn’t automatically include the contents of the directory or its descendants; to be included, each individual entry must match an include filter. For example, the filter regex ^dir/ will match a directory and its content, but ^dir/$ won’t.

Although matching a directory doesn’t automatically include its entries, matching an entry does automatically include all of its ancestors (back to the initial directory). This assures that the hierarchy of the XML elements matches the hierarchy of the filesystem. When ancestors are included this way, none of their other entires are included unless they match an include filter.

For a file a/a/b/file.txt below the initial directory /home/jane, this output will be produced, omitting content that might be present in the intermediate directories:

<c:directory xml:base="file:///home/jane/" name="jane"> <c:directory xml:base="a/" name="a"> <c:directory xml:base="a/" name="a"> <c:directory xml:base="b/" name="b"> <c:file xml:base="file.txt" name="file.txt"/> </c:directory> </c:directory> </c:directory> </c:directory>

If the exclude-filter pattern matches the slash-augmented relative path, the entry (and all of its content in case of a directory) is excluded in the output.

If both options are provided, the include filter is processed first, then the exclude filter. As a result, an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.

If no include-filter is given, that is, if include-filter is an empty sequence, any item will be included in the result (unless it is excluded by exclude-filter).

Note

There is no way to specify a list of values using attribute value templates. If the option shortcut syntax is used to provide the include-filter or exclude-filter option, it will consist of a single regular expression. To specify a list of regular expressions, you must use the p:with-option syntax.

The override-content-types option can be used to partially override the content-type determination mechanism. This works just like with the override-content-types option of p:archive-manifest and p:unarchive (see Overriding content types in XProc 3.0+: Standard Step Library), except that the regular expression matching is done against the paths as used for the matching of the include-filter and exclude-filter options.

The result document produced for the specified directory path has a c:directory document element whose base URI, attached as an xml:base attribute, is the absolute directory path (expressed as a URI that ends in a slash) and whose name attribute (without a trailing slash) is the last segment of the directory path. The same base URI is attached as the resulting document’s base-uri property and, accordingly, as its document node’s base URI.

<c:directory
  name = string
  size? = integer
  readable? = boolean
  writable? = boolean
  last-modified? = dateTime
  hidden? = boolean>
    (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 and subject to the rules that are imposed by the max-depth, include-filter, and exclude-filter options, a c:file, a c:directory, or a c:other element is produced, as follows:

  • A c:directory is produced for each subdirectory not determined to be special. Depending on the values of the three options, it may contain child elements for the directory’s content.

  • A c:file is produced for each file not determined to be special.

    <c:file
      name = string
      size? = integer
      readable? = boolean
      writable? = boolean
      last-modified? = dateTime
      hidden? = boolean
      content-type? = ContentType />

  • Any file or directory determined to be special by the p:directory-list step may be output using a c:other element but the criteria for marking a file as special are implementation-defined.

    <c:other
      name = string
      size? = integer
      readable? = boolean
      writable? = boolean
      last-modified? = dateTime
      hidden? = boolean />

Each of the elements c:file, c:directory, and c:other has a name attribute, whose value is a relative IRI reference, giving the (local) file or directory name.

Each of these element also contains the corresponding resource’s URI in an xml:base attribute, which may be a relative URI for any but the top-level c:directory element. In the case of c:directory, it must end in a trailing slash. This way, users will always be able to compute the absolute URI for any of these elements by applying fn:base-uri() to it.

Directory list details

If detailed is false, then only the name and xml:base attributes are expected on c:file, c:directory, or c:other elements.

If detailed is true, then the pipeline author is expecting additional details about each entry. The following attributes should be provided by the implementation:

content-type

The content-type attribute contains the content type of the respective file. The value “application/octet-stream” will be used if the processor is not able to identify another content type.

readable

“true” if the entry is readable.

writable

“true” if the entry is writable.

hidden

“true” if the entry is hidden.

last-modified

The last modification time of the entry, expressed as a lexical xs:dateTime in UTC.

size

The size of the entry in bytes.

The precise meaning of the detailed properties are implementation-defined and may vary according to the URI scheme of the path. If the value of an attribute is “false” or if it has no meaningful value, the attribute may be omitted.

Any other attributes on c:file, c:directory, or c:other are implementation-defined, but they must be in a namespace.

Document properties

Besides the content-type property, the resulting document has a base-uri. Its value is identical to the top-level element’s xml:base attribute, that is, to the directory’s URI.

2.2. p:file-copy

The p:file-copy step copies a file or a directory to a given target.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
targetxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
overwritexs:booleantrue() 
Errors
Error codeDescription
err:C0050It is a dynamic error the file or directory cannot be copied to the specified location.
err:C0144It is a dynamic error if an implementation does not support p:file-copy for a specified scheme.
err:C0145It is a dynamic error if p:file-copy is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:C0157It is a dynamic error if the href option names a directory, but the target option names a file.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href and target options of p:file-copy. It is implementation-defined what other schemes are supported by p:file-copy, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-copy">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="target"required="true"as="xs:anyURI"/>      
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
     <p:optionname="overwrite"as="xs:boolean"select="true()"/>  
</p:declare-step>

The p:file-copy step copies the file or directory named in href to the new position specified in target. Any non existent directory contained in target will be created before copying starts. If the target is a directory, the step attempts to copy the file or directory into that directory, preserving its base name. It is a dynamic error (err:XC0157) if the href option names a directory, but the target option names a file.

If the overwrite evaluates to false, no existing file will be changed.

Conformant processors must support URIs whose scheme is file for the href and target options of p:file-copy. It is implementation-defined what other schemes are supported by p:file-copy, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0144) if an implementation does not support p:file-copy for a specified scheme.

If href or target are relative, they are made absolute against the base URI of the element on which they are specified (p:with-option or p:file-copy 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]. It is a dynamic error (err:XC0145) if p:file-copy is not available to the step due to access restrictions in the environment in which the pipeline is run.

If no error occurs, the step returns a c:result element containing the absolute URI of the target.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error. In the case of a recursive copy, processing stops at the first error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.

  • It is a dynamic error (err:XC0050) the file or directory cannot be copied to the specified location.

Copying directories

If href identifies a directory and target also identifies a directory, or does not exist, then the p:file-copy step attempts to copy the entire directory tree identified by href: the directory and all of its descendants.

In this case:

  • If fail-on-error is false and an error occurs, no further copying is attempted after the first error is detected.

  • If overwrite is true, err:XC0157 does not apply to descendants. A directory under href may replace a file with the corresponding name under target.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.3. p:file-delete

The p:file-delete step deletes a file or a directory.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
recursivexs:booleanfalse() 
Errors
Error codeDescription
err:C0113It is a dynamic error if an attempt is made to delete a non-empty directory and the recursive option was set to false.
err:C0142It is a dynamic error if an implementation does not support p:file-delete for a specified scheme.
err:C0143It is a dynamic error if p:file-delete is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option cannot be accessed or is not a file or directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-delete. It is implementation-defined what other schemes are supported by p:file-delete, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-delete">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="recursive"as="xs:boolean"select="false()"/> 
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-delete step attempts to delete an existing file or directory named in href. If the named file or directory does not exist, the step just returns a c:result element as described below.

Conformant processors must support URIs whose scheme is file for the href option of p:file-delete. It is implementation-defined what other schemes are supported by p:file-delete, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0142) if an implementation does not support p:file-delete for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-delete 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]. It is a dynamic error (err:XC0143) if p:file-delete is not available to the step due to access restrictions in the environment in which the pipeline is run.

If href specifies a directory, it can only be deleted if the recursive option is true or if the specified directory is empty.

The step returns a c:result element containing the absolute URI of the file or directory.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option cannot be accessed or is not a file or directory.

  • It is a dynamic error (err:XC0113) if an attempt is made to delete a non-empty directory and the recursive option was set to false.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.4. p:file-info

The p:file-info step returns information about a file, directory or other file system object.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
override-content-typesarray(array(xs:string))?() 
Errors
Error codeDescription
err:C0134It is a dynamic error if an implementation does not support p:file-info for a specified scheme.
err:C0135It is a dynamic error if p:file-info is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file, directory or other file system object.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-info. It is implementation-defined what other schemes are supported by p:file-info, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-info">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
     <p:optionname="override-content-types"as="array(array(xs:string))?"/>
</p:declare-step>

The p:file-info step returns information about the file, directory or other file system object named in the href option.

Conformant processors must support URIs whose scheme is file for the href option of p:file-info. It is implementation-defined what other schemes are supported by p:file-info, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0134) if an implementation does not support p:file-info for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-info 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]. It is a dynamic error (err:XC0135) if p:file-info is not available to the step due to access restrictions in the environment in which the pipeline is run.

If the href option is a file: URI, the step returns:

  • If href option references a file: A c:file element with standard attributes (see below).

  • If href option references a directory: A c:directory element with standard attributes (see below).

  • If href option references any other file system object: Implementation defined (for example an c:other or c:device element). It is advised to use the standard attributes (see below) if applicable.

The override-content-types option can be used to partially override the content-type determination mechanism for files. This works just like with the override-content-types option of p:archive-manifest and p:unarchive (see Overriding content types in XProc 3.0+: Standard Step Library), except that the regular expression matching is done against the absolute URI of the file.

Each of the elements c:file, c:directory, and c:other has a name attribute, whose value is a relative IRI reference, giving the (local) file or directory name.

The following attributes are standard on a returned c:file or c:directory element. All attributes are optional and must be absent if not applicable. Additional implementation-defined attributes may be present, but they must be in a namespace.

AttributeTypeDescription
readablexs:booleantrue if the object is readable.
writablexs:booleantrue if the object file is writable.
hiddenxs:booleantrue if the object is hidden.
last-modifiedxs:dateTimeThe last modification time of the object expressed in UTC.
sizexs:integerThe size of the object in bytes.
content-typexs:stringThe content type, if the object is a file.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file, directory or other file system object.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.5. p:file-mkdir

The p:file-mkdir step creates a directory.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
Errors
Error codeDescription
err:C0114It is a dynamic error if the directory referenced by the href option cannot be created.
err:C0140It is a dynamic error if an implementation does not support p:file-mkdir for a specified scheme.
err:C0141It is a dynamic error if p:file-mkdir not available to the step due to access restrictions in the environment in which the pipeline is run.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-mkdir. It is implementation-defined what other schemes are supported by p:file-mkdir, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-mkdir">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-mkdir create the directory named in the href option. If this includes more than one directory component, all of the intermediate components are created. If the directory already exists the step just returns the c:result element as described below. The path separator is implementation-defined.

Conformant processors must support URIs whose scheme is file for the href option of p:file-mkdir. It is implementation-defined what other schemes are supported by p:file-mkdir, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0140) if an implementation does not support p:file-mkdir for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-mkdir 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]. It is a dynamic error (err:XC0141) if p:file-mkdir not available to the step due to access restrictions in the environment in which the pipeline is run.

The step returns a c:result element containing the absolute URI of the directory.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, the following error is raised:

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.6. p:file-move

The p:file-move step moves a file or directory.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
targetxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
Errors
Error codeDescription
err:C0050It is a dynamic error if the directory cannot be moved to the specified location.
err:C0115It is a dynamic error if the resource referenced by the target option is an existing file or other file system object.
err:C0148It is a dynamic error if an implementation does not support p:file-move for a specified scheme.
err:C0149It is a dynamic error if p:file-move is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:C0158It is a dynamic error if the href option names a directory, but the target option names a file.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href and target options of p:file-move. It is implementation-defined what other schemes are supported by p:file-move, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-move">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="target"required="true"as="xs:anyURI"/>      
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-move step moves the file or directory named in href to the new location specified in target. If the target option specifies an existing directory, the step attempts to move the file or directory into that directory, preserving its base name. It is a dynamic error (err:XC0158) if the href option names a directory, but the target option names a file.

Conformant processors must support URIs whose scheme is file for the href and target options of p:file-move. It is implementation-defined what other schemes are supported by p:file-move, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0148) if an implementation does not support p:file-move for a specified scheme.

If href or target are relative, they are made absolute against the base URI of the element on which they are specified (p:with-option or p:file-move 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]. It is a dynamic error (err:XC0149) if p:file-move is not available to the step due to access restrictions in the environment in which the pipeline is run.

If the href option specifies a device or other special kind of object, the results are implementation-defined.

If the move is successful, the step returns a c:result element containing the absolute URI of the target.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.

  • It is a dynamic error (err:XC0115) if the resource referenced by the target option is an existing file or other file system object.

  • It is a dynamic error (err:XC0050) if the directory cannot be moved to the specified location.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.7. p:file-create-tempfile

The p:file-create-tempfile step creates a temporary file.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault value
delete-on-exitxs:booleanfalse()
fail-on-errorxs:booleantrue()
hrefxs:anyURI?()
prefixxs:string?()
suffixxs:string?()
Errors
Error codeDescription
err:C0116It is a dynamic error if the temporary file could not be created.
err:C0138It is a dynamic error if an implementation does not support p:file-create-tempfile for a specified scheme.
err:C0139It is a dynamic error if p:file-create-tempfile cannot be completed due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-create-tempfile. It is implementation-defined what other schemes are supported by p:file-create-tempfile, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-create-tempfile">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"as="xs:anyURI?"/>                       
     <p:optionname="suffix"as="xs:string?"/>                     
     <p:optionname="prefix"as="xs:string?"/>                     
     <p:optionname="delete-on-exit"as="xs:boolean"select="false()"/>
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-create-tempfile creates a temporary file. The temporary file is guaranteed not to already exist when the step is called.

If the href option is specified it must be the URI of an existing directory. The temporary file is created here. If there is no href option specified the location of the temporary file is implementation defined, usually the operating system's default location for temporary files.

Conformant processors must support URIs whose scheme is file for the href option of p:file-create-tempfile. It is implementation-defined what other schemes are supported by p:file-create-tempfile, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0138) if an implementation does not support p:file-create-tempfile for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-create-tempfile 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]. It is a dynamic error (err:XC0139) if p:file-create-tempfile cannot be completed due to access restrictions in the environment in which the pipeline is run.

If the prefix option is specified, the filename will begin with that prefix. If the suffix option is specified, the filename will end with that suffix.

If the delete-on-exit option is true, an attempt will be made to automatically delete the temporary file when the processor terminates the pipeline. No error will be raised if this is unsuccessful.

If the temporary file creation is successful, the step returns a c:result element containing the absolute URI of this file.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.8. p:file-touch

The p:file-touch step updates the modification timestamp of a file.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
timestampxs:dateTime?() 
Errors
Error codeDescription
err:C0136It is a dynamic error if an implementation does not support p:file-touch for a specified scheme.
err:C0137It is a dynamic error if p:file-touch cannot be completed due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist and cannot be created or exists and cannot be accessed.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-touch. It is implementation-defined what other schemes are supported by p:file-touch, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-touch">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="timestamp"as="xs:dateTime?"/>                
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-touch step updates the modification timestamp of the file specified in the href option. If the file specified by href does not exist, an empty file will be created at the given location.

Conformant processors must support URIs whose scheme is file for the href option of p:file-touch. It is implementation-defined what other schemes are supported by p:file-touch, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0136) if an implementation does not support p:file-touch for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-touch 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]. It is a dynamic error (err:XC0137) if p:file-touch cannot be completed due to access restrictions in the environment in which the pipeline is run.

If the timestamp option is set, the file's timestamp is set to this value. Otherwise the file's timestamp is set to the current system's date and time.

If the operation is successful, the step returns a c:result element containing the absolute URI of the file.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, the following error is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist and cannot be created or exists and cannot be accessed.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

3. Step Errors

These steps can raise dynamic errors.

[Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

The following specific errors can be raised by these steps:

err:XC0012

It is a dynamic error if the contents of the directory path are not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:directory-list

err:XC0017

It is a dynamic error if the absolute path does not identify a directory.

See: p:directory-list

err:XC0050

It is a dynamic error the file or directory cannot be copied to the specified location.

See: p:file-copy, p:file-move

err:XC0090

It is a dynamic error if an implementation does not support directory listing for a specified scheme.

See: p:directory-list

err:XC0113

It is a dynamic error if an attempt is made to delete a non-empty directory and the recursive option was set to false.

See: p:file-delete

err:XC0114

It is a dynamic error if the directory referenced by the href option cannot be created.

See: p:file-mkdir

err:XC0115

It is a dynamic error if the resource referenced by the target option is an existing file or other file system object.

See: p:file-move

err:XC0116

It is a dynamic error if the temporary file could not be created.

See: p:file-create-tempfile

err:XC0134

It is a dynamic error if an implementation does not support p:file-info for a specified scheme.

See: p:file-info

err:XC0135

It is a dynamic error if p:file-info is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-info

err:XC0136

It is a dynamic error if an implementation does not support p:file-touch for a specified scheme.

See: p:file-touch

err:XC0137

It is a dynamic error if p:file-touch cannot be completed due to access restrictions in the environment in which the pipeline is run.

See: p:file-touch

err:XC0138

It is a dynamic error if an implementation does not support p:file-create-tempfile for a specified scheme.

See: p:file-create-tempfile

err:XC0139

It is a dynamic error if p:file-create-tempfile cannot be completed due to access restrictions in the environment in which the pipeline is run.

See: p:file-create-tempfile

err:XC0140

It is a dynamic error if an implementation does not support p:file-mkdir for a specified scheme.

See: p:file-mkdir

err:XC0141

It is a dynamic error if p:file-mkdir not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-mkdir

err:XC0142

It is a dynamic error if an implementation does not support p:file-delete for a specified scheme.

See: p:file-delete

err:XC0143

It is a dynamic error if p:file-delete is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-delete

err:XC0144

It is a dynamic error if an implementation does not support p:file-copy for a specified scheme.

See: p:file-copy

err:XC0145

It is a dynamic error if p:file-copy is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-copy

err:XC0147

It is a dynamic error if a specified value is not a valid XPath regular expression.

See: p:directory-list

err:XC0148

It is a dynamic error if an implementation does not support p:file-move for a specified scheme.

See: p:file-move

err:XC0149

It is a dynamic error if p:file-move is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-move

err:XC0157

It is a dynamic error if the href option names a directory, but the target option names a file.

See: p:file-copy

err:XC0158

It is a dynamic error if the href option names a directory, but the target option names a file.

See: p:file-move

A. Conformance

Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

[Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

[Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

A.1. Implementation-defined features

The following features are implementation-defined:

  1. How the file steps behave with respect to special files is implementation-defined. See Section 1, “Introduction”.
  2. Conformant processors must support directory paths whose scheme is file. It is implementation-defined what other schemes are supported by p:directory-list, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.1, “p:directory-list”.
  3. Any file or directory determined to be special by the p:directory-list step may be output using a c:other element but the criteria for marking a file as special are implementation-defined. See Section 2.1, “p:directory-list”.
  4. The precise meaning of the detailed properties are implementation-defined and may vary according to the URI scheme of the path. See Section 2.1, “p:directory-list”.
  5. Any other attributes on c:file, c:directory, or c:other are implementation-defined See Section 2.1, “p:directory-list”.
  6. Conformant processors must support URIs whose scheme is file for the href and target options of p:file-copy. It is implementation-defined what other schemes are supported by p:file-copy, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.2, “p:file-copy”.
  7. Conformant processors must support URIs whose scheme is file for the href option of p:file-delete. It is implementation-defined what other schemes are supported by p:file-delete, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.3, “p:file-delete”.
  8. Conformant processors must support URIs whose scheme is file for the href option of p:file-info. It is implementation-defined what other schemes are supported by p:file-info, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.4, “p:file-info”.
  9. Conformant processors must support URIs whose scheme is file for the href option of p:file-mkdir. It is implementation-defined what other schemes are supported by p:file-mkdir, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.5, “p:file-mkdir”.
  10. Conformant processors must support URIs whose scheme is file for the href and target options of p:file-move. It is implementation-defined what other schemes are supported by p:file-move, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.6, “p:file-move”.
  11. Conformant processors must support URIs whose scheme is file for the href option of p:file-create-tempfile. It is implementation-defined what other schemes are supported by p:file-create-tempfile, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.7, “p:file-create-tempfile”.
  12. Conformant processors must support URIs whose scheme is file for the href option of p:file-touch. It is implementation-defined what other schemes are supported by p:file-touch, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.8, “p:file-touch”.

B. References

[XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

[XProc 3.0 Steps] XProc 3.0 Steps: An Introduction. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

[XPath and XQuery Functions and Operators 3.1] XPath and XQuery Functions and Operators 3.1. Michael Kay, editor. W3C Recommendation. 21 March 2017

[RFC 3986] RFC 3986: Uniform Resource Identifier (URI): General Syntax. T. Berners-Lee, R. Fielding, and L. Masinter, editors. Internet Engineering Task Force. January, 2005.

C. Glossary

dynamic error

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

implementation-defined

An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

implementation-dependent

An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

D. Change log

This appendix catalogs recent non-editorial changes.

  1. Improved the description of include filter processing in p:directory-list.

E. Ancillary files

This specification includes by reference a number of ancillary files.

steps.xpl

An XProc step library for the declared steps.

\ No newline at end of file +

XProc 3.0: file steps

Draft Community Group Report

Editor's Draft at (build 4546)
Latest editor’s draft:
https://spec.xproc.org/master/head/file/
Editors:
Norman Walsh
Achim Berndzen
Gerrit Imsieke
Erik Siegel
Participate:
GitHub xproc/3.0-steps
Report an issue
Changes:
Diff against current “status quo” draft
Commits for this specification

This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: file steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Abstract

This specification describes the file related steps for XProc 3.0: An XML Pipeline Language.

Status of this Document

This document is an editor's draft that has no official standing.

This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

1. Introduction

This specification describes the file related XProc steps. A machine-readable description of these steps may be found in steps.xpl.

Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

Some filesystems and some operating systems support “special” files. These may be interfaces to underlying block or character devices, or represent file system features such as linking two filenames so that they point to the same data. On many filesystems on Unix(-derived) operating systems, the files /dev/null, /dev/urandom, and /dev/zero are special, as are hard and soft symbolic links. Windows and Mac filesystems also support special files and other linking mechanisms.

How the file steps behave with respect to special files is implementation-defined. It may be an error to attempt to access them, or they may be ignored by some or all steps.

2. Step library

2.1. p:directory-list

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

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
pathxs:anyURI ✔ 
detailedxs:booleanfalse() 
exclude-filterxs:string*() 
include-filterxs:string*() 
max-depthxs:string?'1' 
override-content-typesarray(array(xs:string))?() 
Errors
Error codeDescription
err:C0012It is a dynamic error if the contents of the directory path are not available to the step due to access restrictions in the environment in which the pipeline is run.
err:C0017It is a dynamic error if the absolute path does not identify a directory.
err:C0090It is a dynamic error if an implementation does not support directory listing for a specified scheme.
err:C0147It is a dynamic error if a specified value is not a valid XPath regular expression.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant 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.
DefinedAny file or directory determined to be special by the p:directory-list step may be output using a c:other element but the criteria for marking a file as special are implementation-defined.
DefinedThe precise meaning of the detailed properties are implementation-defined and may vary according to the URI scheme of the path.
DefinedAny other attributes on c:file, c:directory, or c:other are implementation-defined
Declaration

<p:declare-steptype="p:directory-list">
     <p:outputport="result"content-types="application/xml"/>
     <p:optionname="path"required="true"as="xs:anyURI"/>        
     <p:optionname="detailed"as="xs:boolean"select="false()"/>  
     <p:optionname="max-depth"as="xs:string?"select="'1'"/>     
     <p:optionname="include-filter"as="xs:string*"/>             
     <p:optionname="exclude-filter"as="xs:string*"/>             
     <p:optionname="override-content-types"as="array(array(xs:string))?"/>
</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.It is a dynamic error (err:XC0090) if an implementation does not support directory listing for a specified scheme.

If path is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:directory-list 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]. 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 the detailed option is true, the pipeline author is requesting additional information about the matching entries, see the section called “Directory list details”.

The max-depth option may contain either the string “unbounded” or a string that may be cast to a non-negative integer. An integer value of 0 means that only information about the directory that is given in the path option is returned. A max-depth of 1, which is the default, will effect that also information about the top-level directory’s immediate children will be included. For larger values of max-depth, also the content of directories will be considered recursively up to the maximum depth, and it will be included as children of the corresponding c:directory elements.

If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions 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 a specified value is not a valid XPath regular expression.

The regular expressions will be matched against an item’s file system path relative to the top-level path that was given in the path option. If the item is a directory, a trailing slash will be appended. The matching is done unanchored: it is a match if the regular expression matches part of the relative item’s file system path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path, $regular-expression).

Examples: A file file.txt in the directory specified by path will remain file.txt, a relative path dir1/file.txt will remain dir1/file.txt, while a relative path dir1/dir2 will become dir1/dir2/ if dir2 is a directory.

Regular expressions that match a/a/b/file.txt are, for example, ^(\w+/){2,3}.+\.txt$, a/a/b/, or /file\.[^/]+$.

If any include-filter pattern matches the slash-augmented relative path, the entry is included in the output. Matching a directory doesn’t automatically include the contents of the directory or its descendants; to be included, each individual entry must match an include filter. For example, the filter regex ^dir/ will match a directory and its content, but ^dir/$ won’t.

Although matching a directory doesn’t automatically include its entries, matching an entry does automatically include all of its ancestors (back to the initial directory). This assures that the hierarchy of the XML elements matches the hierarchy of the filesystem. When ancestors are included this way, none of their other entires are included unless they match an include filter.

For a file a/a/b/file.txt below the initial directory /home/jane, this output will be produced, omitting content that might be present in the intermediate directories:

<c:directory xml:base="file:///home/jane/" name="jane"> <c:directory xml:base="a/" name="a"> <c:directory xml:base="a/" name="a"> <c:directory xml:base="b/" name="b"> <c:file xml:base="file.txt" name="file.txt"/> </c:directory> </c:directory> </c:directory> </c:directory>

If the exclude-filter pattern matches the slash-augmented relative path, the entry (and all of its content in case of a directory) is excluded in the output.

If both options are provided, the include filter is processed first, then the exclude filter. As a result, an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.

If no include-filter is given, that is, if include-filter is an empty sequence, any item will be included in the result (unless it is excluded by exclude-filter).

Note

There is no way to specify a list of values using attribute value templates. If the option shortcut syntax is used to provide the include-filter or exclude-filter option, it will consist of a single regular expression. To specify a list of regular expressions, you must use the p:with-option syntax.

The override-content-types option can be used to partially override the content-type determination mechanism. This works just like with the override-content-types option of p:archive-manifest and p:unarchive (see Overriding content types in XProc 3.0+: Standard Step Library), except that the regular expression matching is done against the paths as used for the matching of the include-filter and exclude-filter options.

The result document produced for the specified directory path has a c:directory document element whose base URI, attached as an xml:base attribute, is the absolute directory path (expressed as a URI that ends in a slash) and whose name attribute (without a trailing slash) is the last segment of the directory path. The same base URI is attached as the resulting document’s base-uri property and, accordingly, as its document node’s base URI.

<c:directory
  name = string
  size? = integer
  readable? = boolean
  writable? = boolean
  last-modified? = dateTime
  hidden? = boolean>
    (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 and subject to the rules that are imposed by the max-depth, include-filter, and exclude-filter options, a c:file, a c:directory, or a c:other element is produced, as follows:

  • A c:directory is produced for each subdirectory not determined to be special. Depending on the values of the three options, it may contain child elements for the directory’s content.

  • A c:file is produced for each file not determined to be special.

    <c:file
      name = string
      size? = integer
      readable? = boolean
      writable? = boolean
      last-modified? = dateTime
      hidden? = boolean
      content-type? = ContentType />

  • Any file or directory determined to be special by the p:directory-list step may be output using a c:other element but the criteria for marking a file as special are implementation-defined.

    <c:other
      name = string
      size? = integer
      readable? = boolean
      writable? = boolean
      last-modified? = dateTime
      hidden? = boolean />

Each of the elements c:file, c:directory, and c:other has a name attribute, whose value is a relative IRI reference, giving the (local) file or directory name.

Each of these element also contains the corresponding resource’s URI in an xml:base attribute, which may be a relative URI for any but the top-level c:directory element. In the case of c:directory, it must end in a trailing slash. This way, users will always be able to compute the absolute URI for any of these elements by applying fn:base-uri() to it.

Directory list details

If detailed is false, then only the name and xml:base attributes are expected on c:file, c:directory, or c:other elements.

If detailed is true, then the pipeline author is expecting additional details about each entry. The following attributes should be provided by the implementation:

content-type

The content-type attribute contains the content type of the respective file. The value “application/octet-stream” will be used if the processor is not able to identify another content type.

readable

“true” if the entry is readable.

writable

“true” if the entry is writable.

hidden

“true” if the entry is hidden.

last-modified

The last modification time of the entry, expressed as a lexical xs:dateTime in UTC.

size

The size of the entry in bytes.

The precise meaning of the detailed properties are implementation-defined and may vary according to the URI scheme of the path. If the value of an attribute is “false” or if it has no meaningful value, the attribute may be omitted.

Any other attributes on c:file, c:directory, or c:other are implementation-defined, but they must be in a namespace.

Document properties

Besides the content-type property, the resulting document has a base-uri. Its value is identical to the top-level element’s xml:base attribute, that is, to the directory’s URI.

2.2. p:file-copy

The p:file-copy step copies a file or a directory to a given target.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
targetxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
overwritexs:booleantrue() 
Errors
Error codeDescription
err:C0050It is a dynamic error the file or directory cannot be copied to the specified location.
err:C0144It is a dynamic error if an implementation does not support p:file-copy for a specified scheme.
err:C0145It is a dynamic error if p:file-copy is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:C0157It is a dynamic error if the href option names a directory, but the target option names a file.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href and target options of p:file-copy. It is implementation-defined what other schemes are supported by p:file-copy, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-copy">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="target"required="true"as="xs:anyURI"/>      
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
     <p:optionname="overwrite"as="xs:boolean"select="true()"/>  
</p:declare-step>

The p:file-copy step copies the file or directory named in href to the new position specified in target. Any non existent directory contained in target will be created before copying starts. If the target is a directory, the step attempts to copy the file or directory into that directory, preserving its base name. It is a dynamic error (err:XC0157) if the href option names a directory, but the target option names a file.

If the overwrite evaluates to false, no existing file will be changed.

Conformant processors must support URIs whose scheme is file for the href and target options of p:file-copy. It is implementation-defined what other schemes are supported by p:file-copy, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0144) if an implementation does not support p:file-copy for a specified scheme.

If href or target are relative, they are made absolute against the base URI of the element on which they are specified (p:with-option or p:file-copy 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]. It is a dynamic error (err:XC0145) if p:file-copy is not available to the step due to access restrictions in the environment in which the pipeline is run.

If no error occurs, the step returns a c:result element containing the absolute URI of the target.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error. In the case of a recursive copy, processing stops at the first error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.

  • It is a dynamic error (err:XC0050) the file or directory cannot be copied to the specified location.

Copying directories

If href identifies a directory and target also identifies a directory, or does not exist, then the p:file-copy step attempts to copy the entire directory tree identified by href: the directory and all of its descendants.

In this case:

  • If fail-on-error is false and an error occurs, no further copying is attempted after the first error is detected.

  • If overwrite is true, err:XC0157 does not apply to descendants. A directory under href may replace a file with the corresponding name under target.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.3. p:file-delete

The p:file-delete step deletes a file or a directory.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
recursivexs:booleanfalse() 
Errors
Error codeDescription
err:C0113It is a dynamic error if an attempt is made to delete a non-empty directory and the recursive option was set to false.
err:C0142It is a dynamic error if an implementation does not support p:file-delete for a specified scheme.
err:C0143It is a dynamic error if p:file-delete is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option cannot be accessed or is not a file or directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-delete. It is implementation-defined what other schemes are supported by p:file-delete, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-delete">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="recursive"as="xs:boolean"select="false()"/> 
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-delete step attempts to delete an existing file or directory named in href. If the named file or directory does not exist, the step just returns a c:result element as described below.

Conformant processors must support URIs whose scheme is file for the href option of p:file-delete. It is implementation-defined what other schemes are supported by p:file-delete, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0142) if an implementation does not support p:file-delete for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-delete 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]. It is a dynamic error (err:XC0143) if p:file-delete is not available to the step due to access restrictions in the environment in which the pipeline is run.

If href specifies a directory, it can only be deleted if the recursive option is true or if the specified directory is empty.

The step returns a c:result element containing the absolute URI of the file or directory.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option cannot be accessed or is not a file or directory.

  • It is a dynamic error (err:XC0113) if an attempt is made to delete a non-empty directory and the recursive option was set to false.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.4. p:file-info

The p:file-info step returns information about a file, directory or other file system object.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
override-content-typesarray(array(xs:string))?() 
Errors
Error codeDescription
err:C0134It is a dynamic error if an implementation does not support p:file-info for a specified scheme.
err:C0135It is a dynamic error if p:file-info is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file, directory or other file system object.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-info. It is implementation-defined what other schemes are supported by p:file-info, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-info">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
     <p:optionname="override-content-types"as="array(array(xs:string))?"/>
</p:declare-step>

The p:file-info step returns information about the file, directory or other file system object named in the href option.

Conformant processors must support URIs whose scheme is file for the href option of p:file-info. It is implementation-defined what other schemes are supported by p:file-info, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0134) if an implementation does not support p:file-info for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-info 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]. It is a dynamic error (err:XC0135) if p:file-info is not available to the step due to access restrictions in the environment in which the pipeline is run.

If the href option is a file: URI, the step returns:

  • If href option references a file: A c:file element with standard attributes (see below).

  • If href option references a directory: A c:directory element with standard attributes (see below).

  • If href option references any other file system object: Implementation defined (for example an c:other or c:device element). It is advised to use the standard attributes (see below) if applicable.

The override-content-types option can be used to partially override the content-type determination mechanism for files. This works just like with the override-content-types option of p:archive-manifest and p:unarchive (see Overriding content types in XProc 3.0+: Standard Step Library), except that the regular expression matching is done against the absolute URI of the file.

Each of the elements c:file, c:directory, and c:other has a name attribute, whose value is a relative IRI reference, giving the (local) file or directory name.

The following attributes are standard on a returned c:file or c:directory element. All attributes are optional and must be absent if not applicable. Additional implementation-defined attributes may be present, but they must be in a namespace.

AttributeTypeDescription
readablexs:booleantrue if the object is readable.
writablexs:booleantrue if the object file is writable.
hiddenxs:booleantrue if the object is hidden.
last-modifiedxs:dateTimeThe last modification time of the object expressed in UTC.
sizexs:integerThe size of the object in bytes.
content-typexs:stringThe content type, if the object is a file.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file, directory or other file system object.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.5. p:file-mkdir

The p:file-mkdir step creates a directory.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
Errors
Error codeDescription
err:C0114It is a dynamic error if the directory referenced by the href option cannot be created.
err:C0140It is a dynamic error if an implementation does not support p:file-mkdir for a specified scheme.
err:C0141It is a dynamic error if p:file-mkdir not available to the step due to access restrictions in the environment in which the pipeline is run.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-mkdir. It is implementation-defined what other schemes are supported by p:file-mkdir, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-mkdir">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-mkdir create the directory named in the href option. If this includes more than one directory component, all of the intermediate components are created. If the directory already exists the step just returns the c:result element as described below. The path separator is implementation-defined.

Conformant processors must support URIs whose scheme is file for the href option of p:file-mkdir. It is implementation-defined what other schemes are supported by p:file-mkdir, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0140) if an implementation does not support p:file-mkdir for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-mkdir 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]. It is a dynamic error (err:XC0141) if p:file-mkdir not available to the step due to access restrictions in the environment in which the pipeline is run.

The step returns a c:result element containing the absolute URI of the directory.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, the following error is raised:

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.6. p:file-move

The p:file-move step moves a file or directory.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
targetxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
Errors
Error codeDescription
err:C0050It is a dynamic error if the directory cannot be moved to the specified location.
err:C0115It is a dynamic error if the resource referenced by the target option is an existing file or other file system object.
err:C0148It is a dynamic error if an implementation does not support p:file-move for a specified scheme.
err:C0149It is a dynamic error if p:file-move is not available to the step due to access restrictions in the environment in which the pipeline is run.
err:C0158It is a dynamic error if the href option names a directory, but the target option names a file.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href and target options of p:file-move. It is implementation-defined what other schemes are supported by p:file-move, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-move">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="target"required="true"as="xs:anyURI"/>      
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-move step moves the file or directory named in href to the new location specified in target. If the target option specifies an existing directory, the step attempts to move the file or directory into that directory, preserving its base name. It is a dynamic error (err:XC0158) if the href option names a directory, but the target option names a file.

Conformant processors must support URIs whose scheme is file for the href and target options of p:file-move. It is implementation-defined what other schemes are supported by p:file-move, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0148) if an implementation does not support p:file-move for a specified scheme.

If href or target are relative, they are made absolute against the base URI of the element on which they are specified (p:with-option or p:file-move 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]. It is a dynamic error (err:XC0149) if p:file-move is not available to the step due to access restrictions in the environment in which the pipeline is run.

If the href option specifies a device or other special kind of object, the results are implementation-defined.

If the move is successful, the step returns a c:result element containing the absolute URI of the target.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file or directory.

  • It is a dynamic error (err:XC0115) if the resource referenced by the target option is an existing file or other file system object.

  • It is a dynamic error (err:XC0050) if the directory cannot be moved to the specified location.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.7. p:file-create-tempfile

The p:file-create-tempfile step creates a temporary file.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault value
delete-on-exitxs:booleanfalse()
fail-on-errorxs:booleantrue()
hrefxs:anyURI?()
prefixxs:string?()
suffixxs:string?()
Errors
Error codeDescription
err:C0116It is a dynamic error if the temporary file could not be created.
err:C0138It is a dynamic error if an implementation does not support p:file-create-tempfile for a specified scheme.
err:C0139It is a dynamic error if p:file-create-tempfile cannot be completed due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a directory.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-create-tempfile. It is implementation-defined what other schemes are supported by p:file-create-tempfile, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-create-tempfile">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"as="xs:anyURI?"/>                       
     <p:optionname="suffix"as="xs:string?"/>                     
     <p:optionname="prefix"as="xs:string?"/>                     
     <p:optionname="delete-on-exit"as="xs:boolean"select="false()"/>
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-create-tempfile creates a temporary file. The temporary file is guaranteed not to already exist when the step is called.

If the href option is specified it must be the URI of an existing directory. The temporary file is created here. If there is no href option specified the location of the temporary file is implementation defined, usually the operating system's default location for temporary files.

Conformant processors must support URIs whose scheme is file for the href option of p:file-create-tempfile. It is implementation-defined what other schemes are supported by p:file-create-tempfile, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0138) if an implementation does not support p:file-create-tempfile for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-create-tempfile 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]. It is a dynamic error (err:XC0139) if p:file-create-tempfile cannot be completed due to access restrictions in the environment in which the pipeline is run.

If the prefix option is specified, the filename will begin with that prefix. If the suffix option is specified, the filename will end with that suffix.

If the delete-on-exit option is true, an attempt will be made to automatically delete the temporary file when the processor terminates the pipeline. No error will be raised if this is unsuccessful.

If the temporary file creation is successful, the step returns a c:result element containing the absolute URI of this file.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, one of the following errors is raised:

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

2.8. p:file-touch

The p:file-touch step updates the modification timestamp of a file.

Summary

Output portPrimarySequenceContent types
result✔  application/xml 
Option nameTypeDefault valueRequired
hrefxs:anyURI ✔ 
fail-on-errorxs:booleantrue() 
timestampxs:dateTime?() 
Errors
Error codeDescription
err:C0136It is a dynamic error if an implementation does not support p:file-touch for a specified scheme.
err:C0137It is a dynamic error if p:file-touch cannot be completed due to access restrictions in the environment in which the pipeline is run.
err:D0011It is a dynamic error if the resource referenced by the href option does not exist and cannot be created or exists and cannot be accessed.
err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
Implementation details
ImplementationDescription
DefinedConformant processors must support URIs whose scheme is file for the href option of p:file-touch. It is implementation-defined what other schemes are supported by p:file-touch, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.
Declaration

<p:declare-steptype="p:file-touch">
     <p:outputport="result"primary="true"content-types="application/xml"/>
     <p:optionname="href"required="true"as="xs:anyURI"/>        
     <p:optionname="timestamp"as="xs:dateTime?"/>                
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

The p:file-touch step updates the modification timestamp of the file specified in the href option. If the file specified by href does not exist, an empty file will be created at the given location.

Conformant processors must support URIs whose scheme is file for the href option of p:file-touch. It is implementation-defined what other schemes are supported by p:file-touch, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes.It is a dynamic error (err:XC0136) if an implementation does not support p:file-touch for a specified scheme.

If href is relative, it is made absolute against the base URI of the element on which it is specified (p:with-option or p:file-touch 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]. It is a dynamic error (err:XC0137) if p:file-touch cannot be completed due to access restrictions in the environment in which the pipeline is run.

If the timestamp option is set, the file's timestamp is set to this value. Otherwise the file's timestamp is set to the current system's date and time.

If the operation is successful, the step returns a c:result element containing the absolute URI of the file.

If an error occurs and fail-on-error is false, the step returns a c:error element which may contain additional, implementation-defined, information about the nature of the error.

If an error occurs and fail-on-error is true, the following error is raised:

  • It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist and cannot be created or exists and cannot be accessed.

Document properties

The resulting document has no properties apart from content-type. In particular, it has no base-uri.

3. Step Errors

These steps can raise dynamic errors.

[Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

The following specific errors can be raised by these steps:

err:XC0012

It is a dynamic error if the contents of the directory path are not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:directory-list

err:XC0017

It is a dynamic error if the absolute path does not identify a directory.

See: p:directory-list

err:XC0050

It is a dynamic error the file or directory cannot be copied to the specified location.

See: p:file-copy, p:file-move

err:XC0090

It is a dynamic error if an implementation does not support directory listing for a specified scheme.

See: p:directory-list

err:XC0113

It is a dynamic error if an attempt is made to delete a non-empty directory and the recursive option was set to false.

See: p:file-delete

err:XC0114

It is a dynamic error if the directory referenced by the href option cannot be created.

See: p:file-mkdir

err:XC0115

It is a dynamic error if the resource referenced by the target option is an existing file or other file system object.

See: p:file-move

err:XC0116

It is a dynamic error if the temporary file could not be created.

See: p:file-create-tempfile

err:XC0134

It is a dynamic error if an implementation does not support p:file-info for a specified scheme.

See: p:file-info

err:XC0135

It is a dynamic error if p:file-info is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-info

err:XC0136

It is a dynamic error if an implementation does not support p:file-touch for a specified scheme.

See: p:file-touch

err:XC0137

It is a dynamic error if p:file-touch cannot be completed due to access restrictions in the environment in which the pipeline is run.

See: p:file-touch

err:XC0138

It is a dynamic error if an implementation does not support p:file-create-tempfile for a specified scheme.

See: p:file-create-tempfile

err:XC0139

It is a dynamic error if p:file-create-tempfile cannot be completed due to access restrictions in the environment in which the pipeline is run.

See: p:file-create-tempfile

err:XC0140

It is a dynamic error if an implementation does not support p:file-mkdir for a specified scheme.

See: p:file-mkdir

err:XC0141

It is a dynamic error if p:file-mkdir not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-mkdir

err:XC0142

It is a dynamic error if an implementation does not support p:file-delete for a specified scheme.

See: p:file-delete

err:XC0143

It is a dynamic error if p:file-delete is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-delete

err:XC0144

It is a dynamic error if an implementation does not support p:file-copy for a specified scheme.

See: p:file-copy

err:XC0145

It is a dynamic error if p:file-copy is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-copy

err:XC0147

It is a dynamic error if a specified value is not a valid XPath regular expression.

See: p:directory-list

err:XC0148

It is a dynamic error if an implementation does not support p:file-move for a specified scheme.

See: p:file-move

err:XC0149

It is a dynamic error if p:file-move is not available to the step due to access restrictions in the environment in which the pipeline is run.

See: p:file-move

err:XC0157

It is a dynamic error if the href option names a directory, but the target option names a file.

See: p:file-copy

err:XC0158

It is a dynamic error if the href option names a directory, but the target option names a file.

See: p:file-move

A. Conformance

Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

[Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

[Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

A.1. Implementation-defined features

The following features are implementation-defined:

  1. How the file steps behave with respect to special files is implementation-defined. See Section 1, “Introduction”.
  2. Conformant processors must support directory paths whose scheme is file. It is implementation-defined what other schemes are supported by p:directory-list, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.1, “p:directory-list”.
  3. Any file or directory determined to be special by the p:directory-list step may be output using a c:other element but the criteria for marking a file as special are implementation-defined. See Section 2.1, “p:directory-list”.
  4. The precise meaning of the detailed properties are implementation-defined and may vary according to the URI scheme of the path. See Section 2.1, “p:directory-list”.
  5. Any other attributes on c:file, c:directory, or c:other are implementation-defined See Section 2.1, “p:directory-list”.
  6. Conformant processors must support URIs whose scheme is file for the href and target options of p:file-copy. It is implementation-defined what other schemes are supported by p:file-copy, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.2, “p:file-copy”.
  7. Conformant processors must support URIs whose scheme is file for the href option of p:file-delete. It is implementation-defined what other schemes are supported by p:file-delete, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.3, “p:file-delete”.
  8. Conformant processors must support URIs whose scheme is file for the href option of p:file-info. It is implementation-defined what other schemes are supported by p:file-info, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.4, “p:file-info”.
  9. Conformant processors must support URIs whose scheme is file for the href option of p:file-mkdir. It is implementation-defined what other schemes are supported by p:file-mkdir, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.5, “p:file-mkdir”.
  10. Conformant processors must support URIs whose scheme is file for the href and target options of p:file-move. It is implementation-defined what other schemes are supported by p:file-move, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.6, “p:file-move”.
  11. Conformant processors must support URIs whose scheme is file for the href option of p:file-create-tempfile. It is implementation-defined what other schemes are supported by p:file-create-tempfile, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.7, “p:file-create-tempfile”.
  12. Conformant processors must support URIs whose scheme is file for the href option of p:file-touch. It is implementation-defined what other schemes are supported by p:file-touch, and what the interpretation of ‘directory’, ‘file’ and ‘contents’ is for those schemes. See Section 2.8, “p:file-touch”.

B. References

[XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

[XProc 3.0 Steps] XProc 3.0 Steps: An Introduction. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

[XPath and XQuery Functions and Operators 3.1] XPath and XQuery Functions and Operators 3.1. Michael Kay, editor. W3C Recommendation. 21 March 2017

[RFC 3986] RFC 3986: Uniform Resource Identifier (URI): General Syntax. T. Berners-Lee, R. Fielding, and L. Masinter, editors. Internet Engineering Task Force. January, 2005.

C. Glossary

dynamic error

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

implementation-defined

An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

implementation-dependent

An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

D. Change log

This appendix catalogs recent non-editorial changes.

  1. Improved the description of include filter processing in p:directory-list.

E. Ancillary files

This specification includes by reference a number of ancillary files.

steps.xpl

An XProc step library for the declared steps.

\ No newline at end of file diff --git a/master/head/file/index.html b/master/head/file/index.html index 0cf10cec2..895c17c7f 100644 --- a/master/head/file/index.html +++ b/master/head/file/index.html @@ -1,4 +1,4 @@ -XProc 3.0: file steps

XProc 3.0: file steps

Draft Community Group Report

Editor's Draft at (build 47)
Latest editor’s draft:
https://spec.xproc.org/master/head/file/
Editors:
Norman Walsh
Achim Berndzen
Gerrit Imsieke
Erik Siegel
Participate:
GitHub xproc/3.0-steps
Report an issue
Changes:
Diff against current “status quo” draft
Commits for this specification

This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: file steps specification, published by the XProc Next Community Group under the W3C +XProc 3.0: file steps

XProc 3.0: file steps

Draft Community Group Report

Editor's Draft at (build 46)
Latest editor’s draft:
https://spec.xproc.org/master/head/file/
Editors:
Norman Walsh
Achim Berndzen
Gerrit Imsieke
Erik Siegel
Participate:
GitHub xproc/3.0-steps
Report an issue
Changes:
Diff against current “status quo” draft
Commits for this specification

This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: file steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Abstract

This specification describes the file related steps for diff --git a/master/head/ixml/diff.html b/master/head/ixml/diff.html index d2b14a7f2..f0c873b11 100644 --- a/master/head/ixml/diff.html +++ b/master/head/ixml/diff.html @@ -15,4 +15,4 @@ Previous Next -

XProc 3.0: Invisible XML

Draft Community Group Report

Editor's Draft at (build 4547)
Latest editor’s draft:
https://spec.xproc.org/master/head/ixml/
Editor:
Norman Walsh
Participate:
GitHub xproc/3.0-steps
Report an issue
Changes:
Diff against current “status quo” draft
Commits for this specification

This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

Copyright © 2021 the Contributors to the XProc 3.0: Invisible XML specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Abstract

This specification describes the p:ixml step for XProc 3.0: An XML Pipeline Language.

Status of this Document

This document is an editor's draft that has no official standing.

This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

1. Introduction

This specification describes the p:ixml XProc step. A machine-readable description of this step may be found in steps.xpl.

Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

2. p:ixml

The p:ixml step performs Invisible XML processing per [Invisible XML]. It transforms a non-XML input into XML by applying the specified Invisible XML grammar.

Summary

Input portPrimarySequenceContent types
grammar ✔ text xml 
source✔  any -xml -html 
Output portPrimarySequenceContent types
result✔ ✔ any 
Option nameTypeDefault value
fail-on-errorxs:booleantrue()
parametersmap(xs:QName, item()*)?()
Errors
Error codeDescription
err:C0205It is a dynamic error if the source document cannot be parsed by the provided grammar.
err:C0211It is a dynamic error if more than one document appears on the grammar port.
err:C0212It is a dynamic error if the grammar provided is not a valid Invisible XML grammar.
Implementation details
ImplementationDescription
DefinedIt is implementation-defined if other result formats are possible.
DefinedThe parameters are implementation-defined.
Declaration

<p:declare-steptype="p:ixml">
     <p:inputport="grammar"sequence="true"content-types="text xml"/>
     <p:inputport="source"primary="true"content-types="any -xml -html"/>
     <p:outputport="result"sequence="true"content-types="any"/>
     <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
     <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
</p:declare-step>

If no grammar is provided on the grammar port, the grammar for Invisible XML is assumed. If an XML or text grammar is provided it must be an Invisible XML grammar. It is a dynamic error (err:XC0212) if the grammar provided is not a valid Invisible XML grammar. It is a dynamic error (err:XC0211) if more than one document appears on the grammar port.

The source to be processed is usually text, but there’s nothing in principle that prevents an Invisible XML grammar from applying to an arbitrary sequence of characters.

The resultshould be XML. It is implementation-defined if other result formats are possible. (An implementation might, for example, provide a way for the p:ixml step to compile an Invisible XML grammar into some format that can be processed more efficiently.)

  • The parameters are implementation-defined. An implementation might provide parameters to select among different ambiguous parses or choose alternate representations.

  • If fail-on-error is true, the step will raise an error if the input cannot be parsed by the grammar. It is a dynamic error (err:XC0205) if the source document cannot be parsed by the provided grammar. If fail-on-error is false, no error will be raised.

    The Invisible XML specification provides a mechanism to identify failed parses in the output.

2.1. Examples

Several examples demonstrate features of the step.

2.1.1. Parsing an Invisible XML grammar

In this first example, no grammar is provided, so the pipeline parses the Invisible XML grammar on the source port and returns its XML representation:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml> <p:with-input port="grammar"><p:empty /></p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain"> date: s?, day, s, month, (s, year)? . -s: -" "+ . day: digit, digit? . -digit: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9". month: "January"; "February"; "March"; "April"; "May"; "June"; "July"; "August"; "September"; "October"; "November"; "December". year: (digit, digit)?, digit, digit . </p:inline> </p:with-input> </p:ixml> </p:declare-step>

This would produce an XML version of the grammar:

<ixml> <rule name="date"> <alt> <option> <nonterminal name="s"/> </option> <nonterminal name="day"/> <nonterminal name="s"/> <nonterminal name="month"/> <option> <alts> <alt> <nonterminal name="s"/> <nonterminal name="year"/> </alt> </alts> </option> </alt> </rule> <!-- … remaining rules elided for brevity … --> </ixml>

2.1.2. Parsing a date

If the grammar is provided on the grammar port, it can be used to parse input, the string “31 December 2021” in this case:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml> <p:with-input port="grammar"> <p:inline content-type="text/plain"> date: s?, day, s, month, (s, year)? . -s: -" "+ . day: digit, digit? . -digit: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9". month: "January"; "February"; "March"; "April"; "May"; "June"; "July"; "August"; "September"; "October"; "November"; "December". year: (digit, digit)?, digit, digit . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">31 December 2021</p:inline> </p:with-input> </p:ixml> </p:declare-step>

This would produce an XML version of the date:

<date><day>31</day><month>December</month><year>2021</year></date>

2.1.3. Failed parses

If a parse fails, the implementation must indicate this, but it may also provide information about where the processing failed.

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml fail-on-error="false"> <p:with-input port="grammar"> <p:inline content-type="text/plain"> date: s?, day, s, month, (s, year)? . -s: -" "+ . day: digit, digit? . -digit: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9". month: "January"; "February"; "March"; "April"; "May"; "June"; "July"; "August"; "September"; "October"; "November"; "December". year: (digit, digit)?, digit, digit . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">31 Mumble 2021</p:inline> </p:with-input> </p:ixml> </p:declare-step>

Here the output might be something like this:

<error xmlns:ixml="http://invisiblexml.org/NS" xmlns:ex="http://example.com/NS" ixml:state="failed" ex:lastChar="4"> <parse> month -> • M a r c h month -> M • a r c h </parse> <parse> month -> • M a y month -> M • a y </parse> </error>

In the case of failure, Invisible XML requires that the ixml:state attribute appear on the root element containing the token “failed”. It doesn’t constrain the implementation’s choice of the root element or the content of the document.

2.1.4. Ambiguous parses

An ixml grammar may be ambiguous. In the grammar below, there are three different possible ways to parse the input. By default, one of them is returned. 

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml> <p:with-input port="grammar"> <p:inline content-type="text/plain"> letters: X, (A; B; C) . A: digits . B: digits . C: digits . X: "a" . digits: ["0"-"9"]+ . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">a123</p:inline> </p:with-input> </p:ixml> </p:declare-step>

This might return any one of these parses:

<letters ixml:state="ambiguous" xmlns:ixml="http://invisiblexml.org/NS"><X>a</X><C><digits>123</digits></C></letters>

or

<letters ixml:state="ambiguous" xmlns:ixml="http://invisiblexml.org/NS"><X>a</X><A><digits>123</digits></A></letters>

or

<letters ixml:state="ambiguous" xmlns:ixml="http://invisiblexml.org/NS"><X>a</X><B><digits>123</digits></B></letters>

All are equally correct.

2.1.5. Ambiguous parse selection

An implementation might provide a parameter to allow the author to select a particular parse: 

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:ex="http://example.com/" version="3.0"> <p:output port="result"/> <p:ixml parameters="map{'ex:select':2}"> <p:with-input port="grammar"> <p:inline content-type="text/plain"> letters: X, (A; B; C) . A: digits . B: digits . C: digits . X: "a" . digits: ["0"-"9"]+ . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">a123</p:inline> </p:with-input> </p:ixml> </p:declare-step>

This might return:

<letters ixml:state="ambiguous"><X>a</X><A><digits>123</digits></A></letters>

2.1.6. Multiple ambiguous outputs

Or a processor might provide a parameter to return all of the parses.

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:ex="http://example.com/" version="3.0"> <p:output port="result"/> <p:ixml parameters="map{'ex:select':'all'}"> <p:with-input port="grammar"> <p:inline content-type="text/plain"> letters: X, (A; B; C) . A: digits . B: digits . C: digits . X: "a" . digits: ["0"-"9"]+ . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">a123</p:inline> </p:with-input> </p:ixml> </p:declare-step>

This might return three documents:

<letters ixml:state="ambiguous"><X>a</X><C><digits>123</digits></C></letters> <letters ixml:state="ambiguous"><X>a</X><B><digits>123</digits></B></letters> <letters ixml:state="ambiguous"><X>a</X><A><digits>123</digits></A></letters>

As before, there is nothing standardized about the results in this case.

2.2. Document properties

No document properties are preserved.

3. Step Errors

This step can raise dynamic errors.

[Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

The following errors can be raised by this step:

err:XC0205

It is a dynamic error if the source document cannot be parsed by the provided grammar.

See: p:ixml

err:XC0211

It is a dynamic error if more than one document appears on the grammar port.

See: p:ixml

err:XC0212

It is a dynamic error if the grammar provided is not a valid Invisible XML grammar.

See: p:ixml

A. Conformance

Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

[Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

[Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

A.1. Implementation-defined features

The following features are implementation-defined:

  1. It is implementation-defined if other result formats are possible. See Section 2, “p:ixml”.
  2. The parameters are implementation-defined. See Section 2, “p:ixml”.

A.2. Implementation-dependent features

This step has no implementation-dependent features.

    C. Glossary

    dynamic error

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

    implementation-defined

    An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

    implementation-dependent

    An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

    D. Ancillary files

    This specification includes by reference a number of ancillary files.

    steps.xpl

    An XProc step library for the declared steps.

    \ No newline at end of file +

    XProc 3.0: Invisible XML

    Draft Community Group Report

    Editor's Draft at (build 4546)
    Latest editor’s draft:
    https://spec.xproc.org/master/head/ixml/
    Editor:
    Norman Walsh
    Participate:
    GitHub xproc/3.0-steps
    Report an issue
    Changes:
    Diff against current “status quo” draft
    Commits for this specification

    This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

    Copyright © 2021 the Contributors to the XProc 3.0: Invisible XML specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

    Abstract

    This specification describes the p:ixml step for XProc 3.0: An XML Pipeline Language.

    Status of this Document

    This document is an editor's draft that has no official standing.

    This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

    If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

    1. Introduction

    This specification describes the p:ixml XProc step. A machine-readable description of this step may be found in steps.xpl.

    Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

    2. p:ixml

    The p:ixml step performs Invisible XML processing per [Invisible XML]. It transforms a non-XML input into XML by applying the specified Invisible XML grammar.

    Summary

    Input portPrimarySequenceContent types
    grammar ✔ text xml 
    source✔  any -xml -html 
    Output portPrimarySequenceContent types
    result✔ ✔ any 
    Option nameTypeDefault value
    fail-on-errorxs:booleantrue()
    parametersmap(xs:QName, item()*)?()
    Errors
    Error codeDescription
    err:C0205It is a dynamic error if the source document cannot be parsed by the provided grammar.
    err:C0211It is a dynamic error if more than one document appears on the grammar port.
    err:C0212It is a dynamic error if the grammar provided is not a valid Invisible XML grammar.
    Implementation details
    ImplementationDescription
    DefinedIt is implementation-defined if other result formats are possible.
    DefinedThe parameters are implementation-defined.
    Declaration

    <p:declare-steptype="p:ixml">
         <p:inputport="grammar"sequence="true"content-types="text xml"/>
         <p:inputport="source"primary="true"content-types="any -xml -html"/>
         <p:outputport="result"sequence="true"content-types="any"/>
         <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
         <p:optionname="fail-on-error"as="xs:boolean"select="true()"/>
    </p:declare-step>

    If no grammar is provided on the grammar port, the grammar for Invisible XML is assumed. If an XML or text grammar is provided it must be an Invisible XML grammar. It is a dynamic error (err:XC0212) if the grammar provided is not a valid Invisible XML grammar. It is a dynamic error (err:XC0211) if more than one document appears on the grammar port.

    The source to be processed is usually text, but there’s nothing in principle that prevents an Invisible XML grammar from applying to an arbitrary sequence of characters.

    The resultshould be XML. It is implementation-defined if other result formats are possible. (An implementation might, for example, provide a way for the p:ixml step to compile an Invisible XML grammar into some format that can be processed more efficiently.)

    • The parameters are implementation-defined. An implementation might provide parameters to select among different ambiguous parses or choose alternate representations.

    • If fail-on-error is true, the step will raise an error if the input cannot be parsed by the grammar. It is a dynamic error (err:XC0205) if the source document cannot be parsed by the provided grammar. If fail-on-error is false, no error will be raised.

      The Invisible XML specification provides a mechanism to identify failed parses in the output.

    2.1. Examples

    Several examples demonstrate features of the step.

    2.1.1. Parsing an Invisible XML grammar

    In this first example, no grammar is provided, so the pipeline parses the Invisible XML grammar on the source port and returns its XML representation:

    <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml> <p:with-input port="grammar"><p:empty /></p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain"> date: s?, day, s, month, (s, year)? . -s: -" "+ . day: digit, digit? . -digit: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9". month: "January"; "February"; "March"; "April"; "May"; "June"; "July"; "August"; "September"; "October"; "November"; "December". year: (digit, digit)?, digit, digit . </p:inline> </p:with-input> </p:ixml> </p:declare-step>

    This would produce an XML version of the grammar:

    <ixml> <rule name="date"> <alt> <option> <nonterminal name="s"/> </option> <nonterminal name="day"/> <nonterminal name="s"/> <nonterminal name="month"/> <option> <alts> <alt> <nonterminal name="s"/> <nonterminal name="year"/> </alt> </alts> </option> </alt> </rule> <!-- … remaining rules elided for brevity … --> </ixml>

    2.1.2. Parsing a date

    If the grammar is provided on the grammar port, it can be used to parse input, the string “31 December 2021” in this case:

    <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml> <p:with-input port="grammar"> <p:inline content-type="text/plain"> date: s?, day, s, month, (s, year)? . -s: -" "+ . day: digit, digit? . -digit: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9". month: "January"; "February"; "March"; "April"; "May"; "June"; "July"; "August"; "September"; "October"; "November"; "December". year: (digit, digit)?, digit, digit . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">31 December 2021</p:inline> </p:with-input> </p:ixml> </p:declare-step>

    This would produce an XML version of the date:

    <date><day>31</day><month>December</month><year>2021</year></date>

    2.1.3. Failed parses

    If a parse fails, the implementation must indicate this, but it may also provide information about where the processing failed.

    <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml fail-on-error="false"> <p:with-input port="grammar"> <p:inline content-type="text/plain"> date: s?, day, s, month, (s, year)? . -s: -" "+ . day: digit, digit? . -digit: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9". month: "January"; "February"; "March"; "April"; "May"; "June"; "July"; "August"; "September"; "October"; "November"; "December". year: (digit, digit)?, digit, digit . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">31 Mumble 2021</p:inline> </p:with-input> </p:ixml> </p:declare-step>

    Here the output might be something like this:

    <error xmlns:ixml="http://invisiblexml.org/NS" xmlns:ex="http://example.com/NS" ixml:state="failed" ex:lastChar="4"> <parse> month -> • M a r c h month -> M • a r c h </parse> <parse> month -> • M a y month -> M • a y </parse> </error>

    In the case of failure, Invisible XML requires that the ixml:state attribute appear on the root element containing the token “failed”. It doesn’t constrain the implementation’s choice of the root element or the content of the document.

    2.1.4. Ambiguous parses

    An ixml grammar may be ambiguous. In the grammar below, there are three different possible ways to parse the input. By default, one of them is returned. 

    <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.0"> <p:output port="result"/> <p:ixml> <p:with-input port="grammar"> <p:inline content-type="text/plain"> letters: X, (A; B; C) . A: digits . B: digits . C: digits . X: "a" . digits: ["0"-"9"]+ . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">a123</p:inline> </p:with-input> </p:ixml> </p:declare-step>

    This might return any one of these parses:

    <letters ixml:state="ambiguous" xmlns:ixml="http://invisiblexml.org/NS"><X>a</X><C><digits>123</digits></C></letters>

    or

    <letters ixml:state="ambiguous" xmlns:ixml="http://invisiblexml.org/NS"><X>a</X><A><digits>123</digits></A></letters>

    or

    <letters ixml:state="ambiguous" xmlns:ixml="http://invisiblexml.org/NS"><X>a</X><B><digits>123</digits></B></letters>

    All are equally correct.

    2.1.5. Ambiguous parse selection

    An implementation might provide a parameter to allow the author to select a particular parse: 

    <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:ex="http://example.com/" version="3.0"> <p:output port="result"/> <p:ixml parameters="map{'ex:select':2}"> <p:with-input port="grammar"> <p:inline content-type="text/plain"> letters: X, (A; B; C) . A: digits . B: digits . C: digits . X: "a" . digits: ["0"-"9"]+ . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">a123</p:inline> </p:with-input> </p:ixml> </p:declare-step>

    This might return:

    <letters ixml:state="ambiguous"><X>a</X><A><digits>123</digits></A></letters>

    2.1.6. Multiple ambiguous outputs

    Or a processor might provide a parameter to return all of the parses.

    <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:ex="http://example.com/" version="3.0"> <p:output port="result"/> <p:ixml parameters="map{'ex:select':'all'}"> <p:with-input port="grammar"> <p:inline content-type="text/plain"> letters: X, (A; B; C) . A: digits . B: digits . C: digits . X: "a" . digits: ["0"-"9"]+ . </p:inline> </p:with-input> <p:with-input port="source"> <p:inline content-type="text/plain">a123</p:inline> </p:with-input> </p:ixml> </p:declare-step>

    This might return three documents:

    <letters ixml:state="ambiguous"><X>a</X><C><digits>123</digits></C></letters> <letters ixml:state="ambiguous"><X>a</X><B><digits>123</digits></B></letters> <letters ixml:state="ambiguous"><X>a</X><A><digits>123</digits></A></letters>

    As before, there is nothing standardized about the results in this case.

    2.2. Document properties

    No document properties are preserved.

    3. Step Errors

    This step can raise dynamic errors.

    [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

    If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

    The following errors can be raised by this step:

    err:XC0205

    It is a dynamic error if the source document cannot be parsed by the provided grammar.

    See: p:ixml

    err:XC0211

    It is a dynamic error if more than one document appears on the grammar port.

    See: p:ixml

    err:XC0212

    It is a dynamic error if the grammar provided is not a valid Invisible XML grammar.

    See: p:ixml

    A. Conformance

    Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

    [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

    [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

    A.1. Implementation-defined features

    The following features are implementation-defined:

    1. It is implementation-defined if other result formats are possible. See Section 2, “p:ixml”.
    2. The parameters are implementation-defined. See Section 2, “p:ixml”.

    A.2. Implementation-dependent features

    This step has no implementation-dependent features.

      C. Glossary

      dynamic error

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

      implementation-defined

      An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

      implementation-dependent

      An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.

      \ No newline at end of file diff --git a/master/head/ixml/index.html b/master/head/ixml/index.html index 794ad0a4a..6a89f9488 100644 --- a/master/head/ixml/index.html +++ b/master/head/ixml/index.html @@ -1,4 +1,4 @@ -XProc 3.0: Invisible XML

      XProc 3.0: Invisible XML

      Draft Community Group Report

      Editor's Draft at (build 47)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/ixml/
      Editor:
      Norman Walsh
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2021 the Contributors to the XProc 3.0: Invisible XML specification, published by the XProc Next Community Group under the W3C +XProc 3.0: Invisible XML

      XProc 3.0: Invisible XML

      Draft Community Group Report

      Editor's Draft at (build 46)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/ixml/
      Editor:
      Norman Walsh
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2021 the Contributors to the XProc 3.0: Invisible XML specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:ixml step for diff --git a/master/head/mail/diff.html b/master/head/mail/diff.html index 43eaa6508..9681f24d4 100644 --- a/master/head/mail/diff.html +++ b/master/head/mail/diff.html @@ -15,4 +15,4 @@ Previous Next -

      XProc 3.0: mail steps

      Draft Community Group Report

      Editor's Draft at (build 4547)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/mail/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: mail steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes optional mail related steps for XProc 3.0: An XML Pipeline Language.

      Status of this Document

      This document is an editor's draft that has no official standing.

      This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

      If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

      1. Introduction

      This specification describes optional mail related XProc steps. A machine-readable description of these steps may be found in steps.xpl.

      Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

      2. p:send-mail

      The p:send-mail step sends an email message.

      Summary

      Input portPrimarySequenceContent types
      source✔ ✔ any 
      Output portPrimarySequenceContent types
      result✔  application/xml 
      Option nameTypeDefault value
      authmap(xs:string, item()+)?()
      parametersmap(xs:QName, item()*)?()
      serializationmap(xs:QName,item()*)?()
      Errors
      Error codeDescription
      err:C0159It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.
      err:C0160It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.
      err:C0161It is a dynamic error if the first document on the source port does not conform to the required format.
      err:C0162It is a dynamic error if the email cannot be send.
      Implementation details
      ImplementationDescription
      DefinedOther key value pairs in “auth” are implementation-defined
      DefinedIt is implementation-defined which other key/value pairs in the parameters option are supported.
      DefinedOther key value pairs in “auth” are implementation-defined
      DefinedIf no values for “host” or “port” is specified, it it implementation-defined which server and port is used.
      Declaration

      <p:declare-steptype="p:send-mail">
           <p:inputport="source"sequence="true"content-types="any"/>
           <p:outputport="result"content-types="application/xml"/>
           <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
           <p:optionname="auth"as="map(xs:string, item()+)?"/>         
           <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
      </p:declare-step>

      The first document on the source port is expected to conform to [XML format for mail]. It is a dynamic error (err:XC0161) if the first document on the source port does not conform to the required format. Any additional documents are treated as attachments.

      If the mail was send successfully a single c:result document whose content is “true” appears on the result port. It is a dynamic error (err:XC0162) if the email cannot be send.

      The em:content may contain either text or HTML. To send some other type as the first message body, you must leave the em:content element out of the first document and supply the body as a second document.

      The p:send-mail step has the following options:

      serialization

      The serialization option is used to control the serialization of documents for constructing the mail. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.

      auth

      If the mail service requires an authentication to send mails, these can be supplied using the auth option.

      The following standard keys are defined:

      username (xs:string)

      The username.

      password (xs:string)

      The password.

      Other key value pairs in “auth” are implementation-defined.It is a dynamic error (err:XC0159) if any key in the “auth” map is associated with a value that is not an instance of the required type.

      parameters

      The parameters option can be used to supply additional information for constructing and sending mails. A number of parameters are defined in this specification. It is implementation-defined which other key/value pairs in the parameters option are supported.

      send-authorization (xs:boolean)

      If the key is associated with false no authentication will be used when sending a mail.

      host (xs:string)

      The SMTP server.

      port (xs:unsignedShort)

      The port.

      Other key value pairs in “auth” are implementation-defined.It is a dynamic error (err:XC0160) if any key in the “parameters” map is associated with a value that is not an instance of the required type.

      If no values for “host” or “port” is specified, it it implementation-defined which server and port is used.

      Document properties

      No document properties are preserved.

      3. Step Errors

      These steps can raise dynamic errors.

      [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

      If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

      The following errors can be raised by this step:

      err:XC0159

      It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.

      See: p:send-mail

      err:XC0160

      It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.

      See: p:send-mail

      err:XC0161

      It is a dynamic error if the first document on the source port does not conform to the required format.

      See: p:send-mail

      err:XC0162

      It is a dynamic error if the email cannot be send.

      See: p:send-mail

      A. Conformance

      Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

      [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

      [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

      A.1. Implementation-defined features

      The following features are implementation-defined:

      1. Other key value pairs in “auth” are implementation-defined See Section 2, “p:send-mail”.
      2. It is implementation-defined which other key/value pairs in the parameters option are supported. See Section 2, “p:send-mail”.
      3. Other key value pairs in “auth” are implementation-defined See Section 2, “p:send-mail”.
      4. If no values for “host” or “port” is specified, it it implementation-defined which server and port is used. See Section 2, “p:send-mail”.

      C. Glossary

      dynamic error

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

      implementation-defined

      An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

      implementation-dependent

      An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.

      \ No newline at end of file +

      XProc 3.0: mail steps

      Draft Community Group Report

      Editor's Draft at (build 4546)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/mail/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: mail steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes optional mail related steps for XProc 3.0: An XML Pipeline Language.

      Status of this Document

      This document is an editor's draft that has no official standing.

      This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

      If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

      1. Introduction

      This specification describes optional mail related XProc steps. A machine-readable description of these steps may be found in steps.xpl.

      Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

      2. p:send-mail

      The p:send-mail step sends an email message.

      Summary

      Input portPrimarySequenceContent types
      source✔ ✔ any 
      Output portPrimarySequenceContent types
      result✔  application/xml 
      Option nameTypeDefault value
      authmap(xs:string, item()+)?()
      parametersmap(xs:QName, item()*)?()
      serializationmap(xs:QName,item()*)?()
      Errors
      Error codeDescription
      err:C0159It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.
      err:C0160It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.
      err:C0161It is a dynamic error if the first document on the source port does not conform to the required format.
      err:C0162It is a dynamic error if the email cannot be send.
      Implementation details
      ImplementationDescription
      DefinedOther key value pairs in “auth” are implementation-defined
      DefinedIt is implementation-defined which other key/value pairs in the parameters option are supported.
      DefinedOther key value pairs in “auth” are implementation-defined
      DefinedIf no values for “host” or “port” is specified, it it implementation-defined which server and port is used.
      Declaration

      <p:declare-steptype="p:send-mail">
           <p:inputport="source"sequence="true"content-types="any"/>
           <p:outputport="result"content-types="application/xml"/>
           <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
           <p:optionname="auth"as="map(xs:string, item()+)?"/>         
           <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
      </p:declare-step>

      The first document on the source port is expected to conform to [XML format for mail]. It is a dynamic error (err:XC0161) if the first document on the source port does not conform to the required format. Any additional documents are treated as attachments.

      If the mail was send successfully a single c:result document whose content is “true” appears on the result port. It is a dynamic error (err:XC0162) if the email cannot be send.

      The em:content may contain either text or HTML. To send some other type as the first message body, you must leave the em:content element out of the first document and supply the body as a second document.

      The p:send-mail step has the following options:

      serialization

      The serialization option is used to control the serialization of documents for constructing the mail. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.

      auth

      If the mail service requires an authentication to send mails, these can be supplied using the auth option.

      The following standard keys are defined:

      username (xs:string)

      The username.

      password (xs:string)

      The password.

      Other key value pairs in “auth” are implementation-defined.It is a dynamic error (err:XC0159) if any key in the “auth” map is associated with a value that is not an instance of the required type.

      parameters

      The parameters option can be used to supply additional information for constructing and sending mails. A number of parameters are defined in this specification. It is implementation-defined which other key/value pairs in the parameters option are supported.

      send-authorization (xs:boolean)

      If the key is associated with false no authentication will be used when sending a mail.

      host (xs:string)

      The SMTP server.

      port (xs:unsignedShort)

      The port.

      Other key value pairs in “auth” are implementation-defined.It is a dynamic error (err:XC0160) if any key in the “parameters” map is associated with a value that is not an instance of the required type.

      If no values for “host” or “port” is specified, it it implementation-defined which server and port is used.

      Document properties

      No document properties are preserved.

      3. Step Errors

      These steps can raise dynamic errors.

      [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

      If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

      The following errors can be raised by this step:

      err:XC0159

      It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.

      See: p:send-mail

      err:XC0160

      It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.

      See: p:send-mail

      err:XC0161

      It is a dynamic error if the first document on the source port does not conform to the required format.

      See: p:send-mail

      err:XC0162

      It is a dynamic error if the email cannot be send.

      See: p:send-mail

      A. Conformance

      Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

      [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

      [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

      A.1. Implementation-defined features

      The following features are implementation-defined:

      1. Other key value pairs in “auth” are implementation-defined See Section 2, “p:send-mail”.
      2. It is implementation-defined which other key/value pairs in the parameters option are supported. See Section 2, “p:send-mail”.
      3. Other key value pairs in “auth” are implementation-defined See Section 2, “p:send-mail”.
      4. If no values for “host” or “port” is specified, it it implementation-defined which server and port is used. See Section 2, “p:send-mail”.

      C. Glossary

      dynamic error

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

      implementation-defined

      An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

      implementation-dependent

      An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.

      \ No newline at end of file diff --git a/master/head/mail/index.html b/master/head/mail/index.html index 2dcb549d0..8f42fd14f 100644 --- a/master/head/mail/index.html +++ b/master/head/mail/index.html @@ -1,4 +1,4 @@ -XProc 3.0: mail steps

      XProc 3.0: mail steps

      Draft Community Group Report

      Editor's Draft at (build 47)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/mail/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: mail steps specification, published by the XProc Next Community Group under the W3C +XProc 3.0: mail steps

      XProc 3.0: mail steps

      Draft Community Group Report

      Editor's Draft at (build 46)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/mail/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: mail steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes optional mail related steps for XProc 3.0: An XML Pipeline Language.

      diff --git a/master/head/os/diff.html b/master/head/os/diff.html index 6652ec577..6b224d8eb 100644 --- a/master/head/os/diff.html +++ b/master/head/os/diff.html @@ -15,4 +15,4 @@ Previous Next -

      XProc 3.0: operating system steps

      Draft Community Group Report

      Editor's Draft at (build 4547)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/os/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: operating system steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:os-exec and p:os-info steps for XProc 3.0: An XML Pipeline Language.

      Status of this Document

      This document is an editor's draft that has no official standing.

      This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

      If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

      1. Introduction

      This specification describes the p:os-info and p:os-exec XProc steps. A machine-readable description of these steps may be found in steps.xpl.

      Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

      2. Step library

      2.1. p:os-info

      The p:os-info step returns information about the operating system on which the processor is running.

      Summary

      Output portPrimarySequenceContent types
      result✔  application/xml 
      Implementation details
      ImplementationDescription
      DefinedThe exact set of properties returned is implementation-defined.
      Declaration

      <p:declare-steptype="p:os-info">
           <p:outputport="result"content-types="application/xml"primary="true"/>
      </p:declare-step>

      The step returns a c:result element with attributes describing properties of the system. It must include the following properties. The attribute can be an empty string if they do not apply to the runtime environment. For example cwd will be an empty string on systems which have no concept of a working directory the value of the attribute will be empty.

      file-separator

      The file separator; usually "/" on Unix, "\" on Windows.

      path-separator

      The path separator; usually ":" on Unix, ";" on Windows.

      os-architecture

      The operating system architecture, for example "i386".

      os-name

      The name of the operating system, for example "Mac OS X".

      os-version

      The version of the operating system, for example "10.5.6".

      cwd

      The current working directory.

      user-name

      The login name of the effective user, for example "ndw".

      user-home

      The home directory of the effective user, for example "/home/ndw".

      The c:result element can contain zero or more c:environment elements that identify the environment variables available. These elements have a mandatory name and value attribute, reflecting name and value of the environment variable. Implementations should include all available operating system environment variables.

      The exact set of properties returned is implementation-defined. Additional attributes must be in a namespace.

      Document properties

      The resulting document has no properties apart from content-type. In particular, it has no base-uri.

      2.2. p:os-exec

      The p:os-exec step runs an external command passing the input that arrives on its source port as standard input, reading result from standard output, and error from standard error.

      Summary

      Input portPrimarySequenceContent types
      source✔ ✔ any 
      Output portPrimarySequenceContent types
      result✔ ✔ any 
      error ✔ any 
      exit-status  application/xml 
      Option nameTypeDefault valueRequired
      commandxs:string ✔ 
      argsxs:string*() 
      cwdxs:string?() 
      error-content-typexs:string'text/plain' 
      failure-thresholdxs:integer?() 
      path-separatorxs:string?() 
      result-content-typexs:string'text/plain' 
      serializationmap(xs:QName,item()*)?() 
      Errors
      Error codeDescription
      err:C0032It is a dynamic error if more than one document appears on the source port of the p:os-exec step.
      err:C0033It is a dynamic error if the command cannot be run.
      err:C0034It is a dynamic error if the current working directory cannot be changed to the value of the cwd option.
      err:C0063It is a dynamic error if the path-separator option is specified and is not exactly one character long.
      err:C0064It is a dynamic error if the exit code from the command is greater than the specified failure-threshold value.
      Implementation details
      ImplementationDescription
      DefinedIf cwd is not specified, the current working directory is implementation-defined.
      DependentThe specific exit status values returned by a process invoked with p:os-exec are implementation-dependent.
      Declaration

      <p:declare-steptype="p:os-exec">
           <p:inputport="source"sequence="true"content-types="any"/>
           <p:outputport="result"primary="true"sequence="true"content-types="any"/>
           <p:outputport="error"sequence="true"content-types="any"/>
           <p:outputport="exit-status"content-types="application/xml"/>
           <p:optionname="command"required="true"as="xs:string"/>     
           <p:optionname="args"select="()"as="xs:string*"/>           
           <p:optionname="cwd"as="xs:string?"/>                        
           <p:optionname="result-content-type"select="'text/plain'"as="xs:string"/>
           <p:optionname="error-content-type"select="'text/plain'"as="xs:string"/>
           <p:optionname="path-separator"as="xs:string?"/>             
           <p:optionname="failure-threshold"as="xs:integer?"/>         
           <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
      </p:declare-step>

      The p:os-exec step executes the command passed on command with the arguments passed on args. The processor does not interpolate the values of the command or args (for example, expanding references to environment variables). It is a dynamic error (err:XC0033) if the command cannot be run.

      If cwd is specified, then the current working directory is changed to the value of that option before execution begins. It is a dynamic error (err:XC0034) if the current working directory cannot be changed to the value of the cwd option. If cwd is not specified, the current working directory is implementation-defined.

      If the path-separator option is specified, every occurrence of the character identified as the path-separator character that occurs in the command, args, or cwd will be replaced by the platform-specific path separator character. It is a dynamic error (err:XC0063) if the path-separator option is specified and is not exactly one character long.

      The source port is declared to accept a sequence so that it can be empty. If no document appears on the source port, then the command receives nothing on standard input. If a document does arrive on the source port, it will be passed to the command as its standard input. It is a dynamic error (err:XC0032) if more than one document appears on the source port of the p:os-exec step. The serialization option is used to control the serialization of the document before passing it to the standard input. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence. Serialization is described in [XProc 3.0].

      If there is content on standard output, it is read and processed as described in p:load with result-content-type taken as value for p:load's content-type option. The created document is returned on result. Otherwise result will be empty.

      If there is content on standard error, it is read and processed as described in p:load with error-content-type taken as value for p:load's content-type option. The created document is returned on error. Otherwise error will be empty.

      The exit-status port always returns a single c:result element which contains the system exit status that the process returned. The specific exit status values returned by a process invoked with p:os-exec are implementation-dependent.

      If a failure-threshold value is supplied, and the exit status is greater than that threshold, then the p:os-exec step must fail. It is a dynamic error (err:XC0064) if the exit code from the command is greater than the specified failure-threshold value. This failure, like any step failure, can be captured with a p:try.

      Document properties

      No document properties are preserved.

      3. Step Errors

      These steps can raise dynamic errors.

      [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

      If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

      The following errors can be raised by these steps:

      err:XC0032

      It is a dynamic error if more than one document appears on the source port of the p:os-exec step.

      See: p:os-exec

      err:XC0033

      It is a dynamic error if the command cannot be run.

      See: p:os-exec

      err:XC0034

      It is a dynamic error if the current working directory cannot be changed to the value of the cwd option.

      See: p:os-exec

      err:XC0063

      It is a dynamic error if the path-separator option is specified and is not exactly one character long.

      See: p:os-exec

      err:XC0064

      It is a dynamic error if the exit code from the command is greater than the specified failure-threshold value.

      See: p:os-exec

      A. Conformance

      Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

      [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

      [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

      A.1. Implementation-defined features

      The following features are implementation-defined:

      1. The exact set of properties returned is implementation-defined. See Section 2.1, “p:os-info”.
      2. If cwd is not specified, the current working directory is implementation-defined. See Section 2.2, “p:os-exec”.

      A.2. Implementation-dependent features

      The following features are implementation-dependent:

      1. The specific exit status values returned by a process invoked with p:os-exec are implementation-dependent. See Section 2.2, “p:os-exec”.

      C. Glossary

      dynamic error

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

      implementation-defined

      An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

      implementation-dependent

      An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.

      \ No newline at end of file +

      XProc 3.0: operating system steps

      Draft Community Group Report

      Editor's Draft at (build 4546)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/os/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: operating system steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:os-exec and p:os-info steps for XProc 3.0: An XML Pipeline Language.

      Status of this Document

      This document is an editor's draft that has no official standing.

      This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

      If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

      1. Introduction

      This specification describes the p:os-info and p:os-exec XProc steps. A machine-readable description of these steps may be found in steps.xpl.

      Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

      2. Step library

      2.1. p:os-info

      The p:os-info step returns information about the operating system on which the processor is running.

      Summary

      Output portPrimarySequenceContent types
      result✔  application/xml 
      Implementation details
      ImplementationDescription
      DefinedThe exact set of properties returned is implementation-defined.
      Declaration

      <p:declare-steptype="p:os-info">
           <p:outputport="result"content-types="application/xml"primary="true"/>
      </p:declare-step>

      The step returns a c:result element with attributes describing properties of the system. It must include the following properties. The attribute can be an empty string if they do not apply to the runtime environment. For example cwd will be an empty string on systems which have no concept of a working directory the value of the attribute will be empty.

      file-separator

      The file separator; usually "/" on Unix, "\" on Windows.

      path-separator

      The path separator; usually ":" on Unix, ";" on Windows.

      os-architecture

      The operating system architecture, for example "i386".

      os-name

      The name of the operating system, for example "Mac OS X".

      os-version

      The version of the operating system, for example "10.5.6".

      cwd

      The current working directory.

      user-name

      The login name of the effective user, for example "ndw".

      user-home

      The home directory of the effective user, for example "/home/ndw".

      The c:result element can contain zero or more c:environment elements that identify the environment variables available. These elements have a mandatory name and value attribute, reflecting name and value of the environment variable. Implementations should include all available operating system environment variables.

      The exact set of properties returned is implementation-defined. Additional attributes must be in a namespace.

      Document properties

      The resulting document has no properties apart from content-type. In particular, it has no base-uri.

      2.2. p:os-exec

      The p:os-exec step runs an external command passing the input that arrives on its source port as standard input, reading result from standard output, and error from standard error.

      Summary

      Input portPrimarySequenceContent types
      source✔ ✔ any 
      Output portPrimarySequenceContent types
      result✔ ✔ any 
      error ✔ any 
      exit-status  application/xml 
      Option nameTypeDefault valueRequired
      commandxs:string ✔ 
      argsxs:string*() 
      cwdxs:string?() 
      error-content-typexs:string'text/plain' 
      failure-thresholdxs:integer?() 
      path-separatorxs:string?() 
      result-content-typexs:string'text/plain' 
      serializationmap(xs:QName,item()*)?() 
      Errors
      Error codeDescription
      err:C0032It is a dynamic error if more than one document appears on the source port of the p:os-exec step.
      err:C0033It is a dynamic error if the command cannot be run.
      err:C0034It is a dynamic error if the current working directory cannot be changed to the value of the cwd option.
      err:C0063It is a dynamic error if the path-separator option is specified and is not exactly one character long.
      err:C0064It is a dynamic error if the exit code from the command is greater than the specified failure-threshold value.
      Implementation details
      ImplementationDescription
      DefinedIf cwd is not specified, the current working directory is implementation-defined.
      DependentThe specific exit status values returned by a process invoked with p:os-exec are implementation-dependent.
      Declaration

      <p:declare-steptype="p:os-exec">
           <p:inputport="source"sequence="true"content-types="any"/>
           <p:outputport="result"primary="true"sequence="true"content-types="any"/>
           <p:outputport="error"sequence="true"content-types="any"/>
           <p:outputport="exit-status"content-types="application/xml"/>
           <p:optionname="command"required="true"as="xs:string"/>     
           <p:optionname="args"select="()"as="xs:string*"/>           
           <p:optionname="cwd"as="xs:string?"/>                        
           <p:optionname="result-content-type"select="'text/plain'"as="xs:string"/>
           <p:optionname="error-content-type"select="'text/plain'"as="xs:string"/>
           <p:optionname="path-separator"as="xs:string?"/>             
           <p:optionname="failure-threshold"as="xs:integer?"/>         
           <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
      </p:declare-step>

      The p:os-exec step executes the command passed on command with the arguments passed on args. The processor does not interpolate the values of the command or args (for example, expanding references to environment variables). It is a dynamic error (err:XC0033) if the command cannot be run.

      If cwd is specified, then the current working directory is changed to the value of that option before execution begins. It is a dynamic error (err:XC0034) if the current working directory cannot be changed to the value of the cwd option. If cwd is not specified, the current working directory is implementation-defined.

      If the path-separator option is specified, every occurrence of the character identified as the path-separator character that occurs in the command, args, or cwd will be replaced by the platform-specific path separator character. It is a dynamic error (err:XC0063) if the path-separator option is specified and is not exactly one character long.

      The source port is declared to accept a sequence so that it can be empty. If no document appears on the source port, then the command receives nothing on standard input. If a document does arrive on the source port, it will be passed to the command as its standard input. It is a dynamic error (err:XC0032) if more than one document appears on the source port of the p:os-exec step. The serialization option is used to control the serialization of the document before passing it to the standard input. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence. Serialization is described in [XProc 3.0].

      If there is content on standard output, it is read and processed as described in p:load with result-content-type taken as value for p:load's content-type option. The created document is returned on result. Otherwise result will be empty.

      If there is content on standard error, it is read and processed as described in p:load with error-content-type taken as value for p:load's content-type option. The created document is returned on error. Otherwise error will be empty.

      The exit-status port always returns a single c:result element which contains the system exit status that the process returned. The specific exit status values returned by a process invoked with p:os-exec are implementation-dependent.

      If a failure-threshold value is supplied, and the exit status is greater than that threshold, then the p:os-exec step must fail. It is a dynamic error (err:XC0064) if the exit code from the command is greater than the specified failure-threshold value. This failure, like any step failure, can be captured with a p:try.

      Document properties

      No document properties are preserved.

      3. Step Errors

      These steps can raise dynamic errors.

      [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

      If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

      The following errors can be raised by these steps:

      err:XC0032

      It is a dynamic error if more than one document appears on the source port of the p:os-exec step.

      See: p:os-exec

      err:XC0033

      It is a dynamic error if the command cannot be run.

      See: p:os-exec

      err:XC0034

      It is a dynamic error if the current working directory cannot be changed to the value of the cwd option.

      See: p:os-exec

      err:XC0063

      It is a dynamic error if the path-separator option is specified and is not exactly one character long.

      See: p:os-exec

      err:XC0064

      It is a dynamic error if the exit code from the command is greater than the specified failure-threshold value.

      See: p:os-exec

      A. Conformance

      Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

      [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

      [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

      A.1. Implementation-defined features

      The following features are implementation-defined:

      1. The exact set of properties returned is implementation-defined. See Section 2.1, “p:os-info”.
      2. If cwd is not specified, the current working directory is implementation-defined. See Section 2.2, “p:os-exec”.

      A.2. Implementation-dependent features

      The following features are implementation-dependent:

      1. The specific exit status values returned by a process invoked with p:os-exec are implementation-dependent. See Section 2.2, “p:os-exec”.

      C. Glossary

      dynamic error

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

      implementation-defined

      An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

      implementation-dependent

      An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.

      \ No newline at end of file diff --git a/master/head/os/index.html b/master/head/os/index.html index f417b998f..f710a5895 100644 --- a/master/head/os/index.html +++ b/master/head/os/index.html @@ -1,4 +1,4 @@ -XProc 3.0: operating system steps

      XProc 3.0: operating system steps

      Draft Community Group Report

      Editor's Draft at (build 47)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/os/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: operating system steps specification, published by the XProc Next Community Group under the W3C +XProc 3.0: operating system steps

      XProc 3.0: operating system steps

      Draft Community Group Report

      Editor's Draft at (build 46)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/os/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: operating system steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:os-exec and p:os-info steps diff --git a/master/head/paged-media/diff.html b/master/head/paged-media/diff.html index 73ec344c9..95716579f 100644 --- a/master/head/paged-media/diff.html +++ b/master/head/paged-media/diff.html @@ -15,4 +15,4 @@ Previous Next -

      XProc 3.0: paged media steps

      Draft Community Group Report

      Editor's Draft at (build 4547)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/paged-media/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: paged media steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:css-formatter and p:xsl-formatter steps for XProc 3.0: An XML Pipeline Language.

      Status of this Document

      This document is an editor's draft that has no official standing.

      This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

      If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

      This document is derived from XProc: An XML Pipeline Language published by the W3C.

      1. Introduction

      This specification describes the p:css-formatter and p:xsl-formatter XProc steps. A machine-readable description of these steps may be found in steps.xpl.

      Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

      2. Step library

      2.1. p:css-formatter

      The p:css-formatter step applies [CSS] formatting to an XML or HTML document. The output of this step is often, but not necessarily, a PDF document.

      Summary

      Input portPrimarySequenceContent typesDefault binding
      source  xml html 
      stylesheet ✔ text p:empty
      Output portPrimarySequenceContent typesDefault binding
      result✔  any 
      Option nameTypeDefault value
      content-typexs:string?()
      parametersmap(xs:QName,item()*)?()
      Errors
      Error codeDescription
      err:C0166It is a dynamic error if the requested document cannot be produced.
      err:C0204It is a dynamic error if the requested content-type is not supported.
      err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
      Implementation details
      ImplementationDescription
      DefinedThe use of media type parameters on the content-type option is implementation-defined.
      DefinedIf the content-type option is not specified, the output type is implementation-defined.
      DefinedThe precise way that the p:css-formatter step selects stylesheets is implementation-defined.
      DefinedA formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the CSS implementation used and are implementation-defined.
      DefinedThe CSS level and the particular CSS features supported by p:css-formatter are implementation-defined.
      Declaration

      <p:declare-steptype="p:css-formatter">
           <p:inputport="source"content-types="xml html"/>
           <p:inputport="stylesheet"content-types="text"sequence="true">
                <p:empty/>
           </p:input>
           <p:outputport="result"content-types="any"/>
           <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
           <p:optionname="content-type"as="xs:string?"/>               
      </p:declare-step>

      The document on the source port is formatted using one or more CSS stylesheets. The content-type of the output is controlled by the content-type option. This option specifies a media type as defined by [IANA Media Types]. 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”. The option may include media type parameters as well (e.g. "application/someformat; charset=UTF-8"). The use of media type parameters on the content-type option is implementation-defined.If the content-type option is not specified, the output type is implementation-defined. The default should be PDF. It is a dynamic error (err:XC0204) if the requested content-type is not supported.

      If one or more stylesheets are provided on the stylesheet port, they should be used. The precise way that the p:css-formatter step selects stylesheets is implementation-defined. Because CSS stylesheets may have import statements that rely on relative URI references, it may be more convenient for authors and implementors to allow stylesheets to be specified as a list of URIs (in, for example, one of the parameters).

      A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the CSS implementation used and are implementation-defined.

      The CSS level and the particular CSS features supported by p:css-formatter are implementation-defined.

      It is a dynamic error (err:XC0166) if the requested document cannot be produced.

      Document properties

      No document properties are preserved.

      2.2. p:xsl-formatter

      The p:xsl-formatter step receives an [XSL 1.1] document and renders the content.

      Summary

      Input portPrimarySequenceContent types
      source✔  xml 
      Output portPrimarySequenceContent types
      result✔  any 
      Option nameTypeDefault value
      content-typexs:string?()
      parametersmap(xs:QName,item()*)?()
      Errors
      Error codeDescription
      err:C0167It is a dynamic error if the requested document cannot be produced.
      err:C0204It is a dynamic error if the requested content-type is not supported.
      err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
      Implementation details
      ImplementationDescription
      DefinedThe use of media type parameters on the content-type option is implementation-defined.
      DefinedIf the content-type option is not specified, the output type is implementation-defined.
      DefinedA formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the XSL implementation used and are implementation-defined.
      Declaration

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

      The content-type of the output is controlled by the content-type option. This option specifies a media type as defined by [IANA Media Types]. 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”. The option may include media type parameters as well (e.g. "application/someformat; charset=UTF-8"). The use of media type parameters on the content-type option is implementation-defined.

      If the content-type option is not specified, the output type is implementation-defined. The default should be PDF. It is a dynamic error (err:XC0204) if the requested content-type is not supported.

      A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the XSL implementation used and are implementation-defined.

      The output of this step is a document containing the result of processing. This is often, but not necessarily, a PDF document.

      It is a dynamic error (err:XC0167) if the requested document cannot be produced.

      Document properties

      No document properties are preserved.

      3. Step Errors

      This step can raise dynamic errors.

      [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

      If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

      The following errors can be raised by this step:

      err:XC0166

      It is a dynamic error if the requested document cannot be produced.

      See: p:css-formatter

      err:XC0167

      It is a dynamic error if the requested document cannot be produced.

      See: p:xsl-formatter

      err:XC0204

      It is a dynamic error if the requested content-type is not supported.

      See: p:css-formatter, p:xsl-formatter

      A. Conformance

      Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

      [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

      [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

      A.1. Implementation-defined features

      The following features are implementation-defined:

      1. The use of media type parameters on the content-type option is implementation-defined. See Section 2.1, “p:css-formatter”.
      2. If the content-type option is not specified, the output type is implementation-defined. See Section 2.1, “p:css-formatter”.
      3. The precise way that the p:css-formatter step selects stylesheets is implementation-defined. See Section 2.1, “p:css-formatter”.
      4. A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the CSS implementation used and are implementation-defined. See Section 2.1, “p:css-formatter”.
      5. The CSS level and the particular CSS features supported by p:css-formatter are implementation-defined. See Section 2.1, “p:css-formatter”.
      6. The use of media type parameters on the content-type option is implementation-defined. See Section 2.2, “p:xsl-formatter”.
      7. If the content-type option is not specified, the output type is implementation-defined. See Section 2.2, “p:xsl-formatter”.
      8. A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the XSL implementation used and are implementation-defined. See Section 2.2, “p:xsl-formatter”.

      B. References

      [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

      [XProc 3.0 Steps] XProc 3.0 Steps: An Introduction. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

      [CSS] CSS Snapshot 2018. Tab Atkins Jr., Elika J. Etemad, and Florial Rivoal editors. W3C Note 22 January 2019.

      [XSL 1.1] Extensible Stylesheet Language (XSL) Version 1.1. Anders Berglund, editor. W3C Recommendation. 5 December 2006.

      [IANA Media Types] IANA MIME Media Types. Internet Engineering Task Force.

      C. Glossary

      dynamic error

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

      implementation-defined

      An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

      implementation-dependent

      An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.

      \ No newline at end of file +

      XProc 3.0: paged media steps

      Draft Community Group Report

      Editor's Draft at (build 4546)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/paged-media/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: paged media steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:css-formatter and p:xsl-formatter steps for XProc 3.0: An XML Pipeline Language.

      Status of this Document

      This document is an editor's draft that has no official standing.

      This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

      If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

      This document is derived from XProc: An XML Pipeline Language published by the W3C.

      1. Introduction

      This specification describes the p:css-formatter and p:xsl-formatter XProc steps. A machine-readable description of these steps may be found in steps.xpl.

      Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

      2. Step library

      2.1. p:css-formatter

      The p:css-formatter step applies [CSS] formatting to an XML or HTML document. The output of this step is often, but not necessarily, a PDF document.

      Summary

      Input portPrimarySequenceContent typesDefault binding
      source  xml html 
      stylesheet ✔ text p:empty
      Output portPrimarySequenceContent typesDefault binding
      result✔  any 
      Option nameTypeDefault value
      content-typexs:string?()
      parametersmap(xs:QName,item()*)?()
      Errors
      Error codeDescription
      err:C0166It is a dynamic error if the requested document cannot be produced.
      err:C0204It is a dynamic error if the requested content-type is not supported.
      err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
      Implementation details
      ImplementationDescription
      DefinedThe use of media type parameters on the content-type option is implementation-defined.
      DefinedIf the content-type option is not specified, the output type is implementation-defined.
      DefinedThe precise way that the p:css-formatter step selects stylesheets is implementation-defined.
      DefinedA formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the CSS implementation used and are implementation-defined.
      DefinedThe CSS level and the particular CSS features supported by p:css-formatter are implementation-defined.
      Declaration

      <p:declare-steptype="p:css-formatter">
           <p:inputport="source"content-types="xml html"/>
           <p:inputport="stylesheet"content-types="text"sequence="true">
                <p:empty/>
           </p:input>
           <p:outputport="result"content-types="any"/>
           <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
           <p:optionname="content-type"as="xs:string?"/>               
      </p:declare-step>

      The document on the source port is formatted using one or more CSS stylesheets. The content-type of the output is controlled by the content-type option. This option specifies a media type as defined by [IANA Media Types]. 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”. The option may include media type parameters as well (e.g. "application/someformat; charset=UTF-8"). The use of media type parameters on the content-type option is implementation-defined.If the content-type option is not specified, the output type is implementation-defined. The default should be PDF. It is a dynamic error (err:XC0204) if the requested content-type is not supported.

      If one or more stylesheets are provided on the stylesheet port, they should be used. The precise way that the p:css-formatter step selects stylesheets is implementation-defined. Because CSS stylesheets may have import statements that rely on relative URI references, it may be more convenient for authors and implementors to allow stylesheets to be specified as a list of URIs (in, for example, one of the parameters).

      A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the CSS implementation used and are implementation-defined.

      The CSS level and the particular CSS features supported by p:css-formatter are implementation-defined.

      It is a dynamic error (err:XC0166) if the requested document cannot be produced.

      Document properties

      No document properties are preserved.

      2.2. p:xsl-formatter

      The p:xsl-formatter step receives an [XSL 1.1] document and renders the content.

      Summary

      Input portPrimarySequenceContent types
      source✔  xml 
      Output portPrimarySequenceContent types
      result✔  any 
      Option nameTypeDefault value
      content-typexs:string?()
      parametersmap(xs:QName,item()*)?()
      Errors
      Error codeDescription
      err:C0167It is a dynamic error if the requested document cannot be produced.
      err:C0204It is a dynamic error if the requested content-type is not supported.
      err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
      Implementation details
      ImplementationDescription
      DefinedThe use of media type parameters on the content-type option is implementation-defined.
      DefinedIf the content-type option is not specified, the output type is implementation-defined.
      DefinedA formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the XSL implementation used and are implementation-defined.
      Declaration

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

      The content-type of the output is controlled by the content-type option. This option specifies a media type as defined by [IANA Media Types]. 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”. The option may include media type parameters as well (e.g. "application/someformat; charset=UTF-8"). The use of media type parameters on the content-type option is implementation-defined.

      If the content-type option is not specified, the output type is implementation-defined. The default should be PDF. It is a dynamic error (err:XC0204) if the requested content-type is not supported.

      A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the XSL implementation used and are implementation-defined.

      The output of this step is a document containing the result of processing. This is often, but not necessarily, a PDF document.

      It is a dynamic error (err:XC0167) if the requested document cannot be produced.

      Document properties

      No document properties are preserved.

      3. Step Errors

      This step can raise dynamic errors.

      [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

      If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

      The following errors can be raised by this step:

      err:XC0166

      It is a dynamic error if the requested document cannot be produced.

      See: p:css-formatter

      err:XC0167

      It is a dynamic error if the requested document cannot be produced.

      See: p:xsl-formatter

      err:XC0204

      It is a dynamic error if the requested content-type is not supported.

      See: p:css-formatter, p:xsl-formatter

      A. Conformance

      Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

      [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

      [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

      A.1. Implementation-defined features

      The following features are implementation-defined:

      1. The use of media type parameters on the content-type option is implementation-defined. See Section 2.1, “p:css-formatter”.
      2. If the content-type option is not specified, the output type is implementation-defined. See Section 2.1, “p:css-formatter”.
      3. The precise way that the p:css-formatter step selects stylesheets is implementation-defined. See Section 2.1, “p:css-formatter”.
      4. A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the CSS implementation used and are implementation-defined. See Section 2.1, “p:css-formatter”.
      5. The CSS level and the particular CSS features supported by p:css-formatter are implementation-defined. See Section 2.1, “p:css-formatter”.
      6. The use of media type parameters on the content-type option is implementation-defined. See Section 2.2, “p:xsl-formatter”.
      7. If the content-type option is not specified, the output type is implementation-defined. See Section 2.2, “p:xsl-formatter”.
      8. A formatter may take any number of optional rendering parameters via the step's parameters; such parameters are defined by the XSL implementation used and are implementation-defined. See Section 2.2, “p:xsl-formatter”.

      B. References

      [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

      [XProc 3.0 Steps] XProc 3.0 Steps: An Introduction. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

      [CSS] CSS Snapshot 2018. Tab Atkins Jr., Elika J. Etemad, and Florial Rivoal editors. W3C Note 22 January 2019.

      [XSL 1.1] Extensible Stylesheet Language (XSL) Version 1.1. Anders Berglund, editor. W3C Recommendation. 5 December 2006.

      [IANA Media Types] IANA MIME Media Types. Internet Engineering Task Force.

      C. Glossary

      dynamic error

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

      implementation-defined

      An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

      implementation-dependent

      An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

      D. Ancillary files

      This specification includes by reference a number of ancillary files.

      steps.xpl

      An XProc step library for the declared steps.

      \ No newline at end of file diff --git a/master/head/paged-media/index.html b/master/head/paged-media/index.html index fc2742030..cfc3b9bb2 100644 --- a/master/head/paged-media/index.html +++ b/master/head/paged-media/index.html @@ -1,4 +1,4 @@ -XProc 3.0: paged media steps

      XProc 3.0: paged media steps

      Draft Community Group Report

      Editor's Draft at (build 47)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/paged-media/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: paged media steps specification, published by the XProc Next Community Group under the W3C +XProc 3.0: paged media steps

      XProc 3.0: paged media steps

      Draft Community Group Report

      Editor's Draft at (build 46)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/paged-media/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: paged media steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:css-formatter and p:xsl-formatter diff --git a/master/head/run/diff.html b/master/head/run/diff.html index 5d1c40529..683e4015b 100644 --- a/master/head/run/diff.html +++ b/master/head/run/diff.html @@ -15,4 +15,4 @@ Previous Next -

      XProc 3.0: dynamic pipeline execution

      Draft Community Group Report

      Editor's Draft at (build 4547)
      Latest editor’s draft:
      https://spec.xproc.org/master/head/run/
      Editors:
      Norman Walsh
      Achim Berndzen
      Gerrit Imsieke
      Erik Siegel
      Participate:
      GitHub xproc/3.0-steps
      Report an issue
      Changes:
      Diff against current “status quo” draft
      Commits for this specification

      This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

      Copyright © 2018, 2019, 2020, 2024 the Contributors to the XProc 3.0: dynamic pipeline execution specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

      Abstract

      This specification describes the p:run step for XProc 3.0: An XML Pipeline Language.

      Status of this Document

      This document is an editor's draft that has no official standing.

      This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

      If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

      1. Introduction

      This specification describes the p:run XProc step. A machine-readable description of this step may be found in steps.xpl.

      Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

      2. p:run

      The p:run step runs a dynamically loaded pipeline.

      <p:run
        name? = NCName>
          (p:with-input? &
           p:run-input* &
           p:run-option* &
           p:output*)
      </p:run>

      The p:run step has a single, anonymous input that accepts the pipeline to be run. Otherwise, it functions similar to an atomic step in that you can define input connections and option values for it, albeit not with the usual p:with-input and p:with-option connections.

      The p:run step expects a single pipeline document on its anonymous input port (“pipeline port”). Independent of how the pipeline is provided, it must have a version attribute on its root element. It is a dynamic error (err:XC0200) if the pipeline input to the p:run step is not a valid pipeline. The anonymous input port is not primary, although it is the only p:input port of p:run. Therefore it will not automatically connect to the default readable port (see Connections in XProc 3.0: An XML Pipeline Language); it needs to be connected to its pipeline input explicitly.

      The pipeline that appears on the pipeline port is evaluated using the inputs and options specified on the p:run step by means of the p:run-input and p:run-option elements, respectively.

      The p:run-input element is a special case of the p:with-input element for passing inputs to the pipeline being run.

      <p:run-input
        port = NCName
        select? = XPathExpression
        href? = { anyURI }
        pipe? = string
        primary? = boolean
        exclude-inline-prefixes? = ExcludeInlinePrefixes>
          ((p:empty |
             (p:document |
              p:pipe |
              p:inline)*) |
           anyElement*)
      </p:run-input>

      Similarly, the p:run-option element is a special case of the p:with-option element for passing options to the pipeline being run.

      <p:run-option
        name = EQName
        as? = XPathSequenceType
        select = XPathExpression
        collection? = boolean
        href? = { anyURI }
        pipe? = string
        static? = boolean
        exclude-inline-prefixes? = ExcludeInlinePrefixes>
          ((p:empty |
             (p:document |
              p:pipe |
              p:inline)*) |
           anyElement*)
      </p:run-option>

      In terms of binding inputs and options, these elements have the same syntax and semantics as p:with-input and p:with-option. In addition, the boolean attribute primary can be used on p:run-input to declare whether the respective port of the dynamically executed pipeline is expected to be the primary input port. If the attribute is omitted, it is assumed to be “false” if there are multiple p:run-input connections and “true” if there is exactly one p:run-input connection. It is a dynamic error (err:XC0206) if the dynamically executed pipeline implicitly or explicitly declares a primary input port with a different name than implicitly or explicitly specified in the p:run invocation. Input ports of the dynamically executed pipeline that are not declared with p:run-input on the p:run invocation will receive a p:empty connection. Input ports that are declared in p:run-input but not in the dynamically executed pipeline will be silently ignored.

      The context item used to evaluate expressions on p:run-option comes from the default readable port of the p:run step. Additionally, if p:run-input implicitly or explicitly identifies a primary input port, the default readable port will be connected to it if no explicit connection is provided.

      Other than p:with-option, p:run-option accepts a boolean attribute static that defaults to “false”. If it is “true”, the option value will be supplied to static analysis of the executed pipeline as a static option with the same name.

      Options of the dynamically executed pipeline that are not provided by a p:run-option on the p:run invocation will be defaulted in the normal way (if the option is required, the invocation will fail, for example). Options that are provided by p:run-option but not declared in the dynamically executed pipeline are silently ignored.

      Each output port of the pipeline can appear as a same-named output port of the p:run step. In order for this to happen, the port needs to be explicitly declared in the p:run step. In contrast to output declarations of compound steps or of p:declare-pipeline with a subpipeline, such an output declaration may not establish a connection to any port of another step or of the pipeline to be run.

      If the pipeline has an output that is not declared on the p:run step, that output is discarded, and the corresponding port on the p:run step does not exist. If the p:run step declares an output port that is not provided by the pipeline, an empty sequence appears on that port.

      It is a dynamic error (err:XC0207) if the dynamically executed pipeline implicitly or explicitly declares a primary output port with a different name than implicitly or explicitly specified in the p:run invocation.

      2.1. Example

      The following pipeline shows how p:run might be used.

      <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="3.0" name="sample-run-invocation"> <p:variable name="xsl-params" select="map{'foo': 'bar'}" as="map(xs:QName, item()*)"/> <p:variable name="assert-valid" select="false()" as="xs:boolean"/> <p:variable name="mode" as="xs:QName?" select="()"/> <p:variable name="template" as="xs:QName?" select="()"/> <p:run name="runme"> <p:with-input href="transform-n-validate.xpl"/> <p:run-option name="mode" select="$mode"/> <p:run-option name="template" select="$template"/> <p:run-option name="xslt-parameters" select="$xsl-params"/> <p:run-option name="assert-valid" select="$assert-valid"/> <p:run-input port="source" href="my.xml" primary="true"/> <p:run-input port="stylesheet" href="my.xsl"/> <p:run-input port="xsd" href="my.xsd"/> <p:output port="result" primary="true"/> <p:output port="report"/> </p:run> </p:declare-step>

      With this pipeline in transform-n-validate.xpl, the preceding step has the effect of running the pipeline with the dynamically constructed options.

      <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="3.0" name="transform-n-validate"> <p:input port="source" primary="true" sequence="true"/> <p:input port="stylesheet"/> <p:input port="xsd"/> <p:option name="assert-valid" as="xs:boolean" select="false()"/> <p:option name="xslt-parameters" as="map(xs:QName, item()*)?"/> <p:option name="mode" as="xs:QName?"/> <p:option name="template" as="xs:QName?"/> <p:output port="result" primary="true"/> <p:output port="report" pipe="report@xsdval"/> <p:xslt> <p:with-option name="initial-mode" select="$mode"/> <p:with-option name="template-name" select="$template"/> <p:with-option name="parameters" select="$xslt-parameters"/> <p:with-input port="stylesheet" pipe="stylesheet"/> </p:xslt> <p:validate-with-xml-schema name="xsdval"> <p:with-option name="assert-valid" select="$assert-valid"/> <p:with-input port="schema" pipe="xsd@transform-n-validate"/> </p:validate-with-xml-schema> </p:declare-step>

      In practice, p:run might be more often used with dynamically constructed pipelines.

      2.2. Document properties

      The extent to which document properties are preserved depends on the steps in the dynamically executed pipeline.

      3. Step Errors

      This step can raise dynamic errors.

      [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

      If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

      The following errors can be raised by this step:

      err:XC0200

      It is a dynamic error if the pipeline input to the p:run step is not a valid pipeline.

      See: p:run

      err:XC0206

      It is a dynamic error if the dynamically executed pipeline implicitly or explicitly declares a primary input port with a different name than implicitly or explicitly specified in the p:run invocation.

      See: p:run

      err:XC0207

      It is a dynamic error if the dynamically executed pipeline implicitly or explicitly declares a primary output port with a different name than implicitly or explicitly specified in the p:run invocation.

      See: p:run

      A. Conformance

      Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

      [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

      [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

      A.1. Implementation-defined features

      The following features are implementation-defined:

        C. Glossary

        dynamic error

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

        implementation-defined

        An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

        implementation-dependent

        An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

        D. Ancillary files

        This specification includes by reference a number of ancillary files.

        steps.xpl

        An XProc step library for the declared steps.

        \ No newline at end of file +

        XProc 3.0: dynamic pipeline execution

        Draft Community Group Report

        Editor's Draft at (build 4546)
        Latest editor’s draft:
        https://spec.xproc.org/master/head/run/
        Editors:
        Norman Walsh
        Achim Berndzen
        Gerrit Imsieke
        Erik Siegel
        Participate:
        GitHub xproc/3.0-steps
        Report an issue
        Changes:
        Diff against current “status quo” draft
        Commits for this specification

        This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

        Copyright © 2018, 2019, 2020, 2024 the Contributors to the XProc 3.0: dynamic pipeline execution specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

        Abstract

        This specification describes the p:run step for XProc 3.0: An XML Pipeline Language.

        Status of this Document

        This document is an editor's draft that has no official standing.

        This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

        If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

        1. Introduction

        This specification describes the p:run XProc step. A machine-readable description of this step may be found in steps.xpl.

        Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

        2. p:run

        The p:run step runs a dynamically loaded pipeline.

        <p:run
          name? = NCName>
            (p:with-input? &
             p:run-input* &
             p:run-option* &
             p:output*)
        </p:run>

        The p:run step has a single, anonymous input that accepts the pipeline to be run. Otherwise, it functions similar to an atomic step in that you can define input connections and option values for it, albeit not with the usual p:with-input and p:with-option connections.

        The p:run step expects a single pipeline document on its anonymous input port (“pipeline port”). Independent of how the pipeline is provided, it must have a version attribute on its root element. It is a dynamic error (err:XC0200) if the pipeline input to the p:run step is not a valid pipeline. The anonymous input port is not primary, although it is the only p:input port of p:run. Therefore it will not automatically connect to the default readable port (see Connections in XProc 3.0: An XML Pipeline Language); it needs to be connected to its pipeline input explicitly.

        The pipeline that appears on the pipeline port is evaluated using the inputs and options specified on the p:run step by means of the p:run-input and p:run-option elements, respectively.

        The p:run-input element is a special case of the p:with-input element for passing inputs to the pipeline being run.

        <p:run-input
          port = NCName
          select? = XPathExpression
          href? = { anyURI }
          pipe? = string
          primary? = boolean
          exclude-inline-prefixes? = ExcludeInlinePrefixes>
            ((p:empty |
               (p:document |
                p:pipe |
                p:inline)*) |
             anyElement*)
        </p:run-input>

        Similarly, the p:run-option element is a special case of the p:with-option element for passing options to the pipeline being run.

        <p:run-option
          name = EQName
          as? = XPathSequenceType
          select = XPathExpression
          collection? = boolean
          href? = { anyURI }
          pipe? = string
          static? = boolean
          exclude-inline-prefixes? = ExcludeInlinePrefixes>
            ((p:empty |
               (p:document |
                p:pipe |
                p:inline)*) |
             anyElement*)
        </p:run-option>

        In terms of binding inputs and options, these elements have the same syntax and semantics as p:with-input and p:with-option. In addition, the boolean attribute primary can be used on p:run-input to declare whether the respective port of the dynamically executed pipeline is expected to be the primary input port. If the attribute is omitted, it is assumed to be “false” if there are multiple p:run-input connections and “true” if there is exactly one p:run-input connection. It is a dynamic error (err:XC0206) if the dynamically executed pipeline implicitly or explicitly declares a primary input port with a different name than implicitly or explicitly specified in the p:run invocation. Input ports of the dynamically executed pipeline that are not declared with p:run-input on the p:run invocation will receive a p:empty connection. Input ports that are declared in p:run-input but not in the dynamically executed pipeline will be silently ignored.

        The context item used to evaluate expressions on p:run-option comes from the default readable port of the p:run step. Additionally, if p:run-input implicitly or explicitly identifies a primary input port, the default readable port will be connected to it if no explicit connection is provided.

        Other than p:with-option, p:run-option accepts a boolean attribute static that defaults to “false”. If it is “true”, the option value will be supplied to static analysis of the executed pipeline as a static option with the same name.

        Options of the dynamically executed pipeline that are not provided by a p:run-option on the p:run invocation will be defaulted in the normal way (if the option is required, the invocation will fail, for example). Options that are provided by p:run-option but not declared in the dynamically executed pipeline are silently ignored.

        Each output port of the pipeline can appear as a same-named output port of the p:run step. In order for this to happen, the port needs to be explicitly declared in the p:run step. In contrast to output declarations of compound steps or of p:declare-pipeline with a subpipeline, such an output declaration may not establish a connection to any port of another step or of the pipeline to be run.

        If the pipeline has an output that is not declared on the p:run step, that output is discarded, and the corresponding port on the p:run step does not exist. If the p:run step declares an output port that is not provided by the pipeline, an empty sequence appears on that port.

        It is a dynamic error (err:XC0207) if the dynamically executed pipeline implicitly or explicitly declares a primary output port with a different name than implicitly or explicitly specified in the p:run invocation.

        2.1. Example

        The following pipeline shows how p:run might be used.

        <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="3.0" name="sample-run-invocation"> <p:variable name="xsl-params" select="map{'foo': 'bar'}" as="map(xs:QName, item()*)"/> <p:variable name="assert-valid" select="false()" as="xs:boolean"/> <p:variable name="mode" as="xs:QName?" select="()"/> <p:variable name="template" as="xs:QName?" select="()"/> <p:run name="runme"> <p:with-input href="transform-n-validate.xpl"/> <p:run-option name="mode" select="$mode"/> <p:run-option name="template" select="$template"/> <p:run-option name="xslt-parameters" select="$xsl-params"/> <p:run-option name="assert-valid" select="$assert-valid"/> <p:run-input port="source" href="my.xml" primary="true"/> <p:run-input port="stylesheet" href="my.xsl"/> <p:run-input port="xsd" href="my.xsd"/> <p:output port="result" primary="true"/> <p:output port="report"/> </p:run> </p:declare-step>

        With this pipeline in transform-n-validate.xpl, the preceding step has the effect of running the pipeline with the dynamically constructed options.

        <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="3.0" name="transform-n-validate"> <p:input port="source" primary="true" sequence="true"/> <p:input port="stylesheet"/> <p:input port="xsd"/> <p:option name="assert-valid" as="xs:boolean" select="false()"/> <p:option name="xslt-parameters" as="map(xs:QName, item()*)?"/> <p:option name="mode" as="xs:QName?"/> <p:option name="template" as="xs:QName?"/> <p:output port="result" primary="true"/> <p:output port="report" pipe="report@xsdval"/> <p:xslt> <p:with-option name="initial-mode" select="$mode"/> <p:with-option name="template-name" select="$template"/> <p:with-option name="parameters" select="$xslt-parameters"/> <p:with-input port="stylesheet" pipe="stylesheet"/> </p:xslt> <p:validate-with-xml-schema name="xsdval"> <p:with-option name="assert-valid" select="$assert-valid"/> <p:with-input port="schema" pipe="xsd@transform-n-validate"/> </p:validate-with-xml-schema> </p:declare-step>

        In practice, p:run might be more often used with dynamically constructed pipelines.

        2.2. Document properties

        The extent to which document properties are preserved depends on the steps in the dynamically executed pipeline.

        3. Step Errors

        This step can raise dynamic errors.

        [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

        If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

        The following errors can be raised by this step:

        err:XC0200

        It is a dynamic error if the pipeline input to the p:run step is not a valid pipeline.

        See: p:run

        err:XC0206

        It is a dynamic error if the dynamically executed pipeline implicitly or explicitly declares a primary input port with a different name than implicitly or explicitly specified in the p:run invocation.

        See: p:run

        err:XC0207

        It is a dynamic error if the dynamically executed pipeline implicitly or explicitly declares a primary output port with a different name than implicitly or explicitly specified in the p:run invocation.

        See: p:run

        A. Conformance

        Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

        [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

        [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

        A.1. Implementation-defined features

        The following features are implementation-defined:

          C. Glossary

          dynamic error

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

          implementation-defined

          An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

          implementation-dependent

          An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

          D. Ancillary files

          This specification includes by reference a number of ancillary files.

          steps.xpl

          An XProc step library for the declared steps.

          \ No newline at end of file diff --git a/master/head/run/index.html b/master/head/run/index.html index 06e83241f..e16166fe8 100644 --- a/master/head/run/index.html +++ b/master/head/run/index.html @@ -1,4 +1,4 @@ -XProc 3.0: dynamic pipeline execution

          XProc 3.0: dynamic pipeline execution

          Draft Community Group Report

          Editor's Draft at (build 47)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/run/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020, 2024 the Contributors to the XProc 3.0: dynamic pipeline execution specification, published by the XProc Next Community Group under the W3C +XProc 3.0: dynamic pipeline execution

          XProc 3.0: dynamic pipeline execution

          Draft Community Group Report

          Editor's Draft at (build 46)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/run/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020, 2024 the Contributors to the XProc 3.0: dynamic pipeline execution specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the p:run step for diff --git a/master/head/steps/diff.html b/master/head/steps/diff.html index c50a10b16..105601504 100644 --- a/master/head/steps/diff.html +++ b/master/head/steps/diff.html @@ -15,4 +15,4 @@ Previous Next -

          XProc 3.0+: Standard Step Library

          Draft Community Group Report

          Editor's Draft at (build 4547)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/steps/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against the 3.0 specification
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020, 2021, 2022 the Contributors to the XProc 3.0+: Standard Step Library specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the standard step vocabulary of XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

          If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

          Note

          This draft is the “editor’s working draft” and includes changes made after the XProc 3.0 standard step specification was released.

          This document is derived from XProc: An XML Pipeline Language published by the W3C.

          1. Introduction

          This specification describes the standard, required atomic XProc steps. A machine-readable description of these steps may be found in steps.xpl.

          Many atomic steps are available for [XProc 3.0]. They are described in several specifications. This specification describes the general background common to all steps. A conformant processor must implement all of the steps in this specification. Additional steps may also be implemented.

          The types given for options should be understood as follows:

          • Types in the XML Schema namespace, identified as QNames with the xs: prefix, as per the XML Schema specification with one exception. Anywhere an xs:QName is specified, an EQName is allowed.

          • XPathExpression: As a string per [W3C XML Schema: Part 2], including whitespace normalization, and the further requirement to be a conformant Expression per [XPath 3.1].

          • XSLTSelectionPattern: As a string per [XSLT 3.0] conforming to an XSLT selection pattern.

          • XPathSequenceType: An XPath sequence type.

          • ContentType: A media type as defined in [RFC 2046].

          • ContentTypes: As a whitespace separated list of media types as defined in [RFC 2046].

          Option values are often expressed using the shortcut syntax. In these cases, the option shortcuts are generally treated as value templates. However, for options of type map() or array(), an expression is required (there is no non-expression string which can ever be a legal value for a map or array). Given that every value entered this way will have to be a value template, and consequently every curly brace contained within the expression will have to be escaped, values of type map or array are defined to be expressions directly.

          Some aspects of documents are generally unchanged by steps:

          • When a step in this library produces an output document, the base URI of the output is the base URI of the step's primary input document unless the step's process explicitly sets an xml:base attribute or the step's description explicitly states how the base URI is constructed.

          • Steps are responsible for describing how document properties are transformed as documents flow through them. Many steps claim that the specified properties are preserved. Generally, it is the responsibility of the pipeline author to determine when this is inapropriate and take corrective action. However, it is the responsibility of the pipeline processor to assure that the content-type property is correct. If a step transforms a document in a manner that is inconsistent with the content-type property (accepting an XML document on the source port but producing a text document on the result, for example), the processor must assure that the content-type property is appropriate. If a step changes the content-type in this way, it must also remove the serialization property

          Also, in this specification, several steps use this element for result information:

          <c:result>
              string
          </c:result>

          When a step uses an XPath to compute an option value, the XPath context is as defined in [XProc 3.0].

          When a step specifies a particular version of a technology, implementations must implement that version or a subsequent version that is backwards compatible with that version. At user-option, they may implement other non-backwards compatible versions.

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

          As described in PSVIs in XProc in XProc 3.0: An XML Pipeline Language, steps may not produce PSVI output unless that behavior is explicitly described. In this specification, the steps that may produce PSVI output are the “identity” steps: p:identity, p:store, and p:split-sequence (which must preserve PSVI properties that appear on their inputs). In addition, the p:xslt and p:xquery steps may return documents with PSVI annotations.

          2. Step library

          A conformant processor must support all of these steps.

          2.1. p:add-attribute

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attribute-namexs:QName ✔ 
          attribute-valuexs:string ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the selection pattern matches a node which is not an element.
          err:C0059It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

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

          Note

          If multiple attributes need to be set on the same element(s), the p:set-attributes step can be used to set them all at once.

          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 is “xmlns” or 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.

          Document properties

          All document properties are preserved.

          2.2. p:add-xml-base

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          allxs:booleanfalse()
          relativexs:booleantrue()
          Errors
          Error codeDescription
          err:C0058It is a dynamic error if the all and relative options are both true.
          Declaration

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

          • For every element that is a child of the document node: force the element to have an xml:base attribute with the document's [base URI] property's value as its value.

          • For other elements:

            • If the all option has the value true, force the element to have an xml:base attribute with the element's [base URI] value as its value.

            • If the element's [base URI] is different from the its parent's [base URI], force the element to have an xml:base attribute with the following value: if the value of the relative option is true, a string which, when resolved against the parent's [base URI], will give the element's [base URI], otherwise the element's [base URI].

            • Otherwise, if there is an xml:base attribute present, remove it.

          Document properties

          All document properties are preserved.

          2.3. p:archive

          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.

          Summary

          Input portPrimarySequenceContent typesDefault binding
          source✔ ✔ any 
          manifest ✔ xml p:empty
          archive ✔ any p:empty
          Output portPrimarySequenceContent typesDefault binding
          result✔  any 
          report  application/xml 
          Option nameTypeDefault value
          formatxs:QName'zip'
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0080It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0084It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0100It is a dynamic error if the document on port manifest does not conform to the given schema.
          err:C0112It is a dynamic error if more than one document appears on the port manifest.
          err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedThe list of formats supported by the p:archive step is implementation-defined.
          DefinedThe list of archive formats that can be modified by p:archive is implementation-defined.
          DefinedThe semantics of any additional attributes, elements and their values are implementation-defined.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe c:archive root element may contain additional implementation-defined attributes.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what other compression methods are supported.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what compression levels are supported.
          DefinedThe c:entry elements may contain additional implementation-defined attributes.
          DefinedThe p:archive step may support additional, implementation-defined commands for ZIP files.
          DefinedThe actual parameter names supported by p:archive for a particular format are implementation-defined.
          Declaration

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

          source

          The (primary) source port is used to provide documents to be archived (for instance constructed by other steps). How and which of these documents are processed is governed by the document(s) appearing on the other input ports and the combination of options and parameters. See below for details. It is a dynamic error (err:XC0084) if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          manifest

          The manifest port can receive a manifest document that tells the step how to construct the archive. If no manifest document is provided on this port, a default manifest is constructed automatically. See Section 2.3.1, “The archive manifest”. It is a dynamic error (err:XC0100) if the document on port manifest does not conform to the given schema.

          It is a dynamic error (err:XC0112) if more than one document appears on the port manifest.

          The default input for this port is the empty sequence.

          archive

          The archive port is used to provide the step with existing archive(s) for operations like update, freshen or merge. Handling of ZIP files supports modifying archives appearing on the archive port (Section 2.3.2, “Handling of ZIP archives”). The list of archive formats that can be modified by p:archive is implementation-defined. For instance an implementation that supports archive merging may accept more than one document on the archive port.

          The default input for this port is the empty sequence.

          The p:archive step has the following output ports:

          result

          The (primary) result port will output the resulting archive.

          report

          The report port will output a report about the archiving operation. This will be the same as the manifest (as provided on the manifest port or automatically created if there was no manifest provided), optionally amended with additional attributes and/or elements. The semantics of any additional attributes, elements and their values are implementation-defined.

          The p:archive step has the following options:

          format

          The format of the archive can be specified using the format option. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.

          parameters

          The parameters option can be used to supply parameters to control the archiving. Several parameters are defined for processing zip archives, but implementations are free to use additional parameters and to use parameters for controlling how other archive formats are processed. 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.

          relative-to

          The relative-to option is used in creating a manifest when no manifest is provided on the manifest port. If a manifest is present this option is not used. If the option’s value is a relative URI, 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 format of the archive is determined as follows:

          • If the format option is specified, this determines the format of the archive. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0081) if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the archive port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [ZIP] format.

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

          2.3.1. The archive manifest

          An archive manifest specifies which documents will be considered in processing the archive. Every entry in the archive must have a corresponding entry in the manifest; if no such entry is provided, one will be constructed automatically (see below). If manifest entries are provided for documents that are not in the archive, how those are processed depends on the archive type and the parameters passed to the step.

          A manifest is represented by a c:archive root element:

          <c:archive>
              (c:entry* &
               anyNonXProcElement*)
          </c:archive>

          The c:archive root element may contain additional implementation-defined attributes.

          All entries in the archive must be present as c:entry child elements:

          <c:entry
            name = string
            href = anyURI
            comment? = string
            method? = string
            level? = string
            content-type? = ContentType>
              anyElement*
          </c:entry>

          • The name attribute specifies the name of the entry in the archive.

          • The href attribute must be a valid URI according to [RFC 3986]. If its value is relative, it is made absolute against the base URI of the manifest. There are two possible cases:

            • If the (absolute) href value is exactly the same as the base URI of a document appearing on the source port, that document is associated with this entry. If this entry is to be added to the archive, the associated document will be used. (The serialization document property can be used to provide serialization properties.)

            • If no document on the source port has a base URI that is exactly the same as the (absolute) href value, the document at the specified URI is associated with this entry. These documents are stored in the archive “as is”; they must not be parsed and re-serialized.

          • The method attribute specifies how the entry should be compressed. The default compression method is implementation-defined. Implementations must support no compression, specified with the value none. It is implementation-defined what other compression methods are supported.

          • The level attribute specifies the level of compression. The default compression method is implementation-defined. It is implementation-defined what compression levels are supported.

          • The content-type attribute specifies the content-type of the entry as detected by the processor. It will be set by p:archive-manifest in constructing the manifest. It will be ignored by p:archive.

          The p:archive step should strive to retain the order of the c:entry elements when constructing the archive. For instance, an e-book in EPUB format has a non-compressed entry that must be first in the archive. It should be possible to construct such an archive using p:archive.

          The c:entry elements may contain additional implementation-defined attributes.

          If no manifest entry is provided for a document appearing on the source port, the step will create a manifest entry for the document. (If no document arrives on the manifest port at all, a complete manifest document will be created.)

          In a constructed manifest entry:

          • The entry’s href value is the base URI of the document.

          • The entry’s name value is derived from the base URI of the document and the relative-to option.

            • First, the value of the relative-to option is made absolute. If the initial substring of the base URI is exactly the same as the resulting absolute value, then the name is the portion of the base URI that follows that initial substring.

            • If there is no relative-to option or if its value is not the initial substring of the base URI of the document, the name is the path portion of the URI (per [RFC 3986]). If the path portion begins with an initial slash, that slash is removed.

          It is a dynamic error (err:XC0100) if an archive manifest is invalid according to the specification.

          2.3.2. Handling of ZIP archives

          The format of the archive can be specified using the format option. Implementations must support the [ZIP] format, specified with the value zip.

          When ZIP archives are processed, every name in the manifest must be a relative path without a leading slash.

          The parameters option can be used to supply parameters to control the archiving. For the zip format, the following parameters must be supported:

          command

          Specifies what operation to perform. If not specified, its default value is update. Implementations must support the values update, create, freshen, and delete. The p:archive step may support additional, implementation-defined commands for ZIP files. Unless otherwise specified, exactly zero or one ZIP archive can appear on the archive port for the commands described below. If no archive appears, a new archive will be created.

          update

          When the command parameter is set to update, the ZIP archive will be updated:

          1. For every entry in the ZIP file:

            • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is updated with the document identified by the c:entry in the manifest.

            • If the manifest does not contain a matching c:entry, the ZIP entry name is resolved against the base URI of the ZIP file.

              • If a document exists at that URI and either has no timestamp or has a timestamp more than the timestamp in the ZIP file, the entry in the ZIP file will be updated with the document at the resolved URI.

              • If no document exists at that URI, or the document cannot be accessed, or the document has a timestamp and the timestamp in the ZIP archive is more recent than the timestamp of the document, then the ZIP entry is unchanged.

          2. For every c:entry in the manifest that does not have a matching entry in the ZIP file, the ZIP file will be updated by adding the document identified by the c:entry to the ZIP file.

          create

          When the command parameter is set to create, the ZIP archive will be created. Creating a ZIP archive behaves exactly like update except that any timestamps are ignored; every ZIP entry will be updated or created if there is a c:entry or matching document for it. The document must be obtained by dereferencing the URI in href. It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          freshen

          When the command parameter is set to freshen, existing files in the ZIP archive may be updated, but no new files will be added. Freshing a ZIP archive behaves exactly like update except that only entries that already exist in the ZIP archive are considered.

          delete

          When the command parameter is set to delete, exactly one document in ZIP format must appear on the archive port. For every entry in the ZIP file:

          • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is removed from the ZIP archive.

          If the manifest contains c:entry elements which do not have a matching entry in the ZIP archive, they are simply ignored.

          level

          Specifies the default compression level for files added to or updated in the archive. If the level attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “smallest”, “fastest”, “default”, “huffman”, and “none”.

          method

          Specifies the default compression method for files added to or updated in the archive. If the method attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “none” and “deflated”.

          It is a dynamic error (err:XC0080) if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          Implementations of other archive formats should use the same parameter names if applicable. The value spaces for these parameters may be format-specific though. The actual parameter names supported by p:archive for a particular format are implementation-defined.

          Document properties

          No document properties are preserved. The archive has no base-uri.

          2.4. p:archive-manifest

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          formatxs:QName?()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0146It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedAdditional information provided for entries in p:archive-manifest is implementation-defined.
          Declaration

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

          • If the format option is specified, this determines the format of the archive. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0081) if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [ZIP] format.

          It is a dynamic error (err:XC0085) if the format of the archive 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.39, “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.

          2.4.1. Overriding content types

          The override-content-types option can be used to partially override the content-type determination mechanism. If present, it must be an array of arrays, where the inner arrays consist of exactly two strings:

          • The first member in an inner array 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.

          • The second member in an inner array must be a valid a MIME content-type. 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:XC0146) if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          Determining an archive entry's content-type is as follows:

          • The XPath regular expressions (the first members of the inner arrays) will be matched against the path of the entry in the archive. This will be done in the order of appearance in the outer array (so order is significant). The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • If a match is found, the content-type (the second member of the inner array for which the match was found) is used as the entry's content-type.

          • If no match was found for all inner arrays, the normal (implementation-defined) mechanism for determining the content-type is used.

          For example: setting the override-content-types option to [ ['.rels$', 'application/xml'], ['^special/', 'application/octet-stream'] ] means that all files ending with .rels will get the content-type application/xml. All files in the archive's special directory (including sub-directories) will get the content-type application/octet-stream.

          Document properties

          No document properties are preserved. The manifest has no base-uri.

          2.5. p:cast-content-type

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          content-typexs:string ✔ 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0071It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.
          err:C0072It is a dynamic error if the c:data contains content is not a valid base64 string.
          err:C0073It is a dynamic error if the c:data element does not have a content-type attribute.
          err:C0074It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:D0049It is a dynamic error if the text value is not a well-formed XML document
          err:D0057It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the text document can not be converted into the XPath data model
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedThe precise nature of the conversion from XML to JSON is implementation-defined.
          DefinedCasting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.
          DefinedCasting from an HTML media type to a JSON media type is implementation-defined.
          DefinedCasting from an HTML media type to any other media type is implementation-defined.
          DefinedIt is implementation-defined whether other result formats are supported.
          DefinedCasting from a JSON media type to an HTML media type is implementation-defined.
          DefinedCasting from a JSON media type to any other media type is implementation-defined.
          DefinedThe precise way in which text documents are parsed into the XPath data model is implementation-defined.
          DefinedCasting from a text media type to any other media type is implementation-defined.
          DefinedCasting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.
          DefinedCasting from any other media type to any other media type is implementation-defined.
          Declaration

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

          2.5.1. Casting from an XML media type

          • Casting from one XML media type to another simply changes the “content-type” document property.

          • Casting from an XML media type to an HTML media type changes the “content-type” document property and removes any serialization property.

          • Casting from an XML media type to a JSON media type converts the XML into JSON. The precise nature of the conversion from XML to JSON is implementation-defined. If the input document is an XML representation of JSON as defined in [XPath and XQuery Functions and Operators 3.1], implementations must produce the same result as fn:parse-json(fn:xml-to-json()) by default. If the input document has a c:param-set document element, an instance of map(xs:QName, xs:string)must be returned that represents the document's c:param elements. The serialization property is removed.

          • Casting from an XML media type to a text media type serializes the XML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an XML media type to any other media type must support the case where the input document is a c:data document. The resulting document will have the specified media type and a representation that is the content of the c:data element after decoding the base64 encoded content The serialization property is removed.

            It is a dynamic error (err:XC0072) if the c:data contains content is not a valid base64 string.

            It is a dynamic error (err:XC0073) if the c:data element does not have a content-type attribute.

            It is a dynamic error (err:XC0074) if the content-type is supplied and is not the same as the content-type specified on the c:data element.

            Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.

          2.5.2. Casting from an HTML media type

          • Casting from an HTML media type to an XML media type changes “content-type” document property and removes any serialization property.

          • Casting from an HTML media type to another HTML media type changes “content-type” document property.

          • Casting from an HTML media type to a JSON media type is implementation-defined.

          • Casting an an HTML media type to a text media type serializes the HTML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an HTML media type to any other media type is implementation-defined.

          2.5.3. Casting from a JSON media type

          • Casting from a JSON media type to an XML media type converts the JSON into XML. An implementation must support the format specified in section “XML Representation of JSON” of [XPath and XQuery Functions and Operators 3.1] as default for the resulting XML. It is implementation-defined whether other result formats are supported. The serialization property is removed.

          • Casting from a JSON media type to an HTML media type is implementation-defined.

          • Casting from a JSON media type to another JSON media type changes “content-type” document property.

          • Casting from a JSON media type to a text media type serializes the JSON document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from a JSON media type to any other media type is implementation-defined.

          2.5.4. Casting from a text media type

          • Casting from a text media type to an XML media type parses the text value of the document on source port by calling fn:parse-xml. It is a dynamic error (err:XD0049) if the text value is not a well-formed XML document. The serialization property is removed.

          • Casting from a text media type to an HTML media type parses the text value of the document on source port into an XPath data model document that contains a tree of elements, attributes, and other nodes. The precise way in which text documents are parsed into the XPath data model is implementation-defined.It is a dynamic error (err:XD0060) if the text document can not be converted into the XPath data model. The serialization property is removed.

          • Casting from a text media type to a JSON media type parses the text value of the document on source port by calling fn:parse-json($doc, $par) where $doc is the text document and $par is the parameter option. It is a dynamic error (err:XD0057) if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation. It is a dynamic error (err:XD0058) if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys. It is a dynamic error (err:XD0059) if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present. The serialization property is removed.

          • Casting from a text media type to another text media type changes “content-type” document property.

          • Casting from a text media type to any other media type is implementation-defined.

          2.5.5. Casting from any other media type

          • Casting from a non-XML media type to an XML media type produces an XML document with a c:data document element. The original media type will be preserved in the content-type attribute on the c:data element.

            <c:data
              content-type = ContentType
              charset? = string
              encoding? = string>
                string
            </c:data>

            The content of the c:data element is the base64 encoded representation of the non-XML content. The serialization property is removed.

          • Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.

          • Casting from any other media type to any other media type is implementation-defined.

          Document properties

          All document properties are preserved except the content-type property which is updated accordingly and the serialization property which is removed by some casting methods.

          2.6. p:compare

          The p:compare step compares two documents for equality.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          alternate  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          differences ✔ any 
          Option nameTypeDefault value
          fail-if-not-equalxs:booleanfalse()
          methodxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0019It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.
          err:C0076It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.
          err:C0077It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.
          Implementation details
          ImplementationDescription
          DefinedImplementations of p:compare must support the deep-equal method; other supported methods are implementation-defined.
          DefinedIf 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.
          Declaration

          <p:declare-steptype="p:compare">
               <p:inputport="source"primary="true"content-types="any"/>
               <p:inputport="alternate"content-types="any"/>
               <p:outputport="result"primary="true"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.

          Document properties

          No document properties are preserved. The comparison document has no base-uri.

          Erratum, April 2024

          The result output port has been made primary. This is consistent with the behavior of all known implementations.

          2.7. p:compress

          The p:compress step serializes the document appearing on its source port and outputs a compressed version of this on its result port.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          formatxs:QName'gzip'
          parametersmap(xs:QName, item()*)?()
          serializationmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

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

          format

          The format of the compression can be specified using the format option. Implementations must support the [GZIP] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0202) if the compression format cannot be understood, determined and/or processed.

          parameters

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

          serialization

          The serialization option is provided to control the serialization of content before compression takes place. 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].

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly and the serialization property which is removed.

          2.8. p:count

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          limitxs:integer0
          Declaration

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

          Document properties

          No document properties are preserved. The count document has no base-uri.

          2.9. p:delete

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the match option matches the document node.
          err:C0062It is a dynamic error if the match option matches a namespace node.
          Declaration

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.10. p:error

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          codexs:QName✔ 
          Declaration

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

          Document properties

          No document properties are preserved but that’s irrelevant as no document is ever produced.

          2.11. p:filter

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ text xml html 
          Option nameTypeRequired
          selectXPathExpression✔ 
          Declaration

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

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI of the selected node(s).

          2.12. p:hash

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault valueRequired
          algorithmxs:QName ✔ 
          valuexs:string ✔ 
          matchXSLTSelectionPattern'/*/node()' 
          parametersmap(xs:QName,item()*)?() 
          versionxs:string?() 
          Errors
          Error codeDescription
          err:C0036It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other algorithms are supported.
          Declaration

          <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 result is a text document.

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.13. p:http-request

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          report  application/json 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          assertxs:string'.?status-code lt 400' 
          authmap(xs:string, item()+)?() 
          headersmap(xs:string, xs:string)?() 
          methodxs:string?'GET' 
          parametersmap(xs:QName, item()*)?() 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0003It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.
          err:C0030It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).
          err:C0078It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.
          err:C0122It is a dynamic error if the given method is not supported.
          err:C0123It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.
          err:C0124It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.
          err:C0125It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.
          err:C0126It is a dynamic error if the XPath expression in assert evaluates to false.
          err:C0127It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.
          err:C0128It is a dynamic error if the URI’s scheme is unknown or not supported.
          err:C0131It is a dynamic error if the processor cannot support the requested encoding.
          err:C0132It is a dynamic error if the override content encoding cannot be supported.
          err:C0133It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.
          err:C0203It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which HTTP methods are supported.
          DefinedThe interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined.
          DefinedOther key value pairs in map “auth” are implementation-defined.
          DefinedIt is implementation-defined which other key/value pairs in the parameters option are supported.
          DefinedThe default behaviour in case of a redirect response is implementation-defined.
          DefinedIt is implementation-defined how a multipart boundary is constructed.
          Declaration

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

          This is the HTTP status code returned for the request.

          base-uri (an xs:anyURI)

          This is the URI of the last request made and is always available in the report even when the request does not return any documents. In the case of HTTP redirection, the base URI returned may be different from the original request URI.

          headers (a map(xs:string, xs:string))

          These are the HTTP headers returned for the request. The map may be empty. Header names are converted to lowercase.

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

          href

          The href option specifies the request’s IRI. Relative values are resolved against the base URI of the element on which the option is specified (the relevant p:with-option or the step element in the case of a syntactic shortcut value).

          Fragment identifiers are removed before making the request. Query parameters are passed through unchanged. It is a dynamic error (err:XC0128) if the URI’s scheme is unknown or not supported. It is the pipeline author’s responsibility to escape problematic UTF-8 characters in the href value, for example with escape-html-uri().

          method

          The method specifies the HTTP request method. The value is implicitly turned into an uppercase string if necessary. It is implementation-defined which HTTP methods are supported. An implementation should implement at least the methods GET, POST, PUT, DELETE, and HEAD (for HTTP and HTTPS). It is a dynamic error (err:XC0122) if the given method is not supported.

          serialization

          The serialization option is used to control the serialization of documents for the request body. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.

          headers

          The key/value pairs in the headers map are used to construct the request headers. Each map key is used as a header name and the value associated with that key in the map is used as the header value.

          If a single document appears on the source port, then document properties on that document may be added as additional headers. For XML, HTML, and text documents with a serialization document property having an encoding key, a charset is appended to the created content-type header of the HTTP request. Properties in the http://www.w3.org/ns/xproc-http namespace will be added to the headers, using the local-name of the property QName as the header name. These properties are only copied if they are not specified in the header map. In other words, if the same header name appears in both places, the value from the map is used and the value from the document properties is ignored. (Header names are case-insensitive, so a case-insensitive comparison must be performed.) If multiple documents appear on the source port, none of their properties are used in the request headers.

          The behavior of the p:http-request depends on the headers specified. In particular:

          content-type

          If a content-type header is provided, it will be used. For a single document request, this overrides the content type value of the document. If the content type specified begins with “multipart/”, a multipart request will be sent to the server.

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

          transfer-encoding

          If a transfer-encoding header is provided, the request must be sent with that encoding. It is a dynamic error (err:XC0131) if the processor cannot support the requested encoding.

          authorization

          The authorization header is used to authenticate a request. If the authoption is specified, any key or property that would have contributed a header named “authorization” (irrespective of case) is ignored. The authorization header is determined exclusively by the auth option when it is present.

          HTTP headers are case-insensitive but keys in maps are not; be careful when specifying the request headers. It is a dynamic error (err:XC0127) if the headers map contains two keys that are the same when compared in a case-insensitive manner. (That is, when fn:uppercase($key1) = fn:uppercase($key2).)

          auth

          Many web services are only available to authenticated users, that is, to users who have “logged in”. The auth option allows the pipeline author to specify information that may be required to generate an “Authorization” header. The standard values support HTTP “Basic” and “Digest” authentication, but other authentication methods are allowed.

          The following standard keys are defined:

          username (xs:string)

          The username.

          password (xs:string)

          The password associated with the username.

          auth-method (xs:string)

          The authentication method. Appropriate values for the “auth-method” key are “Basic” or “Digest” but other values are allowed. If the authentication method is “Basic” or “Digest”, authentication is handled as per [RFC 2617]. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined.

          send-authorization (xs:boolean)

          The “send-authorization” key can be used to attempt to allow the request to avoid an authentication challenge. If the “send-authorization” key is “true()”, and the authentication method specified by the value associated with the “auth-method” key supports generation of an “Authorization” header without a challenge, then the header is generated and sent on the first request. If the “send-authorization” key is absent or does not have the value “true”, the first request is sent without an “Authorization” header.

          Other key value pairs in map “auth” are implementation-defined.It is a dynamic error (err:XC0123) if any key in the “auth” map is associated with a value that is not an instance of the required type.

          If the initial response to the request is an authentication challenge, the values provided in the auth map and any relevant data from the challenge are used to generate an “Authorization” header and the request is sent again. If that authorization fails, the request is not retried.

          It is a dynamic error (err:XC0003) if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported. All implementations must support “Basic” and “Digest” authentication per [RFC 2617].

          parameters

          The parameter option can be used to provide values for fine tuning the construction of the request and/or handling of the server response. A number of parameters are defined in this specification. It is implementation-defined which other key/value pairs in the parameters option are supported.

          override-content-type (xs:string)

          Ordinarily, the value of the content-type header provided in the server response controls the interpretation of any body in the response. If the “override-content-type” parameter is provided, then its value is used to interpret the body. The content-type header that appears on the report port is not changed. 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:XC0030) if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          http-version (xs:string)

          The http-version parameter indicates which version of HTTP must be used for the request.

          accept-multipart (xs:boolean)

          If the accept-multipart parameter is present and explicitly has the value false(), a dynamic error will be raised, if a multipart response is received from the server. This feature is a convenience for pipeline authors as it will raise an error when the multipart request is received, rather than having the presence of a sequence raise an error further along in the pipeline, or simply producing anomalous results. It is a dynamic error (err:XC0125) if the key “accept-multipart” as the value false() and a multipart response is detected.

          override-content-encoding (xs:string)

          If the “override-content-encoding” parameter is present, the response will be treated as if the response contained a “content-encoding” header with the specified value. The content-encoding header that appears on the report port is not changed. It is a dynamic error (err:XC0132) if the override content encoding cannot be supported.

          permit-expired-ssl-certificate (xs:boolean)

          If “permit-expired-ssl-certificate” is true, then the processor should not reject responses where the server provides an expired SSL certificate.

          permit-untrusted-ssl-certificate (xs:boolean)

          If “permit-untrusted-ssl-certificate” is true, then the processor should not reject response where the server provides an SSL certificate which is not trusted, for example, because the certificate authority (CA) is unknown.

          follow-redirect (xs:integer)

          The “follow-redirect” parameter allows the pipeline author to specify the step’s behaviour in the case of a redirect response. A value of 0 indicates that redirects are not to be followed, -1 indicates that redirects are to be followed indefinitely, and a specific number indicates the maximum number of redirects to follow. The default behaviour in case of a redirect response is implementation-defined.

          timeout (xs:integer)

          If a “timeout” is specified, it must be a non-negative integer. It controls the time the XProc processor waits for the request to be answered. If a value is given, it is taken as the number of seconds to wait for the response to be delivered. If no response is received after that time, the request is terminated and a status-code 408 is assumed.

          fail-on-timeout (xs:boolean)

          If “fail-on-timeout” is true, a dynamic error is raised if a 408 response is received (either as a consequence of setting a value for the “timeout” parameter or as status code returned by a server). It is a dynamic error (err:XC0078) if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered. If “fail-on-timeout” is true, it prevents any dynamic error with code C0126 resulting from the assert option to be raised for request's timeout.

          Note

          Please note that the “fail-on-timeout” parameter is different from the “timeout” option on the p:http-request step (see Controlling long running steps in XProc 3.0: An XML Pipeline Language). If the step does not finish in the specified time, D0053 is raised. If the request does not finish in time, and fail-on-timeout is true, C0078 is raised. The actual times after which a timeout is detected may also differ slightly.

          status-only (xs:boolean)

          If the “status-only” parameter is true, this indicates that the pipeline author is only interested in the response code. An empty sequence is always returned on the result port in this case. The implementation may save resources by ignoring the response body. The map on the report will contain the status code and an empty map for “headers”.

          suppress-cookies (xs:boolean)

          If the “suppress-cookies” parameter is true, the implementation must not send any cookies with the request.

          send-body-anyway (xs:boolean)

          If the “send-body-anyway” parameter is true, and one or more documents appear on the source port, a request body is constructed from the documents and sent with the request, even if the semantics of sending a body are not specified for the HTTP method in use.

          It is a dynamic error (err:XC0124) if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          assert (xs:string)

          The assert option can be used by pipeline authors to raise a dynamic error if the response does not fulfill the expectations of the receiver. The option's value (if present) is interpreted as an XPath expression which will be executed using the map that appears on the report port as its context item. If the effective boolean value of the expression is false(), a dynamic error is raised. It is a dynamic error (err:XC0126) if the XPath expression in assert evaluates to false. Implementations should provide an XML representation of the map used as the context item with the error document to enable pipelines to access the error's cause.

          2.13.1. Construction of a multipart request

          If more than one document appears on the source port, or if the specified “content-type” header begins “multipart/”, a multipart request will be constructed, per [RFC 1521]. The content type of the request is derived from the “content-type” header:

          • If the “content-type” header specifies a multipart content type, that value will be used as the content type. If the header includes a boundary parameter, that value will be used as the boundary. It is a dynamic error (err:XC0203) if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          • If the “content-type” header is not specified, “multipart/mixed” will be used.

          • It is a dynamic error (err:XC0133) if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          A multipart request must have a boundary marker, if one isn’t specified in the content type, the implementation must construct one. It is implementation-defined how a multipart boundary is constructed. Implementations are not required to guarantee that the constructed value does not appear accidentally in the multipart data. If it does, the request will be malformed; pipeline authors must provide a boundary if they wish to assure that this cannot happen.

          Each document in the sequence is serialized. If the document has a “serialization” document property, its values are used to determine how serialization is performed.

          All of the document properties in the http://www.w3.org/ns/xproc-http namespace will be added as headers for the part, using the local-name of the property QName as the header name. In particular, this is how the “id”, “description”, “disposition” and other multipart headers can be provided.

          2.13.2. Managing a multipart response

          When a multipart response is received, each part is interpreted according to it’s content type and a pipeline document is constructed. Any additional headers associated with the part are added to the document properties of the constructed document.

          The multipart response is the resulting sequence of documents.

          Document properties

          No document properties are preserved.

          2.14. p:identity

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Declaration

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

          Document properties

          All document properties are preserved.

          2.15. p:insert

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          insertion ✔ xml html text 
          Output portPrimarySequenceContent types
          result✔  xml html text 
          Option nameTypeValuesDefault value
          matchXSLTSelectionPattern '/*'
          positionxs:string('first-child','last-child','before','after') 'after'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace node.
          err:C0024It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.
          err:C0025It is a dynamic error 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”.
          Declaration

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

          • “first-child” - the insertion is made as the first child of the match;

          • “last-child” - the insertion is made as the last child of the match;

          • “before” - the insertion is made as the immediate preceding sibling of the match;

          • “after” - the insertion is made as the immediate following sibling of the match.

          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.

          Document properties

          All document properties on the source port are preserved. The document properties on the insertion port are not preserved or present in the result document.

          2.16. p:json-join

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeDefault value
          flatten-to-depthxs:string?'0'
          Errors
          Error codeDescription
          err:C0111 It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.
          err:C0119It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

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

          • If the document under inspection is a JSON document representing an array, the array is copied to the resulting array according to the setting of option flatten-to-depth.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents, their XDM representation is appended to the resulting array.

          • It is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, an entry is created as described above. It is a dynamic error (err:XC0111) if a document of an unsupported document type appears on port source of p:json-join.

          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.

          Document properties

          No document properties are preserved. The joined document has no base-uri.

          2.17. p:json-merge

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeValuesDefault value
          duplicatesxs:string('reject', 'use-first', 'use-last', 'use-any', 'combine') 'use-first'
          keyXPathExpression 'concat("_",$p:index)'
          Errors
          Error codeDescription
          err:C0106It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.
          err:C0107 It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.
          err:C0110It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

          <p:declare-steptype="p:json-merge">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"content-types="application/json"/>
               <p:optionname="duplicates"values="('reject', 'use-first', 'use-last', 'use-any', 'combine')"select="'use-first'"/><!-- string -->
               <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:

          • If the document under inspection is a JSON document representing a map, all key-value pairs are copied into the result map unless this map already contains an entry with the given key. In this case the value of option duplicates determines the policy for handling duplicate keys as specified for function map:merge in [XPath and XQuery Functions and Operators 3.1]. It is a dynamic error (err:XC0106) if duplicate keys are encountered and option duplicates has value “reject”.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents a new key-value pair is created and put into the resulting map. The key is created by evaluating the XPath expression in option key with the inspected document as context item. If the evaluation result is a single atomic value, it is taken as key. If the evaluation result is a node, its string value is taken as key. It is a dynamic error (err:XC0110) if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function. Duplicate keys are handled as described above. The XDM representation of the inspected document is taken as value of the key-value pair.

          • It is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, the key-value pair is created as described above. It is a dynamic error (err:XC0107) if a document of a not supported document type appears on port source of p:json-merge.

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

          Document properties

          No document properties are preserved. The merged document has no base-uri.

          2.18. p:label-elements

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          attributexs:QName'xml:id'
          labelXPathExpression'concat("_",$p:index)'
          matchXSLTSelectionPattern'*'
          replacexs:booleantrue()
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that expression matches anything other than element nodes.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.19. p:load

          The p:load step has no inputs but produces as its result a document specified by an IRI.

          Summary

          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          content-typexs:string?() 
          document-propertiesmap(xs:QName, item()*)?() 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:D0011It is a dynamic error if the resource referenced by a p:load element does not exist or cannot be accessed.
          err:D0023It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.
          err:D0043It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.
          err:D0049It is a dynamic error if the loaded content is not a well-formed XML document.
          err:D0057It is a dynamic error if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the content-type specifies an encoding, which is not supported by the processor.
          err:D0062It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0078It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIn the absence of an explicit type, the content type is implementation-defined
          DefinedAdditional XML parameters are implementation-defined.
          DefinedText parameters are implementation-defined.
          DefinedAdditional JSON parameters are implementation-defined.
          DefinedThe precise way in which HTML documents are parsed into the XPath data model is implementation-defined.
          DefinedHTML parameters are implementation-defined.
          DefinedHow a processor interprets other media types is implementation-defined.
          DefinedParameters for other media types are implementation-defined.
          Declaration

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

          1. If a content-type property is specified in document-properties or content-type is present, then the document must be interpreted according to that content type. 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:XD0062) if the content-type is specified and the document-properties has a “content-type” that is not the same.

          2. If the document is retrieved with a URI protocol that specifies a content type (for example, http:), then the document must be interpreted according to that content type.

          3. In the absence of an explicit type, the content type is implementation-defined.

          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.

          2.19.1. Loading XML data

          For an XML media type, the content is loaded and parsed as XML.

          It is a dynamic error (err:XD0049) if the loaded content is not a well-formed XML document.

          If the dtd-validate parameter is true, then DTD validation must be performed when parsing the document. It is a dynamic error (err:XD0023) if a DTD validation is performed and either the document is not valid or no DTD is found. It is a dynamic error (err:XD0043) if the dtd-validate parameter is true and the processor does not support DTD validation.

          Additional XML parameters are implementation-defined.

          2.19.2. Loading text data

          For a text media type, the content is loaded as a text document. (A text document is an XPath data model document consisting of a single text node.)

          It is a dynamic error (err:XD0060) if the content-type specifies an encoding, which is not supported by the processor.

          Text parameters are implementation-defined.

          2.19.3. Loading JSON data

          For a JSON media type, the content is loaded and parsed as JSON.

          The parameters specified for the fn:parse-json function in [XPath and XQuery Functions and Operators 3.1] must be supported. Additional JSON parameters are implementation-defined.

          It is a dynamic error (err:XD0057) if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          It is a dynamic error (err:XD0058) if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.

          It is a dynamic error (err:XD0059) if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          2.19.4. Loading HTML data

          For an HTML media type, the content is loaded and parsed into an XPath data model document that contains a tree of elements, attributes, and other nodes.

          The precise way in which HTML documents are parsed into the XPath data model is implementation-defined.

          It is a dynamic error (err:XD0078) if the loaded document cannot be represented as an HTML document in the XPath data model.

          HTML parameters are implementation-defined.

          2.19.5. Loading binary data

          An XProc processor may load other, arbitrary data types. How a processor interprets other media types is implementation-defined.

          Parameters for other media types are implementation-defined.

          Document properties

          The properties specified in document-properties are applied. If the properties do not specify a base-uri, the base-uri property will reflect the base URI of the loaded document.

          2.20. p:make-absolute-uris

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          base-urixs:anyURI?() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than element or attribute nodes.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DependentIf 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.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.21. p:namespace-delete

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeRequired
          prefixesxs:string✔ 
          Errors
          Error codeDescription
          err:C0108It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.
          err:C0109It is a dynamic error if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.22. p:namespace-rename

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeValuesDefault value
          apply-toxs:string('all','elements','attributes') 'all'
          fromxs:anyURI? ()
          toxs:anyURI? ()
          Errors
          Error codeDescription
          err:C0014It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.
          err:C0092It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.
          Declaration

          <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"select="'all'"values="('all','elements','attributes')"/><!-- string -->
          </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:

          • Namespace bindings: If the from option is present and its value is not the empty string, then every binding of a prefix (or the default namespace) in the input document whose value is the same as the value of the from option is

            • replaced in the output with a binding to the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) absent from the output.

            If the from option is absent, or its value is the empty string, then no bindings are changed or removed.

          • Elements and attributes: If the from option is present and its value is not the empty string, for every element and attribute, as appropriate, in the input whose namespace name is the same as the value of the from option, in the output its namespace name is

            • replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) changed to have no value.

            If the from option is absent, or its value is the empty string, then for every element and attribute, as appropriate, whose namespace name has no value, in the output its namespace name is set to the value of the to option.

            It is a dynamic error (err:XC0092) if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          • Namespace attributes: If the from option is present and its value is not the empty string, for every namespace attribute in the input whose value is the same as the value of the from option, in the output

            • the namespace attribute's value is replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) the namespace attribute is absent.

          Note

          The apply-to option is primarily intended to make it possible to avoid renaming attributes when the from option specifies no namespace, since many attributes are in no namespace.

          Care should be taken when specifying no namespace with the to option. Prefixed names in content, for example QNames and XPath expressions, may end up with no appropriate namespace binding.

          Document properties

          All document properties are preserved.

          2.23. p:pack

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          alternate ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeRequired
          wrapperxs:QName✔ 
          Declaration

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

          Note

          In the common case, where the document element of a document in the result sequence has two element children, any comments, processing instructions, or white space text nodes that occur between them may have come from either of the input documents; this step does not attempt to distinguish which one.

          Document properties

          No document properties are preserved. The result documents do not have a base-uri property.

          2.24. p:rename

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          new-namexs:QName ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0013It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.
          err:C0023It is a dynamic error if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.
          Declaration

          <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, or if it matches more than one attribute on a single element.

          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.

          Document properties

          All document properties are preserved.

          2.25. p:replace

          The p:replace step replaces matching nodes in its primary input with the top-level node(s) of the replacement port's document.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          replacement  text xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace nodes.
          Declaration

          <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, the result is a text document.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.26. p:set-attributes

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attributesmap(xs:QName, xs:anyAtomicType) ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than element nodes.
          err:C0059It is a dynamic error if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

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

          This step cannot be used to add namespace declarations. It is a dynamic error (err:XC0059) if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/. However, 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.

          Document properties

          All document properties are preserved.

          2.27. p:set-properties

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          propertiesmap(xs:QName,item()*) ✔ 
          mergexs:booleantrue() 
          Errors
          Error codeDescription
          err:C0069It is a dynamic error if the properties map contains a key equal to the string “content-type”.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0070It is a dynamic error 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 .
          Declaration

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

          Document properties

          If merge is true, document properties not overridden by settings in the properties map are preserved, otherwise the resulting document has only the content-type property and the properties specified in the properties map. In particular, if merge is false, the base-uri property will not be preserved. This means that the resulting document will not have a base URI if the properties map does not contain a base-uri entry.

          2.28. p:sink

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Declaration

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

          Document properties

          Not applicable.

          2.29. p:sleep

          The p:sleep step introduces a delay.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          durationxs:nonNegativeInteger✔ 
          Declaration

          <p:declare-steptype="p:sleep">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"sequence="true"content-types="any"/>
               <p:optionname="duration"as="xs:nonNegativeInteger"required="true"/>
          </p:declare-step>

          The p:sleep step copies each of the documents on the source port to the result port without changing them. Before copying the documents, it pauses for a period of time not less than duration milliseconds.

          Note

          In multi-threaded implementations, there is no guarantee that this will pause the execution of more than one thread. However, any steps that depend on the output of this step will wait for this step to complete.

          Document properties

          All document properties are preserved.

          2.30. p:split-sequence

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          matched✔ ✔ any 
          not-matched ✔ any 
          Option nameTypeDefault valueRequired
          testXPathExpression ✔ 
          initial-onlyxs:booleanfalse() 
          Errors
          Error codeDescription
          err:C0150It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.
          Declaration

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

          Note

          In principle, this component cannot stream because it must buffer all of the input sequence in order to find the context size. In practice, if the test expression does not use the last() function, the implementation can stream and ignore the context size.

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

          Document properties

          All document properties are preserved.

          2.31. p:store

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          result-uri  application/xml 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0050It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.32. p:string-replace

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          replaceXPathExpression✔ 
          Declaration

          <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 result is a text document.

          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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.33. p:text-count

          The p:text-count step counts the number of lines in a text document and returns a single XML document containing that number.

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Declaration

          <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 (&#10;), that newline is ignored. (It is not a separator between that line and a following line that contains no characters.)

          Document properties

          No document properties are preserved. The count document does not have a base-uri property.

          2.34. p:text-head

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

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

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

          • If the count option is positive, the p:text-head step returns the first count lines

          • If the count option is zero, the p:text-head step returns all lines

          • If the count option is negative, the p:text-head step returns all lines except the first count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.35. p:text-join

          The p:text-join step concatenates text documents.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault value
          override-content-typexs:string?()
          prefixxs:string?()
          separatorxs:string?()
          suffixxs:string?()
          Errors
          Error codeDescription
          err:C0001It is a dynamic error if the value of option override-content-type is not a text media type.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Declaration

          <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 separator option is specified, its value will be inserted in between adjacent documents.

          • When the prefix option is specified, the document appearing on the result port will always start with its value (also when there are no documents on the source port).

          • When the suffix option is specified, the document appearing on the result port will always end with its value (also when there are no documents on the source port).

          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.

          Document properties

          No document properties are preserved. The joined document has no base-uri property.

          2.36. p:text-replace

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault valueRequired
          patternxs:string ✔ 
          replacementxs:string ✔ 
          flagsxs:string?() 
          Errors
          Error codeDescription
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.37. p:text-sort

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

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeValuesDefault value
          case-orderxs:string?('upper-first', 'lower-first') ()
          collationxs:string 'http://www.w3.org/2005/xpath-functions/collation/codepoint'
          langxs:language? ()
          orderxs:string('ascending', 'descending') 'ascending'
          sort-keyXPathExpression '.'
          stablexs:boolean true()
          Errors
          Error codeDescription
          err:C0098It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.
          err:C0099It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.
          Implementation details
          ImplementationDescription
          DefinedSupport for other collations is implementation-defined.
          Declaration

          <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')"/><!-- string -->
               <p:optionname="case-order"as="xs:string?"values="('upper-first', 'lower-first')"/><!-- string -->
               <p:optionname="lang"as="xs:language?"/>                     
               <p:optionname="collation"as="xs:string"select="'http://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.

          • The sort-key is used to obtain a sort key for each of the lines in the document appearing on source. The context item is the line as an instance of xs:string, the context position is the number of the line in the document on port source, the context size is the number of lines in this document. It is a dynamic error (err:XC0098) if a dynamic XPath error occurred while applying sort-key to a line. It is a dynamic error (err:XC0099) if the result of applying sort-key to a given line results in a sequence with more than one item.

          • The order option defines whether the lines are processed in ascending or descending order. Its value must be one of ascending or descending. The default is ascending.

          • The case-order option defines whether upper-case letters are to be collated before or after lower-case letters. Its value must be one of upper-first or lower-first. The default is language-dependent.

          • The lang option defines the language whose collating conventions are to be used. The xs:language data type represents natural language identifiers as defined by [BCP 47] (currently represented by [RFC 4646] and [RFC 4647] or its successor(s).) The default depends on the processing environment. Its value must be a valid language code (e.g. en-EN).

          • The collation option identifies how strings are to be compared with each other. Its value must be a valid collation URI. The only collation XProc processors must support is the Unicode Codepoint Collation http://www.w3.org/2005/xpath-functions/collation/codepoint. This is also its default. Support for other collations is implementation-defined.

          • If the stable option is set to false this indicates that there is no requirement to retain the original order of items that have equal values for all the sort keys.

          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 (&#10;), 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 (&#10;).

          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.

          Document properties

          All document properties are preserved.

          Erratum, April 2024

          The URI for the Unicode Codepoint Collation has been corrected to an http: URI rather than an https: one. The URI is an identifier and the correct identifier uses an http: URI. Implementations are encouraged to recognized collation URIs that begin with “https://www.w3.org/” and treat them as if they began “http://www.w3.org/”, with a warning, if practical.

          2.38. p:text-tail

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

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

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

          • If the count option is positive, the p:text-tail step returns the last count lines

          • If the count option is zero, the p:text-tail step returns all lines

          • If the count option is negative, the p:text-tail step returns all lines except the last count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.39. p:unarchive

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          exclude-filterRegularExpression()
          formatxs:QName?()
          include-filterRegularExpression()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0085It is a dynamic error if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0147It is a dynamic error if a specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the option is not a valid URI according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

          <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 format of the archive is determined as follows:

            • If the format option is specified, this determines the format of the archive. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.

            • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [ZIP] format.

            • 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 unarchiving. 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.

          • If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions 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 a specified value is not a valid XPath regular expression.

            If neither the include-filter option nor the exclude-filter option is specified, the p:unarchive step outputs on its result port all entries in the archive.

            If the include-filter option or the exclude-filter option is specified, the p:archive step outputs on the result port the entries from the archive that conform to the following rules:

            • If any include-filter pattern matches an archive entry's name, the entry is included in the output.

            • If any exclude-filter pattern matches an archive 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.

            • Names of entries in archives are always relative names. For instance, the name of a file called xyz.xml in a specs subdirectory in an archive is called in full specs/xyz.xml (and not /specs/xyz.xml).

            As a result: an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.

            The regular expressions specified in the include-filter and exclude-filter options will be matched against the path of the entry in the archive. The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • The relative-to option, when present, is used in creating the base URI of the unarchived documents. 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).

          • The override-content-types option can be used to partially override the content-type determination mechanism, as described in Section 2.4.1, “Overriding content types”.

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

          • If the relative-to option is present: Function p:urify() is called with the value of this option as second parameter ($basedir) and with the relative path of this document as it was in the archive as first parameter

          • If the relative-to option is not present: Function p:urify()is called with the value of the base URI of the archive appended with a “/” as second parameter ($baseDir) and the relative path of this document as it was in the archive as first parameter

          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:

          • With the relative-to option set to file:///x/y/z: file:///x/y/z/specs/xyz.xml

          • Without a relative-to option set: file:///a/b/c.zip/specs/xyz.xml

          Document properties

          No document properties are preserved. The base-uri property of each unarchived document is reflective of the base URI of the document.

          2.40. p:uncompress

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          content-typexs:string'application/octet-stream'
          formatxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0201It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the compression format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

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

          • If the format option is specified, this determines the compression format. Implementations must support the [GZIP] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0202) if the compression format cannot be understood, determined and/or processed.

          • If no format option is specified or its value is the empty sequence, the compression format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the compression format. Implementations should recognize archives in [GZIP] format.

          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:

          1. If the content-type option is specified, the uncompressed document must be interpreted according to that content-type. 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:XC0201) if the p:uncompress step cannot perform the requested content-type cast.

          2. In the absence of an explicit type, the content will be interpreted as content type application/octet-stream.

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly.

          2.41. p:unwrap

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than the document node or element nodes.
          Declaration

          <p:declare-steptype="p:unwrap">
               <p:inputport="source"content-types="xml html"/>
               <p:outputport="result"content-types="text xml html"/>
               <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.

          Note

          The matching applies to the entire document, not just the “top-most” matches. A pattern of the form h:div will replace allh:div elements, not just the top-most ones.

          This step produces a single document. Special cases:

          • If the document element is unwrapped, the result might not be well-formed XML.

            For instance unwrapping the root element of <!-- COMMENT --><root-element/> will result in a document node with a single comment node child, which is not well-formed.

          • If a document consisting of only an empty root element is unwrapped, the result will be a document node without children. The result document’s content type will not change.

          • If a document consisting of a root element containing only text is unwrapped, the result will be a document node with a single text node child. The result document’s content type will become “text/plain”.

          As specified in the core language specification: if the content type changes, the serialization document property, if present, will be removed.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.42. p:uuid

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          parametersmap(xs:QName, item()*)?()
          versionxs:integer?()
          Errors
          Error codeDescription
          err:C0060It is a dynamic error if the processor does not support the specified version of the UUID algorithm.
          Implementation details
          ImplementationDescription
          DefinedIf the version is not specified, the version of UUID computed is implementation-defined.
          DefinedSupport for other versions of UUID is implementation-defined.
          DefinedThe names and values of parameters to p:uuid are implementation-defined.
          Declaration

          <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:optionname="parameters"as="map(xs:QName, item()*)?"/>    
          </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 is implementation-defined. Some UUID schemes require additional parameters which may be provided in the parameters option. The names and values of parameters to p:uuid are 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 result is a text document.

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.43. p:wrap-sequence

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeDefault valueRequired
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Declaration

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

          Document properties

          No document properties are preserved. The document produced has no base-uri property.

          2.44. p:wrap

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than document, element, text, processing instruction, and comment nodes.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.45. p:www-form-urldecode

          The p:www-form-urldecode step decodes a x-www-form-urlencoded string into a JSON representation.

          Summary

          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeRequired
          valuexs:string✔ 
          Errors
          Error codeDescription
          err:C0037It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.
          Declaration

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

          Document properties

          The resulting JSON document has no properties apart from content-type. In particular, it has no base-uri.

          2.46. p:www-form-urlencode

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

          Summary

          Output portPrimarySequenceContent types
          result✔  text/plain 
          Option nameTypeRequired
          parametersmap(xs:string,xs:anyAtomicType+)✔ 
          Declaration

          <p:declare-steptype="p:www-form-urlencode">
               <p:outputport="result"content-types="text/plain"/>
               <p:optionname="parameters"required="true"as="map(xs:string,xs:anyAtomicType+)"/>
          </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.

          Document properties

          The resulting text document has no properties apart from content-type. In particular, it has no base-uri.

          2.47. p:xinclude

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          fixup-xml-basexs:booleanfalse()
          fixup-xml-langxs:booleanfalse()
          Errors
          Error codeDescription
          err:C0029It is a dynamic error if an XInclude error occurs during processing.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.48. p:xquery

          The p:xquery step applies an XQuery query to the sequence of documents provided on the source port.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          query  text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          parametersmap(xs:QName,item()*)?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0009It is a dynamic error if the specified XQuery version is not available.
          err:C0101It is a dynamic error 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.
          err:C0102It is a dynamic error 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.
          err:C0103It is a dynamic error if any error occurs during XQuery’s static analysis phase.
          err:C0104It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.
          Implementation details
          ImplementationDescription
          DefinedSupport for XQueryX is implementation-defined.
          DefinedIt is implementation-defined which XQuery version(s) is/are supported.
          DefinedThe point in time returned as the current dateTime is implementation-defined.
          DefinedThe implicit timezone is implementation-defined.
          DependentThe set of available documents (those that may be retrieved with a URI) is implementation-dependent.
          DependentThe set of available collections is implementation-dependent.
          Declaration

          <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 document root element is c:query, the text descendants of this element are considered the query.

            <c:query>
                string
            </c:query>

          • If the document root element is in the XQueryX namespace, the document is treated as an XQueryX-encoded query. Support for XQueryX is implementation-defined.

          • Otherwise the serialization of the document must be treated as the query. The document's serialization property (if present) is used.

          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:

          Statically known default collection type

          document()*

          Statically known namespaces:

          Unchanged from the implementation defaults. No namespace declarations in the XProc pipeline are automatically exposed in the static context.

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

          Context item

          The first document that appears on the source port.

          Context position

          1

          Context size

          1

          Variable values

          Any parameters passed in the parameters option augment any implementation-defined variable bindings known to the XQuery processor.

          Function implementations

          The function implementations provided by the XQuery processor.

          Current dateTime

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

          Implicit timezone

          The implicit timezone is implementation-defined.

          Available documents

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

          Available collections

          The set of available collections is implementation-dependent.

          Default collection

          The sequence of documents provided on the source port.

          2.48.1. Example

          The following pipeline applies XInclude processing and schema validation before using XQuery:

          Example 1. A Sample Pipeline Document
          <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>

          Where countp.xq might contain:

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

          2.48.2. Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the query. If the query does not establish a base URI, the document will not have one.

          2.49. p:xslt

          The p:xslt step invokes an XSLT stylesheet.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          stylesheet  xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          secondary ✔ any 
          Option nameTypeDefault value
          global-context-itemitem()?()
          initial-modexs:QName?()
          output-base-urixs:anyURI?()
          parametersmap(xs:QName,item()*)?()
          populate-default-collectionxs:boolean?true()
          static-parametersmap(xs:QName,item()*)?()
          template-namexs:QName?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0007It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.
          err:C0008It is a dynamic error if the stylesheet does not support a given mode.
          err:C0038It is a dynamic error if the specified xslt version is not available.
          err:C0039It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.
          err:C0056It is a dynamic error if the stylesheet does not provide a given template.
          err:C0093 It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.
          err:C0094It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.
          err:C0095It is a dynamic error if an error occurred during the transformation.
          err:C0096It is a dynamic error if the transformation is terminated by XSLT message termination.
          err:C0105It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.
          err:C0121It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which XSLT version(s) is/are supported.
          DefinedWhether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher).
          DependentHow XSLT message termination errors are reported to the XProc processor is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          Declaration

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

          2.49.1. Invoking an XSLT 3.0 stylesheet

          The value of global-context-item is used as global context item for the stylesheet invocation. If no value is supplied, the following applies:

          • If there is a single document on the source port, this document will become the value of the global-context-item option.

          • If there are none or multiple documents on the source port, the global context item is absent.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          If no value is supplied for template-name option an “Apply-template invocation” is performed. The documents that appear on source are taken to be the initial match selection. if populate-default-collection is true, they are also the default collection. If a value is supplied for the initial-mode option, this value is used as the initial-mode for the invocation. It is a dynamic error (err:XC0008) if the stylesheet does not support a given mode. If no value is supplied, nothing is supplied to the invocation, so the default behaviour defined for XSLT 3.0 could be applied.

          If a value is supplied for option template-name a “Call template invocation” is performed. The documents on port source are taken as the default collection in this case. Option initial-mode is ignored. It is a dynamic error (err:XC0056) if the stylesheet does not provide a given template.

          Independent of the way the stylesheet is invoked, the principal result(s) will appear on output port result while secondary result(s) will appear on output port secondary. The order in which result documents appear on the secondary port is implementation-dependent. Whether the raw results are delivered or a result tree is constructed, depends on the (explicit or implicit) setting for attribute build-tree of in the output-definition for the respective result. If a result tree is constructed, the result will be a text document if it is a single text node wrapped into a document node. Otherwise it will be either an XML document or an HTML document depending on the attribute method on the output-definition for the respective result. If no result tree is constructed, the stylesheet invocation may additionally deliver a sequence of atomic values, maps, or arrays. For each item in this sequence a JSON document will be constructed and appear on the steps output port.

          Option output-base-uri sets the base output URI per XSLT 3.0 specification. If a final result tree is constructed, this URI is used to resolve a relative URI reference. If no value is supplied for output-base-uri, the base URI of the first document in the source port's sequence is used. If no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error (err:XC0121) if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [RFC 3986].

          Note

          If no result tree is constructed for one of secondary results, a sequence of documents sharing the same value for attribute href may appear on output port result.

          2.49.2. Invoking an XSLT 2.0 stylesheet

          If a sequence of documents is provided on the source port, the first document is used as the initial context node. The whole sequence is also the default collection. If no documents are provided on the source port, the initial context node is undefined and the default collection is empty. It is a dynamic error (err:XC0094) if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          The value of option global-context-item is ignored if a stylesheet is invoked as per XSLT 2.0. 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:XC0007) if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function. It is a dynamic error (err:XC0008) if the specified initial mode cannot be applied to the specified stylesheet. It is a dynamic error (err:XC0056) if the specified template name cannot be applied to the specified stylesheet.

          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.

          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 no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error (err:XC0121) if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [RFC 3986].

          2.49.3. Invoking an XSLT 1.0 stylesheet

          The document provided for source is used the transformations source tree. It is a dynamic error (err:XC0039) if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used. The values supplied for options global-context-item, initial-mode, and template-name are ignored. If XSLT 1.0 is used, an empty sequence of documents must appear on the secondary port. 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.

          The key/value pairs supplied in parameters are used to set top-level parameters in the stylesheet. If the value is an atomic value or a node, its string value is supplied to the stylesheet. It is a dynamic error (err:XC0105) if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the tranformation. If the transformation does not establish a base URI, the document will not have one.

          3. Step Errors

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

          A [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space).

          If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

          Dynamic errors raised by steps are divided into two categories: dynamic errors and step errors. The distinction is largely that “step errors” tend to be related to a particular step or small group of steps (e.g., validation error) whereas the “dynamic errors” apply to many more steps (e.g., URI not available). There is also precedent for some of the error codes dating back to XProc 1.0.

          Dynamic Errors
          err:XD0011

          It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          See: Handling of ZIP archives, p:load

          err:XD0023

          It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.

          See: Loading XML data

          err:XD0043

          It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.

          See: Loading XML data

          err:XD0049

          It is a dynamic error if the text value is not a well-formed XML document

          See: Casting from a text media type, Loading XML data

          err:XD0057

          It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          See: Casting from a text media type, Loading JSON data

          err:XD0058

          It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.

          See: Casting from a text media type, Loading JSON data

          err:XD0059

          It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          See: Casting from a text media type, Loading JSON data

          err:XD0060

          It is a dynamic error if the text document can not be converted into the XPath data model

          See: Casting from a text media type, Loading text data

          err:XD0062

          It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.

          See: p:load

          err:XD0064

          It is a dynamic error if the base URI is not both absolute and valid according to .

          See: p:archive, p:archive-manifest, p:load, p:make-absolute-uris, p:set-properties, p:unarchive

          err:XD0070

          It is a dynamic error 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 .

          See: p:set-properties

          err:XD0078

          It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.

          See: Loading HTML data

          err:XD0079

          It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.

          See: Overriding content types, p:cast-content-type, p:http-request, p:http-request, p:load, p:text-join, p:uncompress

          Step Errors
          err:XC0001

          It is a dynamic error if the value of option override-content-type is not a text media type.

          See: p:text-join

          err:XC0003

          It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.

          See: p:http-request

          err:XC0007

          It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0008

          It is a dynamic error if the stylesheet does not support a given mode.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0009

          It is a dynamic error if the specified XQuery version is not available.

          See: p:xquery

          err:XC0013

          It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.

          See: p:rename

          err:XC0014

          It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.

          See: p:namespace-rename

          err:XC0019

          It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.

          See: p:compare

          err:XC0023

          It is a dynamic error if the selection pattern matches a node which is not an element.

          See: p:add-attribute, p:delete, p:insert, p:label-elements, p:make-absolute-uris, p:rename, p:replace, p:set-attributes, p:unwrap, p:wrap

          err:XC0024

          It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.

          See: p:insert

          err:XC0025

          It is a dynamic error 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”.

          See: p:insert

          err:XC0029

          It is a dynamic error if an XInclude error occurs during processing.

          See: p:xinclude

          err:XC0030

          It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          See: p:http-request

          err:XC0036

          It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.

          See: p:hash

          err:XC0037

          It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.

          See: p:www-form-urldecode

          err:XC0038

          It is a dynamic error if the specified xslt version is not available.

          See: p:xslt

          err:XC0039

          It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0050

          It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.

          See: p:store

          err:XC0056

          It is a dynamic error if the stylesheet does not provide a given template.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0058

          It is a dynamic error if the all and relative options are both true.

          See: p:add-xml-base

          err:XC0059

          It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.

          See: p:add-attribute, p:set-attributes

          err:XC0060

          It is a dynamic error if the processor does not support the specified version of the UUID algorithm.

          See: p:uuid

          err:XC0062

          It is a dynamic error if the match option matches a namespace node.

          See: p:delete

          err:XC0069

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

          See: p:set-properties

          err:XC0071

          It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.

          See: p:cast-content-type

          err:XC0072

          It is a dynamic error if the c:data contains content is not a valid base64 string.

          See: Casting from an XML media type

          err:XC0073

          It is a dynamic error if the c:data element does not have a content-type attribute.

          See: Casting from an XML media type

          err:XC0074

          It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.

          See: Casting from an XML media type

          err:XC0076

          It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.

          See: p:compare

          err:XC0077

          It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.

          See: p:compare

          err:XC0078

          It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.

          See: p:http-request

          err:XC0079

          It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          See: p:archive, p:archive-manifest, p:cast-content-type, p:compress, p:unarchive, p:uncompress

          err:XC0080

          It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          See: Handling of ZIP archives

          err:XC0081

          It is a dynamic error if the format of the archive does not match the format as specified in the format option.

          See: p:archive, p:archive-manifest

          err:XC0084

          It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          See: p:archive

          err:XC0085

          It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.

          See: p:archive, p:archive-manifest, p:unarchive

          err:XC0092

          It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          See: p:namespace-rename

          err:XC0093

          It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.

          See: p:xslt

          err:XC0094

          It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0095

          It is a dynamic error if an error occurred during the transformation.

          See: p:xslt

          err:XC0096

          It is a dynamic error if the transformation is terminated by XSLT message termination.

          See: p:xslt

          err:XC0098

          It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.

          See: p:text-sort

          err:XC0099

          It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.

          See: p:text-sort

          err:XC0100

          It is a dynamic error if the document on port manifest does not conform to the given schema.

          See: p:archive, The archive manifest

          err:XC0101

          It is a dynamic error 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.

          See: p:xquery

          err:XC0102

          It is a dynamic error 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.

          See: p:xquery

          err:XC0103

          It is a dynamic error if any error occurs during XQuery’s static analysis phase.

          See: p:xquery

          err:XC0104

          It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.

          See: p:xquery

          err:XC0105

          It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0106

          It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.

          See: p:json-merge

          err:XC0107

          It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.

          See: p:json-merge

          err:XC0108

          It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.

          See: p:namespace-delete

          err:XC0109

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

          See: p:namespace-delete

          err:XC0110

          It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.

          See: p:json-merge

          err:XC0111

          It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.

          See: p:json-join

          err:XC0112

          It is a dynamic error if more than one document appears on the port manifest.

          See: p:archive

          err:XC0119

          It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.

          See: p:json-join

          err:XC0120

          It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.

          See: p:archive-manifest, p:unarchive

          err:XC0121

          It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0122

          It is a dynamic error if the given method is not supported.

          See: p:http-request

          err:XC0123

          It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0124

          It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0125

          It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.

          See: p:http-request

          err:XC0126

          It is a dynamic error if the XPath expression in assert evaluates to false.

          See: p:http-request

          err:XC0127

          It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.

          See: p:http-request

          err:XC0128

          It is a dynamic error if the URI’s scheme is unknown or not supported.

          See: p:http-request

          err:XC0131

          It is a dynamic error if the processor cannot support the requested encoding.

          See: p:http-request

          err:XC0132

          It is a dynamic error if the override content encoding cannot be supported.

          See: p:http-request

          err:XC0133

          It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          See: Construction of a multipart request

          err:XC0146

          It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          See: Overriding content types

          err:XC0147

          It is a dynamic error if the specified value is not a valid XPath regular expression.

          See: Overriding content types, p:text-replace, p:unarchive

          err:XC0150

          It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.

          See: p:split-sequence

          err:XC0201

          It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.

          See: p:uncompress

          err:XC0202

          It is a dynamic error if the compression format cannot be understood, determined and/or processed.

          See: p:compress, p:uncompress

          err:XC0203

          It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          See: Construction of a multipart request

          A. Conformance

          Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

          [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

          [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

          A.1. Implementation-defined features

          The following features are implementation-defined:

          1. The list of formats supported by the p:archive step is implementation-defined. See Section 2.3, “p:archive”.
          2. The list of archive formats that can be modified by p:archive is implementation-defined. See Section 2.3, “p:archive”.
          3. The semantics of any additional attributes, elements and their values are implementation-defined. See Section 2.3, “p:archive”.
          4. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          5. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          6. It is implementation-defined how the step determines the archive's format. See Section 2.3, “p:archive”.
          7. The c:archive root element may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          8. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          9. It is implementation-defined what other compression methods are supported. See Section 2.3.1, “The archive manifest”.
          10. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          11. It is implementation-defined what compression levels are supported. See Section 2.3.1, “The archive manifest”.
          12. The c:entry elements may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          13. The p:archive step may support additional, implementation-defined commands for ZIP files. See Section 2.3.2, “Handling of ZIP archives”.
          14. The actual parameter names supported by p:archive for a particular format are implementation-defined. See Section 2.3.2, “Handling of ZIP archives”.
          15. It is implementation-defined what other formats are supported. See Section 2.4, “p:archive-manifest”.
          16. It is implementation-defined how the step determines the archive's format. See Section 2.4, “p:archive-manifest”.
          17. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.4, “p:archive-manifest”.
          18. Additional information provided for entries in p:archive-manifest is implementation-defined. See Section 2.4, “p:archive-manifest”.
          19. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.5, “p:cast-content-type”.
          20. The precise nature of the conversion from XML to JSON is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          21. Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          22. Casting from an HTML media type to a JSON media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          23. Casting from an HTML media type to any other media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          24. It is implementation-defined whether other result formats are supported. See Section 2.5.3, “Casting from a JSON media type”.
          25. Casting from a JSON media type to an HTML media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          26. Casting from a JSON media type to any other media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          27. The precise way in which text documents are parsed into the XPath data model is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          28. Casting from a text media type to any other media type is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          29. Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          30. Casting from any other media type to any other media type is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          31. Implementations of p:compare must support the deep-equal method; other supported methods are implementation-defined. See Section 2.6, “p:compare”.
          32. 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. See Section 2.6, “p:compare”.
          33. It is implementation-defined what other formats are supported. See Section 2.7, “p:compress”.
          34. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.7, “p:compress”.
          35. It is implementation-defined what other algorithms are supported. See Section 2.12, “p:hash”.
          36. It is implementation-defined which HTTP methods are supported. See Section 2.13, “p:http-request”.
          37. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined. See Section 2.13, “p:http-request”.
          38. Other key value pairs in map “auth” are implementation-defined. See Section 2.13, “p:http-request”.
          39. It is implementation-defined which other key/value pairs in the parameters option are supported. See Section 2.13, “p:http-request”.
          40. The default behaviour in case of a redirect response is implementation-defined. See Section 2.13, “p:http-request”.
          41. It is implementation-defined how a multipart boundary is constructed. See Section 2.13.1, “Construction of a multipart request”.
          42. It is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.16, “p:json-join”.
          43. It is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.17, “p:json-merge”.
          44. In the absence of an explicit type, the content type is implementation-defined See Section 2.19, “p:load”.
          45. Additional XML parameters are implementation-defined. See Section 2.19.1, “Loading XML data”.
          46. Text parameters are implementation-defined. See Section 2.19.2, “Loading text data”.
          47. Additional JSON parameters are implementation-defined. See Section 2.19.3, “Loading JSON data”.
          48. The precise way in which HTML documents are parsed into the XPath data model is implementation-defined. See Section 2.19.4, “Loading HTML data”.
          49. HTML parameters are implementation-defined. See Section 2.19.4, “Loading HTML data”.
          50. How a processor interprets other media types is implementation-defined. See Section 2.19.5, “Loading binary data”.
          51. Parameters for other media types are implementation-defined. See Section 2.19.5, “Loading binary data”.
          52. Support for other collations is implementation-defined. See Section 2.37, “p:text-sort”.
          53. It is implementation-defined what other formats are supported. See Section 2.39, “p:unarchive”.
          54. It is implementation-defined how the step determines the archive's format. See Section 2.39, “p:unarchive”.
          55. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.39, “p:unarchive”.
          56. It is implementation-defined what other formats are supported. See Section 2.40, “p:uncompress”.
          57. It is implementation-defined how the step determines the compression format. See Section 2.40, “p:uncompress”.
          58. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.40, “p:uncompress”.
          59. If the version is not specified, the version of UUID computed is implementation-defined. See Section 2.42, “p:uuid”.
          60. Support for other versions of UUID is implementation-defined. See Section 2.42, “p:uuid”.
          61. The names and values of parameters to p:uuid are implementation-defined. See Section 2.42, “p:uuid”.
          62. Support for XQueryX is implementation-defined. See Section 2.48, “p:xquery”.
          63. It is implementation-defined which XQuery version(s) is/are supported. See Section 2.48, “p:xquery”.
          64. The point in time returned as the current dateTime is implementation-defined. See Section 2.48, “p:xquery”.
          65. The implicit timezone is implementation-defined. See Section 2.48, “p:xquery”.
          66. It is implementation-defined which XSLT version(s) is/are supported. See Section 2.49, “p:xslt”.
          67. Whether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher). See Section 2.49, “p:xslt”.

          A.2. Implementation-dependent features

          The following features are implementation-dependent:

          1. 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. See Section 2.20, “p:make-absolute-uris”.
          2. The set of available documents (those that may be retrieved with a URI) is implementation-dependent. See Section 2.48, “p:xquery”.
          3. The set of available collections is implementation-dependent. See Section 2.48, “p:xquery”.
          4. How XSLT message termination errors are reported to the XProc processor is implementation-dependent. See Section 2.49, “p:xslt”.
          5. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.
          6. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.

          B. References

          B.1. Normative References

          [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

          [W3C XML Schema: Part 2] XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, editors. World Wide Web Consortium, 28 October 2004.

          [XPath 3.1] XML Path Language (XPath) 3.1. Jonathan Robie, Michael Dyck, Josh Spiegel, editors. W3C Recommendation. 21 March 2017.

          [XPath and XQuery Functions and Operators 3.1] XPath and XQuery Functions and Operators 3.1. Michael Kay, editor. W3C Recommendation. 21 March 2017

          [XSLT 3.0] XSL Transformations (XSLT) Version 3.0. Michael Kay, editor. W3C Recommendation. 8 June 2017.

          [XInclude] XML Inclusions (XInclude) Version 1.0 (Second Edition). Jonathan Marsh, David Orchard, and Daniel Veillard, editors. W3C Recommendation. 15 November 2006.

          [RFC 1321] RFC 1321: The MD5 Message-Digest Algorithm. R. Rivest. Network Working Group, IETF, April 1992.

          [RFC 2046] RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein, editors. Internet Engineering Task Force. November, 1996.

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

          [RFC 2617] RFC 2617: HTTP Authentication: Basic and Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. June, 1999 .

          [RFC 3986] RFC 3986: Uniform Resource Identifier (URI): General Syntax. T. Berners-Lee, R. Fielding, and L. Masinter, editors. Internet Engineering Task Force. January, 2005.

          [RFC 4646] RFC 4646: Tags for Identifying Languages. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [RFC 4647] RFC 4647: Matching of Language Tags. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [BCP 47] Best Current Practices 47. Concatenation of RFC 4646: Tags for Identifying Languages, ed. A. Phillips and M. Davis, September 2006, http://www.ietf.org/rfc/bcp/bcp47.txt, and RFC 4647: Matching of Language Tags, ed. A Phillips and M. Davis, September 2006, http://www.rfc-editor.org/rfc/bcp/bcp47.txt. Internet Engineering Task Force (IETF). September, 2006.

          [CRC32] “32-Bit Cyclic Redundancy Codes for Internet Applications”, The International Conference on Dependable Systems and Networks: 459. 10.1109/DSN.2002.1028931. P. Koopman. June 2002.

          C. Glossary

          dynamic error

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

          implementation-defined

          An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

          implementation-dependent

          An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

          D. Ancillary files

          This specification includes by reference a number of ancillary files.

          steps.xpl

          An XProc step library for the declared steps.

          E. Credits

          This document is derived from XProc: An XML Pipeline Language published by the W3C. It was developed by the XML Processing Model Working Group and edited by Norman Walsh, Alex Miłowski, and Henry Thompson.

          The editors of this specification extend their gratitude to everyone who contributed to this document and all of the versions that came before it.

          F. Change Log

          This appendix catalogs non-editorial changes made after the August 2020 “last call” draft:

          1. Allow the output of the p:insert step to be text. (issue 583.)

          2. Clarified that the manifest has precedence in the p:archive step. (issue 462.)

          3. Changed the type of several options from xs:token to xs:string (issue 490.)

          4. Changed the type of the parameters option from map(xs:string,xs:untypedAtomic+) to map(xs:string,xs:anyAtomicType+). (issue 491.)

          These are the non-editorial changes made after the February 2020 “last call” draft:

          1. For p:cast-content-type the expected result type for casting a c:param-set document to “application/json” was specified as map(xs:QName, xs:string). (2020-03-15)

          2. In p:http-request, instead of using all document properties (with a few explicit exceptions) as headers, only document properties in the http://www.w3.org/ns/xproc-http namespace will be used. (2020-03-18)

          3. Section 2.3.1, “The archive manifest”: An attribute c:entry/@content-type was added to the archive manifest, to be filled by the p:archive-manifest step. (2020-03-20)

          4. A static-parameters was added to p:xslt. (2020-03-23)

          5. The override-content-types option was added to p:archive-manifest and p:unarchive. (2020-03-30)

          6. Clarified the regular expression matching for p:text-replace and p:unarchive. Added an error code for invalid regular expressions. (2020-04-02)

          7. Replaced errors XC0070 and XC0130 with XD0079. (2020-04-09)

          8. Changed signature of p:split-sequence so that any document can appear one port source. (2020-05-22)

          9. Change the behavior of the global-context-item option of p:xslt. (2020-06-10)

          10. Clarified which steps may produce PSVI annotations. (2020-06-09)

          11. Clarified the behaviour in p:archive: A missing resource referenced by c:archive/c:entry/@href is only an error for command = 'create'. (2020-06-11)

          12. Option populate-default-collection is added to the signature of p:xslt. (2020-06-20)

          13. Clarified how the default content-type header of p:http-request is constructed if a single document appears on source port. (2020-06-20)

          14. Added error (XD0079) to p:http-request and p:load for invalid content-types. (2020-06-23)

          15. Changed signature of the result port of p:load to sequence="false" and adapted the prose accordingly. (2020-06-24)

          \ No newline at end of file +

          XProc 3.0+: Standard Step Library

          Draft Community Group Report

          Editor's Draft at (build 4546)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/steps/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against the 3.0 specification
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020, 2021, 2022 the Contributors to the XProc 3.0+: Standard Step Library specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the standard step vocabulary of XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

          If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

          Note

          This draft is the “editor’s working draft” and includes changes made after the XProc 3.0 standard step specification was released.

          This document is derived from XProc: An XML Pipeline Language published by the W3C.

          1. Introduction

          This specification describes the standard, required atomic XProc steps. A machine-readable description of these steps may be found in steps.xpl.

          Many atomic steps are available for [XProc 3.0]. They are described in several specifications. This specification describes the general background common to all steps. A conformant processor must implement all of the steps in this specification. Additional steps may also be implemented.

          The types given for options should be understood as follows:

          • Types in the XML Schema namespace, identified as QNames with the xs: prefix, as per the XML Schema specification with one exception. Anywhere an xs:QName is specified, an EQName is allowed.

          • XPathExpression: As a string per [W3C XML Schema: Part 2], including whitespace normalization, and the further requirement to be a conformant Expression per [XPath 3.1].

          • XSLTSelectionPattern: As a string per [XSLT 3.0] conforming to an XSLT selection pattern.

          • XPathSequenceType: An XPath sequence type.

          • ContentType: A media type as defined in [RFC 2046].

          • ContentTypes: As a whitespace separated list of media types as defined in [RFC 2046].

          Option values are often expressed using the shortcut syntax. In these cases, the option shortcuts are generally treated as value templates. However, for options of type map() or array(), an expression is required (there is no non-expression string which can ever be a legal value for a map or array). Given that every value entered this way will have to be a value template, and consequently every curly brace contained within the expression will have to be escaped, values of type map or array are defined to be expressions directly.

          Some aspects of documents are generally unchanged by steps:

          • When a step in this library produces an output document, the base URI of the output is the base URI of the step's primary input document unless the step's process explicitly sets an xml:base attribute or the step's description explicitly states how the base URI is constructed.

          • Steps are responsible for describing how document properties are transformed as documents flow through them. Many steps claim that the specified properties are preserved. Generally, it is the responsibility of the pipeline author to determine when this is inapropriate and take corrective action. However, it is the responsibility of the pipeline processor to assure that the content-type property is correct. If a step transforms a document in a manner that is inconsistent with the content-type property (accepting an XML document on the source port but producing a text document on the result, for example), the processor must assure that the content-type property is appropriate. If a step changes the content-type in this way, it must also remove the serialization property

          Also, in this specification, several steps use this element for result information:

          <c:result>
              string
          </c:result>

          When a step uses an XPath to compute an option value, the XPath context is as defined in [XProc 3.0].

          When a step specifies a particular version of a technology, implementations must implement that version or a subsequent version that is backwards compatible with that version. At user-option, they may implement other non-backwards compatible versions.

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

          As described in PSVIs in XProc in XProc 3.0: An XML Pipeline Language, steps may not produce PSVI output unless that behavior is explicitly described. In this specification, the steps that may produce PSVI output are the “identity” steps: p:identity, p:store, and p:split-sequence (which must preserve PSVI properties that appear on their inputs). In addition, the p:xslt and p:xquery steps may return documents with PSVI annotations.

          2. Step library

          A conformant processor must support all of these steps.

          2.1. p:add-attribute

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attribute-namexs:QName ✔ 
          attribute-valuexs:string ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the selection pattern matches a node which is not an element.
          err:C0059It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

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

          Note

          If multiple attributes need to be set on the same element(s), the p:set-attributes step can be used to set them all at once.

          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 is “xmlns” or 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.

          Document properties

          All document properties are preserved.

          2.2. p:add-xml-base

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          allxs:booleanfalse()
          relativexs:booleantrue()
          Errors
          Error codeDescription
          err:C0058It is a dynamic error if the all and relative options are both true.
          Declaration

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

          • For every element that is a child of the document node: force the element to have an xml:base attribute with the document's [base URI] property's value as its value.

          • For other elements:

            • If the all option has the value true, force the element to have an xml:base attribute with the element's [base URI] value as its value.

            • If the element's [base URI] is different from the its parent's [base URI], force the element to have an xml:base attribute with the following value: if the value of the relative option is true, a string which, when resolved against the parent's [base URI], will give the element's [base URI], otherwise the element's [base URI].

            • Otherwise, if there is an xml:base attribute present, remove it.

          Document properties

          All document properties are preserved.

          2.3. p:archive

          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.

          Summary

          Input portPrimarySequenceContent typesDefault binding
          source✔ ✔ any 
          manifest ✔ xml p:empty
          archive ✔ any p:empty
          Output portPrimarySequenceContent typesDefault binding
          result✔  any 
          report  application/xml 
          Option nameTypeDefault value
          formatxs:QName'zip'
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0080It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0084It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0100It is a dynamic error if the document on port manifest does not conform to the given schema.
          err:C0112It is a dynamic error if more than one document appears on the port manifest.
          err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedThe list of formats supported by the p:archive step is implementation-defined.
          DefinedThe list of archive formats that can be modified by p:archive is implementation-defined.
          DefinedThe semantics of any additional attributes, elements and their values are implementation-defined.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe c:archive root element may contain additional implementation-defined attributes.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what other compression methods are supported.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what compression levels are supported.
          DefinedThe c:entry elements may contain additional implementation-defined attributes.
          DefinedThe p:archive step may support additional, implementation-defined commands for ZIP files.
          DefinedThe actual parameter names supported by p:archive for a particular format are implementation-defined.
          Declaration

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

          source

          The (primary) source port is used to provide documents to be archived (for instance constructed by other steps). How and which of these documents are processed is governed by the document(s) appearing on the other input ports and the combination of options and parameters. See below for details. It is a dynamic error (err:XC0084) if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          manifest

          The manifest port can receive a manifest document that tells the step how to construct the archive. If no manifest document is provided on this port, a default manifest is constructed automatically. See Section 2.3.1, “The archive manifest”. It is a dynamic error (err:XC0100) if the document on port manifest does not conform to the given schema.

          It is a dynamic error (err:XC0112) if more than one document appears on the port manifest.

          The default input for this port is the empty sequence.

          archive

          The archive port is used to provide the step with existing archive(s) for operations like update, freshen or merge. Handling of ZIP files supports modifying archives appearing on the archive port (Section 2.3.2, “Handling of ZIP archives”). The list of archive formats that can be modified by p:archive is implementation-defined. For instance an implementation that supports archive merging may accept more than one document on the archive port.

          The default input for this port is the empty sequence.

          The p:archive step has the following output ports:

          result

          The (primary) result port will output the resulting archive.

          report

          The report port will output a report about the archiving operation. This will be the same as the manifest (as provided on the manifest port or automatically created if there was no manifest provided), optionally amended with additional attributes and/or elements. The semantics of any additional attributes, elements and their values are implementation-defined.

          The p:archive step has the following options:

          format

          The format of the archive can be specified using the format option. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.

          parameters

          The parameters option can be used to supply parameters to control the archiving. Several parameters are defined for processing zip archives, but implementations are free to use additional parameters and to use parameters for controlling how other archive formats are processed. 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.

          relative-to

          The relative-to option is used in creating a manifest when no manifest is provided on the manifest port. If a manifest is present this option is not used. If the option’s value is a relative URI, 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 format of the archive is determined as follows:

          • If the format option is specified, this determines the format of the archive. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0081) if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the archive port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [ZIP] format.

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

          2.3.1. The archive manifest

          An archive manifest specifies which documents will be considered in processing the archive. Every entry in the archive must have a corresponding entry in the manifest; if no such entry is provided, one will be constructed automatically (see below). If manifest entries are provided for documents that are not in the archive, how those are processed depends on the archive type and the parameters passed to the step.

          A manifest is represented by a c:archive root element:

          <c:archive>
              (c:entry* &
               anyNonXProcElement*)
          </c:archive>

          The c:archive root element may contain additional implementation-defined attributes.

          All entries in the archive must be present as c:entry child elements:

          <c:entry
            name = string
            href = anyURI
            comment? = string
            method? = string
            level? = string
            content-type? = ContentType>
              anyElement*
          </c:entry>

          • The name attribute specifies the name of the entry in the archive.

          • The href attribute must be a valid URI according to [RFC 3986]. If its value is relative, it is made absolute against the base URI of the manifest. There are two possible cases:

            • If the (absolute) href value is exactly the same as the base URI of a document appearing on the source port, that document is associated with this entry. If this entry is to be added to the archive, the associated document will be used. (The serialization document property can be used to provide serialization properties.)

            • If no document on the source port has a base URI that is exactly the same as the (absolute) href value, the document at the specified URI is associated with this entry. These documents are stored in the archive “as is”; they must not be parsed and re-serialized.

          • The method attribute specifies how the entry should be compressed. The default compression method is implementation-defined. Implementations must support no compression, specified with the value none. It is implementation-defined what other compression methods are supported.

          • The level attribute specifies the level of compression. The default compression method is implementation-defined. It is implementation-defined what compression levels are supported.

          • The content-type attribute specifies the content-type of the entry as detected by the processor. It will be set by p:archive-manifest in constructing the manifest. It will be ignored by p:archive.

          The p:archive step should strive to retain the order of the c:entry elements when constructing the archive. For instance, an e-book in EPUB format has a non-compressed entry that must be first in the archive. It should be possible to construct such an archive using p:archive.

          The c:entry elements may contain additional implementation-defined attributes.

          If no manifest entry is provided for a document appearing on the source port, the step will create a manifest entry for the document. (If no document arrives on the manifest port at all, a complete manifest document will be created.)

          In a constructed manifest entry:

          • The entry’s href value is the base URI of the document.

          • The entry’s name value is derived from the base URI of the document and the relative-to option.

            • First, the value of the relative-to option is made absolute. If the initial substring of the base URI is exactly the same as the resulting absolute value, then the name is the portion of the base URI that follows that initial substring.

            • If there is no relative-to option or if its value is not the initial substring of the base URI of the document, the name is the path portion of the URI (per [RFC 3986]). If the path portion begins with an initial slash, that slash is removed.

          It is a dynamic error (err:XC0100) if an archive manifest is invalid according to the specification.

          2.3.2. Handling of ZIP archives

          The format of the archive can be specified using the format option. Implementations must support the [ZIP] format, specified with the value zip.

          When ZIP archives are processed, every name in the manifest must be a relative path without a leading slash.

          The parameters option can be used to supply parameters to control the archiving. For the zip format, the following parameters must be supported:

          command

          Specifies what operation to perform. If not specified, its default value is update. Implementations must support the values update, create, freshen, and delete. The p:archive step may support additional, implementation-defined commands for ZIP files. Unless otherwise specified, exactly zero or one ZIP archive can appear on the archive port for the commands described below. If no archive appears, a new archive will be created.

          update

          When the command parameter is set to update, the ZIP archive will be updated:

          1. For every entry in the ZIP file:

            • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is updated with the document identified by the c:entry in the manifest.

            • If the manifest does not contain a matching c:entry, the ZIP entry name is resolved against the base URI of the ZIP file.

              • If a document exists at that URI and either has no timestamp or has a timestamp more than the timestamp in the ZIP file, the entry in the ZIP file will be updated with the document at the resolved URI.

              • If no document exists at that URI, or the document cannot be accessed, or the document has a timestamp and the timestamp in the ZIP archive is more recent than the timestamp of the document, then the ZIP entry is unchanged.

          2. For every c:entry in the manifest that does not have a matching entry in the ZIP file, the ZIP file will be updated by adding the document identified by the c:entry to the ZIP file.

          create

          When the command parameter is set to create, the ZIP archive will be created. Creating a ZIP archive behaves exactly like update except that any timestamps are ignored; every ZIP entry will be updated or created if there is a c:entry or matching document for it. The document must be obtained by dereferencing the URI in href. It is a dynamic error (err:XD0011) if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          freshen

          When the command parameter is set to freshen, existing files in the ZIP archive may be updated, but no new files will be added. Freshing a ZIP archive behaves exactly like update except that only entries that already exist in the ZIP archive are considered.

          delete

          When the command parameter is set to delete, exactly one document in ZIP format must appear on the archive port. For every entry in the ZIP file:

          • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is removed from the ZIP archive.

          If the manifest contains c:entry elements which do not have a matching entry in the ZIP archive, they are simply ignored.

          level

          Specifies the default compression level for files added to or updated in the archive. If the level attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “smallest”, “fastest”, “default”, “huffman”, and “none”.

          method

          Specifies the default compression method for files added to or updated in the archive. If the method attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “none” and “deflated”.

          It is a dynamic error (err:XC0080) if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          Implementations of other archive formats should use the same parameter names if applicable. The value spaces for these parameters may be format-specific though. The actual parameter names supported by p:archive for a particular format are implementation-defined.

          Document properties

          No document properties are preserved. The archive has no base-uri.

          2.4. p:archive-manifest

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          formatxs:QName?()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0146It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedAdditional information provided for entries in p:archive-manifest is implementation-defined.
          Declaration

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

          • If the format option is specified, this determines the format of the archive. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0081) if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [ZIP] format.

          It is a dynamic error (err:XC0085) if the format of the archive 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.39, “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.

          2.4.1. Overriding content types

          The override-content-types option can be used to partially override the content-type determination mechanism. If present, it must be an array of arrays, where the inner arrays consist of exactly two strings:

          • The first member in an inner array 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.

          • The second member in an inner array must be a valid a MIME content-type. 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:XC0146) if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          Determining an archive entry's content-type is as follows:

          • The XPath regular expressions (the first members of the inner arrays) will be matched against the path of the entry in the archive. This will be done in the order of appearance in the outer array (so order is significant). The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • If a match is found, the content-type (the second member of the inner array for which the match was found) is used as the entry's content-type.

          • If no match was found for all inner arrays, the normal (implementation-defined) mechanism for determining the content-type is used.

          For example: setting the override-content-types option to [ ['.rels$', 'application/xml'], ['^special/', 'application/octet-stream'] ] means that all files ending with .rels will get the content-type application/xml. All files in the archive's special directory (including sub-directories) will get the content-type application/octet-stream.

          Document properties

          No document properties are preserved. The manifest has no base-uri.

          2.5. p:cast-content-type

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          content-typexs:string ✔ 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0071It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.
          err:C0072It is a dynamic error if the c:data contains content is not a valid base64 string.
          err:C0073It is a dynamic error if the c:data element does not have a content-type attribute.
          err:C0074It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:D0049It is a dynamic error if the text value is not a well-formed XML document
          err:D0057It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the text document can not be converted into the XPath data model
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedThe precise nature of the conversion from XML to JSON is implementation-defined.
          DefinedCasting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.
          DefinedCasting from an HTML media type to a JSON media type is implementation-defined.
          DefinedCasting from an HTML media type to any other media type is implementation-defined.
          DefinedIt is implementation-defined whether other result formats are supported.
          DefinedCasting from a JSON media type to an HTML media type is implementation-defined.
          DefinedCasting from a JSON media type to any other media type is implementation-defined.
          DefinedThe precise way in which text documents are parsed into the XPath data model is implementation-defined.
          DefinedCasting from a text media type to any other media type is implementation-defined.
          DefinedCasting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.
          DefinedCasting from any other media type to any other media type is implementation-defined.
          Declaration

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

          2.5.1. Casting from an XML media type

          • Casting from one XML media type to another simply changes the “content-type” document property.

          • Casting from an XML media type to an HTML media type changes the “content-type” document property and removes any serialization property.

          • Casting from an XML media type to a JSON media type converts the XML into JSON. The precise nature of the conversion from XML to JSON is implementation-defined. If the input document is an XML representation of JSON as defined in [XPath and XQuery Functions and Operators 3.1], implementations must produce the same result as fn:parse-json(fn:xml-to-json()) by default. If the input document has a c:param-set document element, an instance of map(xs:QName, xs:string)must be returned that represents the document's c:param elements. The serialization property is removed.

          • Casting from an XML media type to a text media type serializes the XML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an XML media type to any other media type must support the case where the input document is a c:data document. The resulting document will have the specified media type and a representation that is the content of the c:data element after decoding the base64 encoded content The serialization property is removed.

            It is a dynamic error (err:XC0072) if the c:data contains content is not a valid base64 string.

            It is a dynamic error (err:XC0073) if the c:data element does not have a content-type attribute.

            It is a dynamic error (err:XC0074) if the content-type is supplied and is not the same as the content-type specified on the c:data element.

            Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.

          2.5.2. Casting from an HTML media type

          • Casting from an HTML media type to an XML media type changes “content-type” document property and removes any serialization property.

          • Casting from an HTML media type to another HTML media type changes “content-type” document property.

          • Casting from an HTML media type to a JSON media type is implementation-defined.

          • Casting an an HTML media type to a text media type serializes the HTML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an HTML media type to any other media type is implementation-defined.

          2.5.3. Casting from a JSON media type

          • Casting from a JSON media type to an XML media type converts the JSON into XML. An implementation must support the format specified in section “XML Representation of JSON” of [XPath and XQuery Functions and Operators 3.1] as default for the resulting XML. It is implementation-defined whether other result formats are supported. The serialization property is removed.

          • Casting from a JSON media type to an HTML media type is implementation-defined.

          • Casting from a JSON media type to another JSON media type changes “content-type” document property.

          • Casting from a JSON media type to a text media type serializes the JSON document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from a JSON media type to any other media type is implementation-defined.

          2.5.4. Casting from a text media type

          • Casting from a text media type to an XML media type parses the text value of the document on source port by calling fn:parse-xml. It is a dynamic error (err:XD0049) if the text value is not a well-formed XML document. The serialization property is removed.

          • Casting from a text media type to an HTML media type parses the text value of the document on source port into an XPath data model document that contains a tree of elements, attributes, and other nodes. The precise way in which text documents are parsed into the XPath data model is implementation-defined.It is a dynamic error (err:XD0060) if the text document can not be converted into the XPath data model. The serialization property is removed.

          • Casting from a text media type to a JSON media type parses the text value of the document on source port by calling fn:parse-json($doc, $par) where $doc is the text document and $par is the parameter option. It is a dynamic error (err:XD0057) if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation. It is a dynamic error (err:XD0058) if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys. It is a dynamic error (err:XD0059) if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present. The serialization property is removed.

          • Casting from a text media type to another text media type changes “content-type” document property.

          • Casting from a text media type to any other media type is implementation-defined.

          2.5.5. Casting from any other media type

          • Casting from a non-XML media type to an XML media type produces an XML document with a c:data document element. The original media type will be preserved in the content-type attribute on the c:data element.

            <c:data
              content-type = ContentType
              charset? = string
              encoding? = string>
                string
            </c:data>

            The content of the c:data element is the base64 encoded representation of the non-XML content. The serialization property is removed.

          • Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.

          • Casting from any other media type to any other media type is implementation-defined.

          Document properties

          All document properties are preserved except the content-type property which is updated accordingly and the serialization property which is removed by some casting methods.

          2.6. p:compare

          The p:compare step compares two documents for equality.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          alternate  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          differences ✔ any 
          Option nameTypeDefault value
          fail-if-not-equalxs:booleanfalse()
          methodxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0019It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.
          err:C0076It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.
          err:C0077It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.
          Implementation details
          ImplementationDescription
          DefinedImplementations of p:compare must support the deep-equal method; other supported methods are implementation-defined.
          DefinedIf 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.
          Declaration

          <p:declare-steptype="p:compare">
               <p:inputport="source"primary="true"content-types="any"/>
               <p:inputport="alternate"content-types="any"/>
               <p:outputport="result"primary="true"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.

          Document properties

          No document properties are preserved. The comparison document has no base-uri.

          Erratum, April 2024

          The result output port has been made primary. This is consistent with the behavior of all known implementations.

          2.7. p:compress

          The p:compress step serializes the document appearing on its source port and outputs a compressed version of this on its result port.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          formatxs:QName'gzip'
          parametersmap(xs:QName, item()*)?()
          serializationmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

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

          format

          The format of the compression can be specified using the format option. Implementations must support the [GZIP] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0202) if the compression format cannot be understood, determined and/or processed.

          parameters

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

          serialization

          The serialization option is provided to control the serialization of content before compression takes place. 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].

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly and the serialization property which is removed.

          2.8. p:count

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          limitxs:integer0
          Declaration

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

          Document properties

          No document properties are preserved. The count document has no base-uri.

          2.9. p:delete

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the match option matches the document node.
          err:C0062It is a dynamic error if the match option matches a namespace node.
          Declaration

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.10. p:error

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          codexs:QName✔ 
          Declaration

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

          Document properties

          No document properties are preserved but that’s irrelevant as no document is ever produced.

          2.11. p:filter

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ text xml html 
          Option nameTypeRequired
          selectXPathExpression✔ 
          Declaration

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

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI of the selected node(s).

          2.12. p:hash

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault valueRequired
          algorithmxs:QName ✔ 
          valuexs:string ✔ 
          matchXSLTSelectionPattern'/*/node()' 
          parametersmap(xs:QName,item()*)?() 
          versionxs:string?() 
          Errors
          Error codeDescription
          err:C0036It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other algorithms are supported.
          Declaration

          <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 result is a text document.

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.13. p:http-request

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          report  application/json 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          assertxs:string'.?status-code lt 400' 
          authmap(xs:string, item()+)?() 
          headersmap(xs:string, xs:string)?() 
          methodxs:string?'GET' 
          parametersmap(xs:QName, item()*)?() 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0003It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.
          err:C0030It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).
          err:C0078It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.
          err:C0122It is a dynamic error if the given method is not supported.
          err:C0123It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.
          err:C0124It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.
          err:C0125It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.
          err:C0126It is a dynamic error if the XPath expression in assert evaluates to false.
          err:C0127It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.
          err:C0128It is a dynamic error if the URI’s scheme is unknown or not supported.
          err:C0131It is a dynamic error if the processor cannot support the requested encoding.
          err:C0132It is a dynamic error if the override content encoding cannot be supported.
          err:C0133It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.
          err:C0203It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which HTTP methods are supported.
          DefinedThe interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined.
          DefinedOther key value pairs in map “auth” are implementation-defined.
          DefinedIt is implementation-defined which other key/value pairs in the parameters option are supported.
          DefinedThe default behaviour in case of a redirect response is implementation-defined.
          DefinedIt is implementation-defined how a multipart boundary is constructed.
          Declaration

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

          This is the HTTP status code returned for the request.

          base-uri (an xs:anyURI)

          This is the URI of the last request made and is always available in the report even when the request does not return any documents. In the case of HTTP redirection, the base URI returned may be different from the original request URI.

          headers (a map(xs:string, xs:string))

          These are the HTTP headers returned for the request. The map may be empty. Header names are converted to lowercase.

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

          href

          The href option specifies the request’s IRI. Relative values are resolved against the base URI of the element on which the option is specified (the relevant p:with-option or the step element in the case of a syntactic shortcut value).

          Fragment identifiers are removed before making the request. Query parameters are passed through unchanged. It is a dynamic error (err:XC0128) if the URI’s scheme is unknown or not supported. It is the pipeline author’s responsibility to escape problematic UTF-8 characters in the href value, for example with escape-html-uri().

          method

          The method specifies the HTTP request method. The value is implicitly turned into an uppercase string if necessary. It is implementation-defined which HTTP methods are supported. An implementation should implement at least the methods GET, POST, PUT, DELETE, and HEAD (for HTTP and HTTPS). It is a dynamic error (err:XC0122) if the given method is not supported.

          serialization

          The serialization option is used to control the serialization of documents for the request body. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.

          headers

          The key/value pairs in the headers map are used to construct the request headers. Each map key is used as a header name and the value associated with that key in the map is used as the header value.

          If a single document appears on the source port, then document properties on that document may be added as additional headers. For XML, HTML, and text documents with a serialization document property having an encoding key, a charset is appended to the created content-type header of the HTTP request. Properties in the http://www.w3.org/ns/xproc-http namespace will be added to the headers, using the local-name of the property QName as the header name. These properties are only copied if they are not specified in the header map. In other words, if the same header name appears in both places, the value from the map is used and the value from the document properties is ignored. (Header names are case-insensitive, so a case-insensitive comparison must be performed.) If multiple documents appear on the source port, none of their properties are used in the request headers.

          The behavior of the p:http-request depends on the headers specified. In particular:

          content-type

          If a content-type header is provided, it will be used. For a single document request, this overrides the content type value of the document. If the content type specified begins with “multipart/”, a multipart request will be sent to the server.

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

          transfer-encoding

          If a transfer-encoding header is provided, the request must be sent with that encoding. It is a dynamic error (err:XC0131) if the processor cannot support the requested encoding.

          authorization

          The authorization header is used to authenticate a request. If the authoption is specified, any key or property that would have contributed a header named “authorization” (irrespective of case) is ignored. The authorization header is determined exclusively by the auth option when it is present.

          HTTP headers are case-insensitive but keys in maps are not; be careful when specifying the request headers. It is a dynamic error (err:XC0127) if the headers map contains two keys that are the same when compared in a case-insensitive manner. (That is, when fn:uppercase($key1) = fn:uppercase($key2).)

          auth

          Many web services are only available to authenticated users, that is, to users who have “logged in”. The auth option allows the pipeline author to specify information that may be required to generate an “Authorization” header. The standard values support HTTP “Basic” and “Digest” authentication, but other authentication methods are allowed.

          The following standard keys are defined:

          username (xs:string)

          The username.

          password (xs:string)

          The password associated with the username.

          auth-method (xs:string)

          The authentication method. Appropriate values for the “auth-method” key are “Basic” or “Digest” but other values are allowed. If the authentication method is “Basic” or “Digest”, authentication is handled as per [RFC 2617]. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined.

          send-authorization (xs:boolean)

          The “send-authorization” key can be used to attempt to allow the request to avoid an authentication challenge. If the “send-authorization” key is “true()”, and the authentication method specified by the value associated with the “auth-method” key supports generation of an “Authorization” header without a challenge, then the header is generated and sent on the first request. If the “send-authorization” key is absent or does not have the value “true”, the first request is sent without an “Authorization” header.

          Other key value pairs in map “auth” are implementation-defined.It is a dynamic error (err:XC0123) if any key in the “auth” map is associated with a value that is not an instance of the required type.

          If the initial response to the request is an authentication challenge, the values provided in the auth map and any relevant data from the challenge are used to generate an “Authorization” header and the request is sent again. If that authorization fails, the request is not retried.

          It is a dynamic error (err:XC0003) if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported. All implementations must support “Basic” and “Digest” authentication per [RFC 2617].

          parameters

          The parameter option can be used to provide values for fine tuning the construction of the request and/or handling of the server response. A number of parameters are defined in this specification. It is implementation-defined which other key/value pairs in the parameters option are supported.

          override-content-type (xs:string)

          Ordinarily, the value of the content-type header provided in the server response controls the interpretation of any body in the response. If the “override-content-type” parameter is provided, then its value is used to interpret the body. The content-type header that appears on the report port is not changed. 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:XC0030) if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          http-version (xs:string)

          The http-version parameter indicates which version of HTTP must be used for the request.

          accept-multipart (xs:boolean)

          If the accept-multipart parameter is present and explicitly has the value false(), a dynamic error will be raised, if a multipart response is received from the server. This feature is a convenience for pipeline authors as it will raise an error when the multipart request is received, rather than having the presence of a sequence raise an error further along in the pipeline, or simply producing anomalous results. It is a dynamic error (err:XC0125) if the key “accept-multipart” as the value false() and a multipart response is detected.

          override-content-encoding (xs:string)

          If the “override-content-encoding” parameter is present, the response will be treated as if the response contained a “content-encoding” header with the specified value. The content-encoding header that appears on the report port is not changed. It is a dynamic error (err:XC0132) if the override content encoding cannot be supported.

          permit-expired-ssl-certificate (xs:boolean)

          If “permit-expired-ssl-certificate” is true, then the processor should not reject responses where the server provides an expired SSL certificate.

          permit-untrusted-ssl-certificate (xs:boolean)

          If “permit-untrusted-ssl-certificate” is true, then the processor should not reject response where the server provides an SSL certificate which is not trusted, for example, because the certificate authority (CA) is unknown.

          follow-redirect (xs:integer)

          The “follow-redirect” parameter allows the pipeline author to specify the step’s behaviour in the case of a redirect response. A value of 0 indicates that redirects are not to be followed, -1 indicates that redirects are to be followed indefinitely, and a specific number indicates the maximum number of redirects to follow. The default behaviour in case of a redirect response is implementation-defined.

          timeout (xs:integer)

          If a “timeout” is specified, it must be a non-negative integer. It controls the time the XProc processor waits for the request to be answered. If a value is given, it is taken as the number of seconds to wait for the response to be delivered. If no response is received after that time, the request is terminated and a status-code 408 is assumed.

          fail-on-timeout (xs:boolean)

          If “fail-on-timeout” is true, a dynamic error is raised if a 408 response is received (either as a consequence of setting a value for the “timeout” parameter or as status code returned by a server). It is a dynamic error (err:XC0078) if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered. If “fail-on-timeout” is true, it prevents any dynamic error with code C0126 resulting from the assert option to be raised for request's timeout.

          Note

          Please note that the “fail-on-timeout” parameter is different from the “timeout” option on the p:http-request step (see Controlling long running steps in XProc 3.0: An XML Pipeline Language). If the step does not finish in the specified time, D0053 is raised. If the request does not finish in time, and fail-on-timeout is true, C0078 is raised. The actual times after which a timeout is detected may also differ slightly.

          status-only (xs:boolean)

          If the “status-only” parameter is true, this indicates that the pipeline author is only interested in the response code. An empty sequence is always returned on the result port in this case. The implementation may save resources by ignoring the response body. The map on the report will contain the status code and an empty map for “headers”.

          suppress-cookies (xs:boolean)

          If the “suppress-cookies” parameter is true, the implementation must not send any cookies with the request.

          send-body-anyway (xs:boolean)

          If the “send-body-anyway” parameter is true, and one or more documents appear on the source port, a request body is constructed from the documents and sent with the request, even if the semantics of sending a body are not specified for the HTTP method in use.

          It is a dynamic error (err:XC0124) if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          assert (xs:string)

          The assert option can be used by pipeline authors to raise a dynamic error if the response does not fulfill the expectations of the receiver. The option's value (if present) is interpreted as an XPath expression which will be executed using the map that appears on the report port as its context item. If the effective boolean value of the expression is false(), a dynamic error is raised. It is a dynamic error (err:XC0126) if the XPath expression in assert evaluates to false. Implementations should provide an XML representation of the map used as the context item with the error document to enable pipelines to access the error's cause.

          2.13.1. Construction of a multipart request

          If more than one document appears on the source port, or if the specified “content-type” header begins “multipart/”, a multipart request will be constructed, per [RFC 1521]. The content type of the request is derived from the “content-type” header:

          • If the “content-type” header specifies a multipart content type, that value will be used as the content type. If the header includes a boundary parameter, that value will be used as the boundary. It is a dynamic error (err:XC0203) if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          • If the “content-type” header is not specified, “multipart/mixed” will be used.

          • It is a dynamic error (err:XC0133) if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          A multipart request must have a boundary marker, if one isn’t specified in the content type, the implementation must construct one. It is implementation-defined how a multipart boundary is constructed. Implementations are not required to guarantee that the constructed value does not appear accidentally in the multipart data. If it does, the request will be malformed; pipeline authors must provide a boundary if they wish to assure that this cannot happen.

          Each document in the sequence is serialized. If the document has a “serialization” document property, its values are used to determine how serialization is performed.

          All of the document properties in the http://www.w3.org/ns/xproc-http namespace will be added as headers for the part, using the local-name of the property QName as the header name. In particular, this is how the “id”, “description”, “disposition” and other multipart headers can be provided.

          2.13.2. Managing a multipart response

          When a multipart response is received, each part is interpreted according to it’s content type and a pipeline document is constructed. Any additional headers associated with the part are added to the document properties of the constructed document.

          The multipart response is the resulting sequence of documents.

          Document properties

          No document properties are preserved.

          2.14. p:identity

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Declaration

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

          Document properties

          All document properties are preserved.

          2.15. p:insert

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          insertion ✔ xml html text 
          Output portPrimarySequenceContent types
          result✔  xml html text 
          Option nameTypeValuesDefault value
          matchXSLTSelectionPattern '/*'
          positionxs:string('first-child','last-child','before','after') 'after'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace node.
          err:C0024It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.
          err:C0025It is a dynamic error 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”.
          Declaration

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

          • “first-child” - the insertion is made as the first child of the match;

          • “last-child” - the insertion is made as the last child of the match;

          • “before” - the insertion is made as the immediate preceding sibling of the match;

          • “after” - the insertion is made as the immediate following sibling of the match.

          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.

          Document properties

          All document properties on the source port are preserved. The document properties on the insertion port are not preserved or present in the result document.

          2.16. p:json-join

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeDefault value
          flatten-to-depthxs:string?'0'
          Errors
          Error codeDescription
          err:C0111 It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.
          err:C0119It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

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

          • If the document under inspection is a JSON document representing an array, the array is copied to the resulting array according to the setting of option flatten-to-depth.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents, their XDM representation is appended to the resulting array.

          • It is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, an entry is created as described above. It is a dynamic error (err:XC0111) if a document of an unsupported document type appears on port source of p:json-join.

          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.

          Document properties

          No document properties are preserved. The joined document has no base-uri.

          2.17. p:json-merge

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeValuesDefault value
          duplicatesxs:string('reject', 'use-first', 'use-last', 'use-any', 'combine') 'use-first'
          keyXPathExpression 'concat("_",$p:index)'
          Errors
          Error codeDescription
          err:C0106It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.
          err:C0107 It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.
          err:C0110It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

          <p:declare-steptype="p:json-merge">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"content-types="application/json"/>
               <p:optionname="duplicates"values="('reject', 'use-first', 'use-last', 'use-any', 'combine')"select="'use-first'"/><!-- string -->
               <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:

          • If the document under inspection is a JSON document representing a map, all key-value pairs are copied into the result map unless this map already contains an entry with the given key. In this case the value of option duplicates determines the policy for handling duplicate keys as specified for function map:merge in [XPath and XQuery Functions and Operators 3.1]. It is a dynamic error (err:XC0106) if duplicate keys are encountered and option duplicates has value “reject”.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents a new key-value pair is created and put into the resulting map. The key is created by evaluating the XPath expression in option key with the inspected document as context item. If the evaluation result is a single atomic value, it is taken as key. If the evaluation result is a node, its string value is taken as key. It is a dynamic error (err:XC0110) if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function. Duplicate keys are handled as described above. The XDM representation of the inspected document is taken as value of the key-value pair.

          • It is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, the key-value pair is created as described above. It is a dynamic error (err:XC0107) if a document of a not supported document type appears on port source of p:json-merge.

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

          Document properties

          No document properties are preserved. The merged document has no base-uri.

          2.18. p:label-elements

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          attributexs:QName'xml:id'
          labelXPathExpression'concat("_",$p:index)'
          matchXSLTSelectionPattern'*'
          replacexs:booleantrue()
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that expression matches anything other than element nodes.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.19. p:load

          The p:load step has no inputs but produces as its result a document specified by an IRI.

          Summary

          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          content-typexs:string?() 
          document-propertiesmap(xs:QName, item()*)?() 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:D0011It is a dynamic error if the resource referenced by a p:load element does not exist or cannot be accessed.
          err:D0023It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.
          err:D0043It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.
          err:D0049It is a dynamic error if the loaded content is not a well-formed XML document.
          err:D0057It is a dynamic error if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the content-type specifies an encoding, which is not supported by the processor.
          err:D0062It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0078It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIn the absence of an explicit type, the content type is implementation-defined
          DefinedAdditional XML parameters are implementation-defined.
          DefinedText parameters are implementation-defined.
          DefinedAdditional JSON parameters are implementation-defined.
          DefinedThe precise way in which HTML documents are parsed into the XPath data model is implementation-defined.
          DefinedHTML parameters are implementation-defined.
          DefinedHow a processor interprets other media types is implementation-defined.
          DefinedParameters for other media types are implementation-defined.
          Declaration

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

          1. If a content-type property is specified in document-properties or content-type is present, then the document must be interpreted according to that content type. 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:XD0062) if the content-type is specified and the document-properties has a “content-type” that is not the same.

          2. If the document is retrieved with a URI protocol that specifies a content type (for example, http:), then the document must be interpreted according to that content type.

          3. In the absence of an explicit type, the content type is implementation-defined.

          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.

          2.19.1. Loading XML data

          For an XML media type, the content is loaded and parsed as XML.

          It is a dynamic error (err:XD0049) if the loaded content is not a well-formed XML document.

          If the dtd-validate parameter is true, then DTD validation must be performed when parsing the document. It is a dynamic error (err:XD0023) if a DTD validation is performed and either the document is not valid or no DTD is found. It is a dynamic error (err:XD0043) if the dtd-validate parameter is true and the processor does not support DTD validation.

          Additional XML parameters are implementation-defined.

          2.19.2. Loading text data

          For a text media type, the content is loaded as a text document. (A text document is an XPath data model document consisting of a single text node.)

          It is a dynamic error (err:XD0060) if the content-type specifies an encoding, which is not supported by the processor.

          Text parameters are implementation-defined.

          2.19.3. Loading JSON data

          For a JSON media type, the content is loaded and parsed as JSON.

          The parameters specified for the fn:parse-json function in [XPath and XQuery Functions and Operators 3.1] must be supported. Additional JSON parameters are implementation-defined.

          It is a dynamic error (err:XD0057) if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          It is a dynamic error (err:XD0058) if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.

          It is a dynamic error (err:XD0059) if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          2.19.4. Loading HTML data

          For an HTML media type, the content is loaded and parsed into an XPath data model document that contains a tree of elements, attributes, and other nodes.

          The precise way in which HTML documents are parsed into the XPath data model is implementation-defined.

          It is a dynamic error (err:XD0078) if the loaded document cannot be represented as an HTML document in the XPath data model.

          HTML parameters are implementation-defined.

          2.19.5. Loading binary data

          An XProc processor may load other, arbitrary data types. How a processor interprets other media types is implementation-defined.

          Parameters for other media types are implementation-defined.

          Document properties

          The properties specified in document-properties are applied. If the properties do not specify a base-uri, the base-uri property will reflect the base URI of the loaded document.

          2.20. p:make-absolute-uris

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          base-urixs:anyURI?() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than element or attribute nodes.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DependentIf 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.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.21. p:namespace-delete

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeRequired
          prefixesxs:string✔ 
          Errors
          Error codeDescription
          err:C0108It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.
          err:C0109It is a dynamic error if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.22. p:namespace-rename

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeValuesDefault value
          apply-toxs:string('all','elements','attributes') 'all'
          fromxs:anyURI? ()
          toxs:anyURI? ()
          Errors
          Error codeDescription
          err:C0014It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.
          err:C0092It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.
          Declaration

          <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"select="'all'"values="('all','elements','attributes')"/><!-- string -->
          </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:

          • Namespace bindings: If the from option is present and its value is not the empty string, then every binding of a prefix (or the default namespace) in the input document whose value is the same as the value of the from option is

            • replaced in the output with a binding to the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) absent from the output.

            If the from option is absent, or its value is the empty string, then no bindings are changed or removed.

          • Elements and attributes: If the from option is present and its value is not the empty string, for every element and attribute, as appropriate, in the input whose namespace name is the same as the value of the from option, in the output its namespace name is

            • replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) changed to have no value.

            If the from option is absent, or its value is the empty string, then for every element and attribute, as appropriate, whose namespace name has no value, in the output its namespace name is set to the value of the to option.

            It is a dynamic error (err:XC0092) if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          • Namespace attributes: If the from option is present and its value is not the empty string, for every namespace attribute in the input whose value is the same as the value of the from option, in the output

            • the namespace attribute's value is replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) the namespace attribute is absent.

          Note

          The apply-to option is primarily intended to make it possible to avoid renaming attributes when the from option specifies no namespace, since many attributes are in no namespace.

          Care should be taken when specifying no namespace with the to option. Prefixed names in content, for example QNames and XPath expressions, may end up with no appropriate namespace binding.

          Document properties

          All document properties are preserved.

          2.23. p:pack

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          alternate ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeRequired
          wrapperxs:QName✔ 
          Declaration

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

          Note

          In the common case, where the document element of a document in the result sequence has two element children, any comments, processing instructions, or white space text nodes that occur between them may have come from either of the input documents; this step does not attempt to distinguish which one.

          Document properties

          No document properties are preserved. The result documents do not have a base-uri property.

          2.24. p:rename

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          new-namexs:QName ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0013It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.
          err:C0023It is a dynamic error if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.
          Declaration

          <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, or if it matches more than one attribute on a single element.

          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.

          Document properties

          All document properties are preserved.

          2.25. p:replace

          The p:replace step replaces matching nodes in its primary input with the top-level node(s) of the replacement port's document.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          replacement  text xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace nodes.
          Declaration

          <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, the result is a text document.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.26. p:set-attributes

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attributesmap(xs:QName, xs:anyAtomicType) ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than element nodes.
          err:C0059It is a dynamic error if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

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

          This step cannot be used to add namespace declarations. It is a dynamic error (err:XC0059) if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/. However, 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.

          Document properties

          All document properties are preserved.

          2.27. p:set-properties

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          propertiesmap(xs:QName,item()*) ✔ 
          mergexs:booleantrue() 
          Errors
          Error codeDescription
          err:C0069It is a dynamic error if the properties map contains a key equal to the string “content-type”.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0070It is a dynamic error 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 .
          Declaration

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

          Document properties

          If merge is true, document properties not overridden by settings in the properties map are preserved, otherwise the resulting document has only the content-type property and the properties specified in the properties map. In particular, if merge is false, the base-uri property will not be preserved. This means that the resulting document will not have a base URI if the properties map does not contain a base-uri entry.

          2.28. p:sink

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Declaration

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

          Document properties

          Not applicable.

          2.29. p:sleep

          The p:sleep step introduces a delay.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          durationxs:nonNegativeInteger✔ 
          Declaration

          <p:declare-steptype="p:sleep">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"sequence="true"content-types="any"/>
               <p:optionname="duration"as="xs:nonNegativeInteger"required="true"/>
          </p:declare-step>

          The p:sleep step copies each of the documents on the source port to the result port without changing them. Before copying the documents, it pauses for a period of time not less than duration milliseconds.

          Note

          In multi-threaded implementations, there is no guarantee that this will pause the execution of more than one thread. However, any steps that depend on the output of this step will wait for this step to complete.

          Document properties

          All document properties are preserved.

          2.30. p:split-sequence

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          matched✔ ✔ any 
          not-matched ✔ any 
          Option nameTypeDefault valueRequired
          testXPathExpression ✔ 
          initial-onlyxs:booleanfalse() 
          Errors
          Error codeDescription
          err:C0150It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.
          Declaration

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

          Note

          In principle, this component cannot stream because it must buffer all of the input sequence in order to find the context size. In practice, if the test expression does not use the last() function, the implementation can stream and ignore the context size.

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

          Document properties

          All document properties are preserved.

          2.31. p:store

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          result-uri  application/xml 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0050It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.32. p:string-replace

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          replaceXPathExpression✔ 
          Declaration

          <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 result is a text document.

          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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.33. p:text-count

          The p:text-count step counts the number of lines in a text document and returns a single XML document containing that number.

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Declaration

          <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 (&#10;), that newline is ignored. (It is not a separator between that line and a following line that contains no characters.)

          Document properties

          No document properties are preserved. The count document does not have a base-uri property.

          2.34. p:text-head

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

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

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

          • If the count option is positive, the p:text-head step returns the first count lines

          • If the count option is zero, the p:text-head step returns all lines

          • If the count option is negative, the p:text-head step returns all lines except the first count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.35. p:text-join

          The p:text-join step concatenates text documents.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault value
          override-content-typexs:string?()
          prefixxs:string?()
          separatorxs:string?()
          suffixxs:string?()
          Errors
          Error codeDescription
          err:C0001It is a dynamic error if the value of option override-content-type is not a text media type.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Declaration

          <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 separator option is specified, its value will be inserted in between adjacent documents.

          • When the prefix option is specified, the document appearing on the result port will always start with its value (also when there are no documents on the source port).

          • When the suffix option is specified, the document appearing on the result port will always end with its value (also when there are no documents on the source port).

          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.

          Document properties

          No document properties are preserved. The joined document has no base-uri property.

          2.36. p:text-replace

          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.

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault valueRequired
          patternxs:string ✔ 
          replacementxs:string ✔ 
          flagsxs:string?() 
          Errors
          Error codeDescription
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.37. p:text-sort

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

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeValuesDefault value
          case-orderxs:string?('upper-first', 'lower-first') ()
          collationxs:string 'http://www.w3.org/2005/xpath-functions/collation/codepoint'
          langxs:language? ()
          orderxs:string('ascending', 'descending') 'ascending'
          sort-keyXPathExpression '.'
          stablexs:boolean true()
          Errors
          Error codeDescription
          err:C0098It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.
          err:C0099It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.
          Implementation details
          ImplementationDescription
          DefinedSupport for other collations is implementation-defined.
          Declaration

          <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')"/><!-- string -->
               <p:optionname="case-order"as="xs:string?"values="('upper-first', 'lower-first')"/><!-- string -->
               <p:optionname="lang"as="xs:language?"/>                     
               <p:optionname="collation"as="xs:string"select="'http://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.

          • The sort-key is used to obtain a sort key for each of the lines in the document appearing on source. The context item is the line as an instance of xs:string, the context position is the number of the line in the document on port source, the context size is the number of lines in this document. It is a dynamic error (err:XC0098) if a dynamic XPath error occurred while applying sort-key to a line. It is a dynamic error (err:XC0099) if the result of applying sort-key to a given line results in a sequence with more than one item.

          • The order option defines whether the lines are processed in ascending or descending order. Its value must be one of ascending or descending. The default is ascending.

          • The case-order option defines whether upper-case letters are to be collated before or after lower-case letters. Its value must be one of upper-first or lower-first. The default is language-dependent.

          • The lang option defines the language whose collating conventions are to be used. The xs:language data type represents natural language identifiers as defined by [BCP 47] (currently represented by [RFC 4646] and [RFC 4647] or its successor(s).) The default depends on the processing environment. Its value must be a valid language code (e.g. en-EN).

          • The collation option identifies how strings are to be compared with each other. Its value must be a valid collation URI. The only collation XProc processors must support is the Unicode Codepoint Collation http://www.w3.org/2005/xpath-functions/collation/codepoint. This is also its default. Support for other collations is implementation-defined.

          • If the stable option is set to false this indicates that there is no requirement to retain the original order of items that have equal values for all the sort keys.

          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 (&#10;), 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 (&#10;).

          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.

          Document properties

          All document properties are preserved.

          Erratum, April 2024

          The URI for the Unicode Codepoint Collation has been corrected to an http: URI rather than an https: one. The URI is an identifier and the correct identifier uses an http: URI. Implementations are encouraged to recognized collation URIs that begin with “https://www.w3.org/” and treat them as if they began “http://www.w3.org/”, with a warning, if practical.

          2.38. p:text-tail

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

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

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

          • If the count option is positive, the p:text-tail step returns the last count lines

          • If the count option is zero, the p:text-tail step returns all lines

          • If the count option is negative, the p:text-tail step returns all lines except the last count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.39. p:unarchive

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          exclude-filterRegularExpression()
          formatxs:QName?()
          include-filterRegularExpression()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0085It is a dynamic error if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0147It is a dynamic error if a specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the option is not a valid URI according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

          <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 format of the archive is determined as follows:

            • If the format option is specified, this determines the format of the archive. Implementations must support the [ZIP] format, specified with the value zip. It is implementation-defined what other formats are supported.

            • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [ZIP] format.

            • 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 unarchiving. 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.

          • If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions 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 a specified value is not a valid XPath regular expression.

            If neither the include-filter option nor the exclude-filter option is specified, the p:unarchive step outputs on its result port all entries in the archive.

            If the include-filter option or the exclude-filter option is specified, the p:archive step outputs on the result port the entries from the archive that conform to the following rules:

            • If any include-filter pattern matches an archive entry's name, the entry is included in the output.

            • If any exclude-filter pattern matches an archive 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.

            • Names of entries in archives are always relative names. For instance, the name of a file called xyz.xml in a specs subdirectory in an archive is called in full specs/xyz.xml (and not /specs/xyz.xml).

            As a result: an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.

            The regular expressions specified in the include-filter and exclude-filter options will be matched against the path of the entry in the archive. The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • The relative-to option, when present, is used in creating the base URI of the unarchived documents. 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).

          • The override-content-types option can be used to partially override the content-type determination mechanism, as described in Section 2.4.1, “Overriding content types”.

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

          • If the relative-to option is present: Function p:urify() is called with the value of this option as second parameter ($basedir) and with the relative path of this document as it was in the archive as first parameter

          • If the relative-to option is not present: Function p:urify()is called with the value of the base URI of the archive appended with a “/” as second parameter ($baseDir) and the relative path of this document as it was in the archive as first parameter

          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:

          • With the relative-to option set to file:///x/y/z: file:///x/y/z/specs/xyz.xml

          • Without a relative-to option set: file:///a/b/c.zip/specs/xyz.xml

          Document properties

          No document properties are preserved. The base-uri property of each unarchived document is reflective of the base URI of the document.

          2.40. p:uncompress

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          content-typexs:string'application/octet-stream'
          formatxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0201It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the compression format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

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

          • If the format option is specified, this determines the compression format. Implementations must support the [GZIP] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error (err:XC0202) if the compression format cannot be understood, determined and/or processed.

          • If no format option is specified or its value is the empty sequence, the compression format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the compression format. Implementations should recognize archives in [GZIP] format.

          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:

          1. If the content-type option is specified, the uncompressed document must be interpreted according to that content-type. 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:XC0201) if the p:uncompress step cannot perform the requested content-type cast.

          2. In the absence of an explicit type, the content will be interpreted as content type application/octet-stream.

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly.

          2.41. p:unwrap

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than the document node or element nodes.
          Declaration

          <p:declare-steptype="p:unwrap">
               <p:inputport="source"content-types="xml html"/>
               <p:outputport="result"content-types="text xml html"/>
               <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.

          Note

          The matching applies to the entire document, not just the “top-most” matches. A pattern of the form h:div will replace allh:div elements, not just the top-most ones.

          This step produces a single document. Special cases:

          • If the document element is unwrapped, the result might not be well-formed XML.

            For instance unwrapping the root element of <!-- COMMENT --><root-element/> will result in a document node with a single comment node child, which is not well-formed.

          • If a document consisting of only an empty root element is unwrapped, the result will be a document node without children. The result document’s content type will not change.

          • If a document consisting of a root element containing only text is unwrapped, the result will be a document node with a single text node child. The result document’s content type will become “text/plain”.

          As specified in the core language specification: if the content type changes, the serialization document property, if present, will be removed.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.42. p:uuid

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          parametersmap(xs:QName, item()*)?()
          versionxs:integer?()
          Errors
          Error codeDescription
          err:C0060It is a dynamic error if the processor does not support the specified version of the UUID algorithm.
          Implementation details
          ImplementationDescription
          DefinedIf the version is not specified, the version of UUID computed is implementation-defined.
          DefinedSupport for other versions of UUID is implementation-defined.
          DefinedThe names and values of parameters to p:uuid are implementation-defined.
          Declaration

          <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:optionname="parameters"as="map(xs:QName, item()*)?"/>    
          </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 is implementation-defined. Some UUID schemes require additional parameters which may be provided in the parameters option. The names and values of parameters to p:uuid are 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 result is a text document.

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.43. p:wrap-sequence

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeDefault valueRequired
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Declaration

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

          Document properties

          No document properties are preserved. The document produced has no base-uri property.

          2.44. p:wrap

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than document, element, text, processing instruction, and comment nodes.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.45. p:www-form-urldecode

          The p:www-form-urldecode step decodes a x-www-form-urlencoded string into a JSON representation.

          Summary

          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeRequired
          valuexs:string✔ 
          Errors
          Error codeDescription
          err:C0037It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.
          Declaration

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

          Document properties

          The resulting JSON document has no properties apart from content-type. In particular, it has no base-uri.

          2.46. p:www-form-urlencode

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

          Summary

          Output portPrimarySequenceContent types
          result✔  text/plain 
          Option nameTypeRequired
          parametersmap(xs:string,xs:anyAtomicType+)✔ 
          Declaration

          <p:declare-steptype="p:www-form-urlencode">
               <p:outputport="result"content-types="text/plain"/>
               <p:optionname="parameters"required="true"as="map(xs:string,xs:anyAtomicType+)"/>
          </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.

          Document properties

          The resulting text document has no properties apart from content-type. In particular, it has no base-uri.

          2.47. p:xinclude

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          fixup-xml-basexs:booleanfalse()
          fixup-xml-langxs:booleanfalse()
          Errors
          Error codeDescription
          err:C0029It is a dynamic error if an XInclude error occurs during processing.
          Declaration

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

          Document properties

          All document properties are preserved.

          2.48. p:xquery

          The p:xquery step applies an XQuery query to the sequence of documents provided on the source port.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          query  text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          parametersmap(xs:QName,item()*)?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0009It is a dynamic error if the specified XQuery version is not available.
          err:C0101It is a dynamic error 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.
          err:C0102It is a dynamic error 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.
          err:C0103It is a dynamic error if any error occurs during XQuery’s static analysis phase.
          err:C0104It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.
          Implementation details
          ImplementationDescription
          DefinedSupport for XQueryX is implementation-defined.
          DefinedIt is implementation-defined which XQuery version(s) is/are supported.
          DefinedThe point in time returned as the current dateTime is implementation-defined.
          DefinedThe implicit timezone is implementation-defined.
          DependentThe set of available documents (those that may be retrieved with a URI) is implementation-dependent.
          DependentThe set of available collections is implementation-dependent.
          Declaration

          <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 document root element is c:query, the text descendants of this element are considered the query.

            <c:query>
                string
            </c:query>

          • If the document root element is in the XQueryX namespace, the document is treated as an XQueryX-encoded query. Support for XQueryX is implementation-defined.

          • Otherwise the serialization of the document must be treated as the query. The document's serialization property (if present) is used.

          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:

          Statically known default collection type

          document()*

          Statically known namespaces:

          Unchanged from the implementation defaults. No namespace declarations in the XProc pipeline are automatically exposed in the static context.

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

          Context item

          The first document that appears on the source port.

          Context position

          1

          Context size

          1

          Variable values

          Any parameters passed in the parameters option augment any implementation-defined variable bindings known to the XQuery processor.

          Function implementations

          The function implementations provided by the XQuery processor.

          Current dateTime

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

          Implicit timezone

          The implicit timezone is implementation-defined.

          Available documents

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

          Available collections

          The set of available collections is implementation-dependent.

          Default collection

          The sequence of documents provided on the source port.

          2.48.1. Example

          The following pipeline applies XInclude processing and schema validation before using XQuery:

          Example 1. A Sample Pipeline Document
          <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>

          Where countp.xq might contain:

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

          2.48.2. Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the query. If the query does not establish a base URI, the document will not have one.

          2.49. p:xslt

          The p:xslt step invokes an XSLT stylesheet.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          stylesheet  xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          secondary ✔ any 
          Option nameTypeDefault value
          global-context-itemitem()?()
          initial-modexs:QName?()
          output-base-urixs:anyURI?()
          parametersmap(xs:QName,item()*)?()
          populate-default-collectionxs:boolean?true()
          static-parametersmap(xs:QName,item()*)?()
          template-namexs:QName?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0007It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.
          err:C0008It is a dynamic error if the stylesheet does not support a given mode.
          err:C0038It is a dynamic error if the specified xslt version is not available.
          err:C0039It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.
          err:C0056It is a dynamic error if the stylesheet does not provide a given template.
          err:C0093 It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.
          err:C0094It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.
          err:C0095It is a dynamic error if an error occurred during the transformation.
          err:C0096It is a dynamic error if the transformation is terminated by XSLT message termination.
          err:C0105It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.
          err:C0121It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which XSLT version(s) is/are supported.
          DefinedWhether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher).
          DependentHow XSLT message termination errors are reported to the XProc processor is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          Declaration

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

          2.49.1. Invoking an XSLT 3.0 stylesheet

          The value of global-context-item is used as global context item for the stylesheet invocation. If no value is supplied, the following applies:

          • If there is a single document on the source port, this document will become the value of the global-context-item option.

          • If there are none or multiple documents on the source port, the global context item is absent.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          If no value is supplied for template-name option an “Apply-template invocation” is performed. The documents that appear on source are taken to be the initial match selection. if populate-default-collection is true, they are also the default collection. If a value is supplied for the initial-mode option, this value is used as the initial-mode for the invocation. It is a dynamic error (err:XC0008) if the stylesheet does not support a given mode. If no value is supplied, nothing is supplied to the invocation, so the default behaviour defined for XSLT 3.0 could be applied.

          If a value is supplied for option template-name a “Call template invocation” is performed. The documents on port source are taken as the default collection in this case. Option initial-mode is ignored. It is a dynamic error (err:XC0056) if the stylesheet does not provide a given template.

          Independent of the way the stylesheet is invoked, the principal result(s) will appear on output port result while secondary result(s) will appear on output port secondary. The order in which result documents appear on the secondary port is implementation-dependent. Whether the raw results are delivered or a result tree is constructed, depends on the (explicit or implicit) setting for attribute build-tree of in the output-definition for the respective result. If a result tree is constructed, the result will be a text document if it is a single text node wrapped into a document node. Otherwise it will be either an XML document or an HTML document depending on the attribute method on the output-definition for the respective result. If no result tree is constructed, the stylesheet invocation may additionally deliver a sequence of atomic values, maps, or arrays. For each item in this sequence a JSON document will be constructed and appear on the steps output port.

          Option output-base-uri sets the base output URI per XSLT 3.0 specification. If a final result tree is constructed, this URI is used to resolve a relative URI reference. If no value is supplied for output-base-uri, the base URI of the first document in the source port's sequence is used. If no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error (err:XC0121) if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [RFC 3986].

          Note

          If no result tree is constructed for one of secondary results, a sequence of documents sharing the same value for attribute href may appear on output port result.

          2.49.2. Invoking an XSLT 2.0 stylesheet

          If a sequence of documents is provided on the source port, the first document is used as the initial context node. The whole sequence is also the default collection. If no documents are provided on the source port, the initial context node is undefined and the default collection is empty. It is a dynamic error (err:XC0094) if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          The value of option global-context-item is ignored if a stylesheet is invoked as per XSLT 2.0. 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:XC0007) if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function. It is a dynamic error (err:XC0008) if the specified initial mode cannot be applied to the specified stylesheet. It is a dynamic error (err:XC0056) if the specified template name cannot be applied to the specified stylesheet.

          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.

          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 no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error (err:XC0121) if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [RFC 3986].

          2.49.3. Invoking an XSLT 1.0 stylesheet

          The document provided for source is used the transformations source tree. It is a dynamic error (err:XC0039) if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used. The values supplied for options global-context-item, initial-mode, and template-name are ignored. If XSLT 1.0 is used, an empty sequence of documents must appear on the secondary port. 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.

          The key/value pairs supplied in parameters are used to set top-level parameters in the stylesheet. If the value is an atomic value or a node, its string value is supplied to the stylesheet. It is a dynamic error (err:XC0105) if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the tranformation. If the transformation does not establish a base URI, the document will not have one.

          3. Step Errors

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

          A [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space).

          If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

          Dynamic errors raised by steps are divided into two categories: dynamic errors and step errors. The distinction is largely that “step errors” tend to be related to a particular step or small group of steps (e.g., validation error) whereas the “dynamic errors” apply to many more steps (e.g., URI not available). There is also precedent for some of the error codes dating back to XProc 1.0.

          Dynamic Errors
          err:XD0011

          It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          See: Handling of ZIP archives, p:load

          err:XD0023

          It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.

          See: Loading XML data

          err:XD0043

          It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.

          See: Loading XML data

          err:XD0049

          It is a dynamic error if the text value is not a well-formed XML document

          See: Casting from a text media type, Loading XML data

          err:XD0057

          It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          See: Casting from a text media type, Loading JSON data

          err:XD0058

          It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.

          See: Casting from a text media type, Loading JSON data

          err:XD0059

          It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          See: Casting from a text media type, Loading JSON data

          err:XD0060

          It is a dynamic error if the text document can not be converted into the XPath data model

          See: Casting from a text media type, Loading text data

          err:XD0062

          It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.

          See: p:load

          err:XD0064

          It is a dynamic error if the base URI is not both absolute and valid according to .

          See: p:archive, p:archive-manifest, p:load, p:make-absolute-uris, p:set-properties, p:unarchive

          err:XD0070

          It is a dynamic error 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 .

          See: p:set-properties

          err:XD0078

          It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.

          See: Loading HTML data

          err:XD0079

          It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.

          See: Overriding content types, p:cast-content-type, p:http-request, p:http-request, p:load, p:text-join, p:uncompress

          Step Errors
          err:XC0001

          It is a dynamic error if the value of option override-content-type is not a text media type.

          See: p:text-join

          err:XC0003

          It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.

          See: p:http-request

          err:XC0007

          It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0008

          It is a dynamic error if the stylesheet does not support a given mode.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0009

          It is a dynamic error if the specified XQuery version is not available.

          See: p:xquery

          err:XC0013

          It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.

          See: p:rename

          err:XC0014

          It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.

          See: p:namespace-rename

          err:XC0019

          It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.

          See: p:compare

          err:XC0023

          It is a dynamic error if the selection pattern matches a node which is not an element.

          See: p:add-attribute, p:delete, p:insert, p:label-elements, p:make-absolute-uris, p:rename, p:replace, p:set-attributes, p:unwrap, p:wrap

          err:XC0024

          It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.

          See: p:insert

          err:XC0025

          It is a dynamic error 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”.

          See: p:insert

          err:XC0029

          It is a dynamic error if an XInclude error occurs during processing.

          See: p:xinclude

          err:XC0030

          It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          See: p:http-request

          err:XC0036

          It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.

          See: p:hash

          err:XC0037

          It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.

          See: p:www-form-urldecode

          err:XC0038

          It is a dynamic error if the specified xslt version is not available.

          See: p:xslt

          err:XC0039

          It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0050

          It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.

          See: p:store

          err:XC0056

          It is a dynamic error if the stylesheet does not provide a given template.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0058

          It is a dynamic error if the all and relative options are both true.

          See: p:add-xml-base

          err:XC0059

          It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.

          See: p:add-attribute, p:set-attributes

          err:XC0060

          It is a dynamic error if the processor does not support the specified version of the UUID algorithm.

          See: p:uuid

          err:XC0062

          It is a dynamic error if the match option matches a namespace node.

          See: p:delete

          err:XC0069

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

          See: p:set-properties

          err:XC0071

          It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.

          See: p:cast-content-type

          err:XC0072

          It is a dynamic error if the c:data contains content is not a valid base64 string.

          See: Casting from an XML media type

          err:XC0073

          It is a dynamic error if the c:data element does not have a content-type attribute.

          See: Casting from an XML media type

          err:XC0074

          It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.

          See: Casting from an XML media type

          err:XC0076

          It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.

          See: p:compare

          err:XC0077

          It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.

          See: p:compare

          err:XC0078

          It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.

          See: p:http-request

          err:XC0079

          It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          See: p:archive, p:archive-manifest, p:cast-content-type, p:compress, p:unarchive, p:uncompress

          err:XC0080

          It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          See: Handling of ZIP archives

          err:XC0081

          It is a dynamic error if the format of the archive does not match the format as specified in the format option.

          See: p:archive, p:archive-manifest

          err:XC0084

          It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          See: p:archive

          err:XC0085

          It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.

          See: p:archive, p:archive-manifest, p:unarchive

          err:XC0092

          It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          See: p:namespace-rename

          err:XC0093

          It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.

          See: p:xslt

          err:XC0094

          It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0095

          It is a dynamic error if an error occurred during the transformation.

          See: p:xslt

          err:XC0096

          It is a dynamic error if the transformation is terminated by XSLT message termination.

          See: p:xslt

          err:XC0098

          It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.

          See: p:text-sort

          err:XC0099

          It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.

          See: p:text-sort

          err:XC0100

          It is a dynamic error if the document on port manifest does not conform to the given schema.

          See: p:archive, The archive manifest

          err:XC0101

          It is a dynamic error 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.

          See: p:xquery

          err:XC0102

          It is a dynamic error 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.

          See: p:xquery

          err:XC0103

          It is a dynamic error if any error occurs during XQuery’s static analysis phase.

          See: p:xquery

          err:XC0104

          It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.

          See: p:xquery

          err:XC0105

          It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0106

          It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.

          See: p:json-merge

          err:XC0107

          It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.

          See: p:json-merge

          err:XC0108

          It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.

          See: p:namespace-delete

          err:XC0109

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

          See: p:namespace-delete

          err:XC0110

          It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.

          See: p:json-merge

          err:XC0111

          It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.

          See: p:json-join

          err:XC0112

          It is a dynamic error if more than one document appears on the port manifest.

          See: p:archive

          err:XC0119

          It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.

          See: p:json-join

          err:XC0120

          It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.

          See: p:archive-manifest, p:unarchive

          err:XC0121

          It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0122

          It is a dynamic error if the given method is not supported.

          See: p:http-request

          err:XC0123

          It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0124

          It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0125

          It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.

          See: p:http-request

          err:XC0126

          It is a dynamic error if the XPath expression in assert evaluates to false.

          See: p:http-request

          err:XC0127

          It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.

          See: p:http-request

          err:XC0128

          It is a dynamic error if the URI’s scheme is unknown or not supported.

          See: p:http-request

          err:XC0131

          It is a dynamic error if the processor cannot support the requested encoding.

          See: p:http-request

          err:XC0132

          It is a dynamic error if the override content encoding cannot be supported.

          See: p:http-request

          err:XC0133

          It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          See: Construction of a multipart request

          err:XC0146

          It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          See: Overriding content types

          err:XC0147

          It is a dynamic error if the specified value is not a valid XPath regular expression.

          See: Overriding content types, p:text-replace, p:unarchive

          err:XC0150

          It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.

          See: p:split-sequence

          err:XC0201

          It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.

          See: p:uncompress

          err:XC0202

          It is a dynamic error if the compression format cannot be understood, determined and/or processed.

          See: p:compress, p:uncompress

          err:XC0203

          It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          See: Construction of a multipart request

          A. Conformance

          Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

          [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

          [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

          A.1. Implementation-defined features

          The following features are implementation-defined:

          1. The list of formats supported by the p:archive step is implementation-defined. See Section 2.3, “p:archive”.
          2. The list of archive formats that can be modified by p:archive is implementation-defined. See Section 2.3, “p:archive”.
          3. The semantics of any additional attributes, elements and their values are implementation-defined. See Section 2.3, “p:archive”.
          4. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          5. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          6. It is implementation-defined how the step determines the archive's format. See Section 2.3, “p:archive”.
          7. The c:archive root element may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          8. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          9. It is implementation-defined what other compression methods are supported. See Section 2.3.1, “The archive manifest”.
          10. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          11. It is implementation-defined what compression levels are supported. See Section 2.3.1, “The archive manifest”.
          12. The c:entry elements may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          13. The p:archive step may support additional, implementation-defined commands for ZIP files. See Section 2.3.2, “Handling of ZIP archives”.
          14. The actual parameter names supported by p:archive for a particular format are implementation-defined. See Section 2.3.2, “Handling of ZIP archives”.
          15. It is implementation-defined what other formats are supported. See Section 2.4, “p:archive-manifest”.
          16. It is implementation-defined how the step determines the archive's format. See Section 2.4, “p:archive-manifest”.
          17. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.4, “p:archive-manifest”.
          18. Additional information provided for entries in p:archive-manifest is implementation-defined. See Section 2.4, “p:archive-manifest”.
          19. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.5, “p:cast-content-type”.
          20. The precise nature of the conversion from XML to JSON is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          21. Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          22. Casting from an HTML media type to a JSON media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          23. Casting from an HTML media type to any other media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          24. It is implementation-defined whether other result formats are supported. See Section 2.5.3, “Casting from a JSON media type”.
          25. Casting from a JSON media type to an HTML media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          26. Casting from a JSON media type to any other media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          27. The precise way in which text documents are parsed into the XPath data model is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          28. Casting from a text media type to any other media type is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          29. Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          30. Casting from any other media type to any other media type is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          31. Implementations of p:compare must support the deep-equal method; other supported methods are implementation-defined. See Section 2.6, “p:compare”.
          32. 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. See Section 2.6, “p:compare”.
          33. It is implementation-defined what other formats are supported. See Section 2.7, “p:compress”.
          34. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.7, “p:compress”.
          35. It is implementation-defined what other algorithms are supported. See Section 2.12, “p:hash”.
          36. It is implementation-defined which HTTP methods are supported. See Section 2.13, “p:http-request”.
          37. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined. See Section 2.13, “p:http-request”.
          38. Other key value pairs in map “auth” are implementation-defined. See Section 2.13, “p:http-request”.
          39. It is implementation-defined which other key/value pairs in the parameters option are supported. See Section 2.13, “p:http-request”.
          40. The default behaviour in case of a redirect response is implementation-defined. See Section 2.13, “p:http-request”.
          41. It is implementation-defined how a multipart boundary is constructed. See Section 2.13.1, “Construction of a multipart request”.
          42. It is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.16, “p:json-join”.
          43. It is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.17, “p:json-merge”.
          44. In the absence of an explicit type, the content type is implementation-defined See Section 2.19, “p:load”.
          45. Additional XML parameters are implementation-defined. See Section 2.19.1, “Loading XML data”.
          46. Text parameters are implementation-defined. See Section 2.19.2, “Loading text data”.
          47. Additional JSON parameters are implementation-defined. See Section 2.19.3, “Loading JSON data”.
          48. The precise way in which HTML documents are parsed into the XPath data model is implementation-defined. See Section 2.19.4, “Loading HTML data”.
          49. HTML parameters are implementation-defined. See Section 2.19.4, “Loading HTML data”.
          50. How a processor interprets other media types is implementation-defined. See Section 2.19.5, “Loading binary data”.
          51. Parameters for other media types are implementation-defined. See Section 2.19.5, “Loading binary data”.
          52. Support for other collations is implementation-defined. See Section 2.37, “p:text-sort”.
          53. It is implementation-defined what other formats are supported. See Section 2.39, “p:unarchive”.
          54. It is implementation-defined how the step determines the archive's format. See Section 2.39, “p:unarchive”.
          55. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.39, “p:unarchive”.
          56. It is implementation-defined what other formats are supported. See Section 2.40, “p:uncompress”.
          57. It is implementation-defined how the step determines the compression format. See Section 2.40, “p:uncompress”.
          58. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.40, “p:uncompress”.
          59. If the version is not specified, the version of UUID computed is implementation-defined. See Section 2.42, “p:uuid”.
          60. Support for other versions of UUID is implementation-defined. See Section 2.42, “p:uuid”.
          61. The names and values of parameters to p:uuid are implementation-defined. See Section 2.42, “p:uuid”.
          62. Support for XQueryX is implementation-defined. See Section 2.48, “p:xquery”.
          63. It is implementation-defined which XQuery version(s) is/are supported. See Section 2.48, “p:xquery”.
          64. The point in time returned as the current dateTime is implementation-defined. See Section 2.48, “p:xquery”.
          65. The implicit timezone is implementation-defined. See Section 2.48, “p:xquery”.
          66. It is implementation-defined which XSLT version(s) is/are supported. See Section 2.49, “p:xslt”.
          67. Whether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher). See Section 2.49, “p:xslt”.

          A.2. Implementation-dependent features

          The following features are implementation-dependent:

          1. 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. See Section 2.20, “p:make-absolute-uris”.
          2. The set of available documents (those that may be retrieved with a URI) is implementation-dependent. See Section 2.48, “p:xquery”.
          3. The set of available collections is implementation-dependent. See Section 2.48, “p:xquery”.
          4. How XSLT message termination errors are reported to the XProc processor is implementation-dependent. See Section 2.49, “p:xslt”.
          5. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.
          6. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.

          B. References

          B.1. Normative References

          [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

          [W3C XML Schema: Part 2] XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, editors. World Wide Web Consortium, 28 October 2004.

          [XPath 3.1] XML Path Language (XPath) 3.1. Jonathan Robie, Michael Dyck, Josh Spiegel, editors. W3C Recommendation. 21 March 2017.

          [XPath and XQuery Functions and Operators 3.1] XPath and XQuery Functions and Operators 3.1. Michael Kay, editor. W3C Recommendation. 21 March 2017

          [XSLT 3.0] XSL Transformations (XSLT) Version 3.0. Michael Kay, editor. W3C Recommendation. 8 June 2017.

          [XInclude] XML Inclusions (XInclude) Version 1.0 (Second Edition). Jonathan Marsh, David Orchard, and Daniel Veillard, editors. W3C Recommendation. 15 November 2006.

          [RFC 1321] RFC 1321: The MD5 Message-Digest Algorithm. R. Rivest. Network Working Group, IETF, April 1992.

          [RFC 2046] RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein, editors. Internet Engineering Task Force. November, 1996.

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

          [RFC 2617] RFC 2617: HTTP Authentication: Basic and Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. June, 1999 .

          [RFC 3986] RFC 3986: Uniform Resource Identifier (URI): General Syntax. T. Berners-Lee, R. Fielding, and L. Masinter, editors. Internet Engineering Task Force. January, 2005.

          [RFC 4646] RFC 4646: Tags for Identifying Languages. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [RFC 4647] RFC 4647: Matching of Language Tags. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [BCP 47] Best Current Practices 47. Concatenation of RFC 4646: Tags for Identifying Languages, ed. A. Phillips and M. Davis, September 2006, http://www.ietf.org/rfc/bcp/bcp47.txt, and RFC 4647: Matching of Language Tags, ed. A Phillips and M. Davis, September 2006, http://www.rfc-editor.org/rfc/bcp/bcp47.txt. Internet Engineering Task Force (IETF). September, 2006.

          [CRC32] “32-Bit Cyclic Redundancy Codes for Internet Applications”, The International Conference on Dependable Systems and Networks: 459. 10.1109/DSN.2002.1028931. P. Koopman. June 2002.

          C. Glossary

          dynamic error

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

          implementation-defined

          An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

          implementation-dependent

          An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

          D. Ancillary files

          This specification includes by reference a number of ancillary files.

          steps.xpl

          An XProc step library for the declared steps.

          E. Credits

          This document is derived from XProc: An XML Pipeline Language published by the W3C. It was developed by the XML Processing Model Working Group and edited by Norman Walsh, Alex Miłowski, and Henry Thompson.

          The editors of this specification extend their gratitude to everyone who contributed to this document and all of the versions that came before it.

          F. Change Log

          This appendix catalogs non-editorial changes made after the August 2020 “last call” draft:

          1. Allow the output of the p:insert step to be text. (issue 583.)

          2. Clarified that the manifest has precedence in the p:archive step. (issue 462.)

          3. Changed the type of several options from xs:token to xs:string (issue 490.)

          4. Changed the type of the parameters option from map(xs:string,xs:untypedAtomic+) to map(xs:string,xs:anyAtomicType+). (issue 491.)

          These are the non-editorial changes made after the February 2020 “last call” draft:

          1. For p:cast-content-type the expected result type for casting a c:param-set document to “application/json” was specified as map(xs:QName, xs:string). (2020-03-15)

          2. In p:http-request, instead of using all document properties (with a few explicit exceptions) as headers, only document properties in the http://www.w3.org/ns/xproc-http namespace will be used. (2020-03-18)

          3. Section 2.3.1, “The archive manifest”: An attribute c:entry/@content-type was added to the archive manifest, to be filled by the p:archive-manifest step. (2020-03-20)

          4. A static-parameters was added to p:xslt. (2020-03-23)

          5. The override-content-types option was added to p:archive-manifest and p:unarchive. (2020-03-30)

          6. Clarified the regular expression matching for p:text-replace and p:unarchive. Added an error code for invalid regular expressions. (2020-04-02)

          7. Replaced errors XC0070 and XC0130 with XD0079. (2020-04-09)

          8. Changed signature of p:split-sequence so that any document can appear one port source. (2020-05-22)

          9. Change the behavior of the global-context-item option of p:xslt. (2020-06-10)

          10. Clarified which steps may produce PSVI annotations. (2020-06-09)

          11. Clarified the behaviour in p:archive: A missing resource referenced by c:archive/c:entry/@href is only an error for command = 'create'. (2020-06-11)

          12. Option populate-default-collection is added to the signature of p:xslt. (2020-06-20)

          13. Clarified how the default content-type header of p:http-request is constructed if a single document appears on source port. (2020-06-20)

          14. Added error (XD0079) to p:http-request and p:load for invalid content-types. (2020-06-23)

          15. Changed signature of the result port of p:load to sequence="false" and adapted the prose accordingly. (2020-06-24)

          \ No newline at end of file diff --git a/master/head/steps/index.html b/master/head/steps/index.html index 12b6068fa..40ac1fe9e 100644 --- a/master/head/steps/index.html +++ b/master/head/steps/index.html @@ -1,4 +1,4 @@ -XProc 3.0+: Standard Step Library

          XProc 3.0+: Standard Step Library

          Draft Community Group Report

          Editor's Draft at (build 47)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/steps/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against the 3.0 specification
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020, 2021, 2022 the Contributors to the XProc 3.0+: Standard Step Library specification, published by the XProc Next Community Group under the W3C +XProc 3.0+: Standard Step Library

          XProc 3.0+: Standard Step Library

          Draft Community Group Report

          Editor's Draft at (build 46)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/steps/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against the 3.0 specification
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020, 2021, 2022 the Contributors to the XProc 3.0+: Standard Step Library specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the standard step vocabulary of XProc 3.0: An XML Pipeline Language.

          diff --git a/master/head/steps/lcdiff.html b/master/head/steps/lcdiff.html index 724eb2c4a..ffee95a79 100644 --- a/master/head/steps/lcdiff.html +++ b/master/head/steps/lcdiff.html @@ -15,4 +15,4 @@ Previous Next -

          XProc 3.0+: Standard Step Library

          Draft Community Group Report

          Editor's Draft at (build 47)
          Specification:
          Latest editor’s draft:
          https://spec.xproc.org/3.0/master/head/steps/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Errata:
          Changes:
          https://spec.xproc.org/3.0/steps/errata.htmlDiff against the 3.0 specification
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML, PDF (A4),and HTML with automatic change markup courtesy of PDF (US Letter)DeltaXML.

          Copyright © 2018, 2019, 2020, 2021, 2022 the Contributors to the XProc 3.0+: Standard Step Library specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the standard step vocabulary of XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

          If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

          Note

          This draft is the “editor’s working draft” and includes changes made after the XProc 3.0 standard step specification was released.

          This document is derived from XProc: An XML Pipeline Language published by the W3C.

          1. Introduction

          This specification describes the standard, required atomic XProc steps. A machine-readable description of these steps may be found in steps.xpl.

          Many atomic steps are available for [XProc 3.0]. They are described in several specifications. This specification describes the general background common to all steps. A conformant processor must implement all of the steps in this specification. Additional steps may also be implemented.

          The types given for options should be understood as follows:

          • Types in the XML Schema namespace, identified as QNames with the xs: prefix, as per the XML Schema specification with one exception. Anywhere an xs:QName is specified, an EQName is allowed.

          • XPathExpression: As a string per [W3C XML Schema: Part 2], including whitespace normalization, and the further requirement to be a conformant Expression per [XPath 3.1].

          • XSLTSelectionPattern: As a string per [XSLT 3.0] conforming to an XSLT selection pattern.

          • XPathSequenceType: An XPath sequence type.

          • ContentType: A media type as defined in [RFC 2046].

          • ContentTypes: As a whitespace separated list of media types as defined in [RFC 2046].

          Option values are often expressed using the shortcut syntax. In these cases, the option shortcuts are generally treated as value templates. However, for options of type map() or array(), an expression is required (there is no non-expression string which can ever be a legal value for a map or array). Given that every value entered this way will have to be a value template, and consequently every curly brace contained within the expression will have to be escaped, values of type map or array are defined to be expressions directly.

          Some aspects of documents are generally unchanged by steps:

          • When a step in this library produces an output document, the base URI of the output is the base URI of the step's primary input document unless the step's process explicitly sets an xml:base attribute or the step's description explicitly states how the base URI is constructed.

          • Steps are responsible for describing how document properties are transformed as documents flow through them. Many steps claim that the specified properties are preserved. Generally, it is the responsibility of the pipeline author to determine when this is inapropriate and take corrective action. However, it is the responsibility of the pipeline processor to assure that the content-type property is correct. If a step transforms a document in a manner that is inconsistent with the content-type property (accepting an XML document on the source port but producing a text document on the result, for example), the processor must assure that the content-type property is appropriate. If a step changes the content-type in this way, it must also remove the serialization property

          Also, in this specification, several steps use this element for result information:

          <c:result>
              string
          </c:result>

          When a step uses an XPath to compute an option value, the XPath context is as defined in [XProc 3.0].

          When a step specifies a particular version of a technology, implementations must implement that version or a subsequent version that is backwards compatible with that version. At user-option, they may implement other non-backwards compatible versions.

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

          As described in PSVIs in XProc in XProc 3.0: An XML Pipeline Language, steps may not produce PSVI output unless that behavior is explicitly described. In this specification, the steps that may produce PSVI output are the “identity” steps: p:identity, p:store, and p:split-sequence (which must preserve PSVI properties that appear on their inputs). In addition, the p:xslt and p:xquery steps may return documents with PSVI annotations.

          2. The required steps

          2. Step library

          A conformant processor must support all of these steps.

          2.1. p:add-attribute

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attribute-namexs:QName ✔ 
          attribute-valuexs:string ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the selection pattern matches a node which is not an element.
          err:C0059It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

          <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 () if the selection pattern matches a node which is not an element.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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. 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.

          Note

          If multiple attributes need to be set on the same element(s), the p:set-attributes step can be used to set them all at once.

          This step cannot be used to add namespace declarations. It is a dynamic error () if the QName value in the attribute-name option is “xmlns” or 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.This step cannot be used to add namespace declarations. It is a dynamic error () if the QName value in the attribute-name option is “xmlns” or 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.

          Document properties

          All document properties are preserved.

          2.2. p:add-xml-base

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          allxs:booleanfalse()
          relativexs:booleantrue()
          Errors
          Error codeDescription
          err:C0058It is a dynamic error if the all and relative options are both true.
          Declaration

          <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 all option must be a boolean.

          The value of the relative option must be a boolean.The value of the relative option must be a boolean.

          It is a dynamic error () if the all and relative options are bothtrue.It is a dynamic error () if the all and relative options are bothtrue.

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

          • For every element that is a child of the document node: force the element to have an xml:base attribute with the document's [base URI] property's value as its value.

          • For other elements:

            • If the all option has the value true, force the element to have an xml:base attribute with the element's [base URI] value as its value.If the all option has the value true, force the element to have an xml:base attribute with the element's [base URI] value as its value.

            • If the element's [base URI] is different from the its parent's [base URI], force the element to have an xml:base attribute with the following value: if the value of the relative option is true, a string which, when resolved against the parent's [base URI], will give the element's [base URI], otherwise the element's [base URI].If the element's [base URI] is different from the its parent's [base URI], force the element to have an xml:base attribute with the following value: if the value of the relative option is true, a string which, when resolved against the parent's [base URI], will give the element's [base URI], otherwise the element's [base URI].

            • Otherwise, if there is an xml:base attribute present, remove it.

          Document properties

          All document properties are preserved.

          2.3. p:archive

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

          Summary

          Input portPrimarySequenceContent typesDefault binding
          source✔ ✔ any 
          manifest ✔ xml p:empty
          archive ✔ any p:empty
          Output portPrimarySequenceContent typesDefault binding
          result✔  any 
          report  application/xml 
          Option nameTypeDefault value
          formatxs:QName'zip'
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0080It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0084It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0100It is a dynamic error if the document on port manifest does not conform to the given schema.
          err:C0112It is a dynamic error if more than one document appears on the port manifest.
          err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedThe list of formats supported by the p:archive step is implementation-defined.
          DefinedThe list of archive formats that can be modified by p:archive is implementation-defined.
          DefinedThe semantics of any additional attributes, elements and their values are implementation-defined.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe c:archive root element may contain additional implementation-defined attributes.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what other compression methods are supported.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what compression levels are supported.
          DefinedThe c:entry elements may contain additional implementation-defined attributes.
          DefinedThe p:archive step may support additional, implementation-defined commands for ZIP files.
          DefinedThe actual parameter names supported by p:archive for a particular format are implementation-defined.
          Declaration

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

          source

          The (primary) source port is used to provide documents to be archived (for instance constructed by other steps). How and which of these documents are processed is governed by the document(s) appearing on the other input ports and the combination of options and parameters. See below for details. It is a dynamic error () if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.The (primary) source port is used to provide documents to be archived (for instance constructed by other steps). How and which of these documents are processed is governed by the document(s) appearing on the other input ports and the combination of options and parameters. See below for details. It is a dynamic error () if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          manifest

          The manifest port can receive a manifest document that tells the step how to construct the archive. If no manifest document is provided on this port, a default manifest is constructed automatically. See . It is a dynamic error () if the document on port manifest does not conform to the given schema. The manifest port can receive a manifest document that tells the step how to construct the archive. If no manifest document is provided on this port, a default manifest is constructed automatically. See . It is a dynamic error () if the document on port manifest does not conform to the given schema.

          It is a dynamic error () if more than one document appears on the port manifest.It is a dynamic error () if more than one document appears on the port manifest.

          The default input for this port is the empty sequence.

          archive

          The archive port is used to provide the step with existing archive(s) for operations like update, freshen or merge. Handling of ZIP files supports modifying archives appearing on the archive port (). The list of archive formats that can be modified by p:archive is implementation-defined. For instance an implementation that supports archive merging may accept more than one document on the archive port.The archive port is used to provide the step with existing archive(s) for operations like update, freshen or merge. Handling of ZIP files supports modifying archives appearing on the archive port (). The list of archive formats that can be modified by p:archive is implementation-defined. For instance an implementation that supports archive merging may accept more than one document on the archive port.

          The default input for this port is the empty sequence.

          The p:archive step has the following output ports:

          result

          The (primary) result port will output the resulting archive.The (primary) result port will output the resulting archive.

          report

          The report port will output a report about the archiving operation. This will be the same as the manifest (as provided on the manifest port or automatically created if there was no manifest provided), optionally amended with additional attributes and/or elements. The semantics of any additional attributes, elements and their values are implementation-defined.The report port will output a report about the archiving operation. This will be the same as the manifest (as provided on the manifest port or automatically created if there was no manifest provided), optionally amended with additional attributes and/or elements. The semantics of any additional attributes, elements and their values are implementation-defined.

          The p:archive step has the following options:

          format

          The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.

          parameters

          The parameters option can be used to supply parameters to control the archiving. The semantics of the keys and the allowed values for these keysSeveral parameters are defined for processing , but implementations are free to use additional parameters and to use parameters for controlling how other archive formats are processed. It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.The parameters option can be used to supply parameters to control the archiving. The semantics of the keys and the allowed values for these keysSeveral parameters are defined for processing , but implementations are free to use additional parameters and to use parameters for controlling how other archive formats are processed. It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          relative-to

          The relative-to option is used in creating a manifest when no manifest is provided on the manifest port. If a manifest is present this option is not used. If the option’s value is a relative URI, 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 () if the base URI is not both absolute and valid according to [].The relative-to option is used in creating a manifest when no manifest is provided on the manifest port. If a manifest is present this option is not used. If the option’s value is a relative URI, 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 () if the base URI is not both absolute and valid according to [].

          The format of the archive is determined as follows:

          • If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option.If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the archive port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format. If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the archive port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format.

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

          2.3.1. The archive manifest

          An archive manifest specifies which documents will be considered in processing the archive. Every entry in the archive must have a corresponding entry in the manifest; if no such entry is provided, one will be constructed automatically (see below). If manifest entries are provided for documents that are not in the archive, how those are processed depends on the archive type and the parameters passed to the step.

          A manifest is represented by a c:archive root element:

          <c:archive>
              (c:entry* &
               anyNonXProcElement*)
          </c:archive>

          The c:archive root element may contain additional implementation-defined attributes.

          All entries in the archive must be present as c:entry child elements:

          <c:entry
            name = string
            href = anyURI
            comment? = string
            method? = string
            level? = string
            content-type? = ContentType>
              anyElement*
          </c:entry>

          • The name attribute specifies the name of the entry in the archive.

          • The href attribute must be a valid URI according to [RFC 3986]. If its value is relative, it is made absolute against the base URI of the manifest. There are two possible cases:

            • If the (absolute) href value is exactly the same as the base URI of a document appearing on the source port, that document is associated with this entry. If this entry is to be added to the archive, the associated document will be used. (The serialization document property can be used to provide serialization properties.) If the (absolute) href value is exactly the same as the base URI of a document appearing on the source port, that document is associated with this entry. If this entry is to be added to the archive, the associated document will be used. (The serialization document property can be used to provide serialization properties.)

            • If no document on the source port has a base URI that is exactly the same as the (absolute) href value, the document at the specified URI is associated with this entry. These documents are stored in the archive “as is”; they must not be parsed and re-serialized.If no document on the source port has a base URI that is exactly the same as the (absolute) href value, the document at the specified URI is associated with this entry. These documents are stored in the archive “as is”; they must not be parsed and re-serialized.

          • The method attribute specifies how the entry should be compressed. The default compression method is implementation-defined. Implementations must support no compression, specified with the value none. It is implementation-defined what other compression methods are supported.

          • The level attribute specifies the level of compression. The default compression method is implementation-defined. It is implementation-defined what compression levels are supported.

          • The content-type attribute specifies the content-type of the entry as detected by the processor. It will be set by p:archive-manifest in constructing the manifest. It will be ignored by p:archive.

          The p:archive step should strive to retain the order of the c:entry elements when constructing the archive. For instance, an e-book in EPUB format has a non-compressed entry that must be first in the archive. It should be possible to construct such an archive using p:archive.

          The c:entry elements may contain additional implementation-defined attributes.

          If no manifest entry is provided for a document appearing on the source port, the step will create a manifest entry for the document. (If no document arrives on the manifest port at all, a complete manifest document will be created.)If no manifest entry is provided for a document appearing on the source port, the step will create a manifest entry for the document. (If no document arrives on the manifest port at all, a complete manifest document will be created.)

          In a constructed manifest entry:

          • The entry’s href value is the base URI of the document.

          • The entry’s name value is derived from the base URI of the document and the relative-to option.The entry’s name value is derived from the base URI of the document and the relative-to option.

            • First, the value of the relative-to option is made absolute. If the initial substring of the base URI is exactly the same as the resulting absolute value, then the name is the portion of the base URI that follows that initial substring. First, the value of the relative-to option is made absolute. If the initial substring of the base URI is exactly the same as the resulting absolute value, then the name is the portion of the base URI that follows that initial substring.

            • If there is no relative-to option or if its value is not the initial substring of the base URI of the document, the name is the path portion of the URI (per []). If the path portion begins with an initial slash, that slash is removed. If there is no relative-to option or if its value is not the initial substring of the base URI of the document, the name is the path portion of the URI (per []). If the path portion begins with an initial slash, that slash is removed.

          It is a dynamic error () if an archive manifest is invalid according to the specification.It is a dynamic error () if an archive manifest is invalid according to the specification.

          2.3.2. Handling of ZIP archives

          The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip. The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip.

          When ZIP archives are processed, every name in the manifest must be a relative path without a leading slash.

          The parameters option can be used to supply parameters to control the archiving. For the zip format, the following parameters must be supported:The parameters option can be used to supply parameters to control the archiving. For the zip format, the following parameters must be supported:

          command

          Specifies what operation to perform. If not specified, its default value is update. Implementations must support the values update, create, freshen, and delete. The p:archive step may support additional, implementation-defined commands for ZIP files. Unless otherwise specified, exactly zero or one ZIP archive can appear on the archive port for the commands described below. If no archive appears, a new archive will be created. Specifies what operation to perform. If not specified, its default value is update. Implementations must support the values update, create, freshen, and delete. The p:archive step may support additional, implementation-defined commands for ZIP files. Unless otherwise specified, exactly zero or one ZIP archive can appear on the archive port for the commands described below. If no archive appears, a new archive will be created.

          update

          When the command parameter is set to update, the ZIP archive will be updated:

          1. For every entry in the ZIP file:

            • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is updated with the document identified by the c:entry in the manifest.

            • If the manifest does not contain a matching c:entry, the ZIP entry name is resolved against the base URI of the ZIP file.

              • If a document exists at that URI and either has no timestamp or has a timestamp more than the timestamp in the ZIP file, the entry in the ZIP file will be updated with the document at the resolved URI.

              • If no document exists at that URI, or the document cannot be accessed, or the document has a timestamp and the timestamp in the ZIP archive is more recent than the timestamp of the document, then the ZIP entry is unchanged.

          2. For every c:entry in the manifest that does not have a matching entry in the ZIP file, the ZIP file will be updated by adding the document identified by the c:entry to the ZIP file.

          create

          When the command parameter is set to create, the ZIP archive will be created. Creating a ZIP archive behaves exactly like update except that any timestamps are ignored; every ZIP entry will be updated or created if there is a or matching document for it. The document must be obtained by dereferencing the URI in href. It is a dynamic error () if the resource referenced by the href option does not exist, cannot be accessed or is not a file.When the command parameter is set to create, the ZIP archive will be created. Creating a ZIP archive behaves exactly like update except that any timestamps are ignored; every ZIP entry will be updated or created if there is a or matching document for it. The document must be obtained by dereferencing the URI in href. It is a dynamic error () if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          freshen

          When the command parameter is set to freshen, existing files in the ZIP archive may be updated, but no new files will be added. Freshing a ZIP archive behaves exactly like update except that only entries that already exist in the ZIP archive are considered.

          delete

          When the command parameter is set to delete, exactly one document in ZIP format must appear on the archive port. For every entry in the ZIP file:When the command parameter is set to delete, exactly one document in ZIP format must appear on the archive port. For every entry in the ZIP file:

          • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is removed from the ZIP archive.

          If the manifest contains c:entry elements which do not have a matching entry in the ZIP archive, they are simply ignored.

          level

          Specifies the default compression level for files added to or updated in the archive. If the level attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “smallest”, “fastest”, “default”, “huffman”, and “none”.

          method

          Specifies the default compression method for files added to or updated in the archive. If the method attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “none” and “deflated”.

          It is a dynamic error () if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.It is a dynamic error () if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          Implementations of other archive formats should use the same parameter names if applicable. The value spaces for these parameters may be format-specific though. The actual parameter names supported by p:archive for a particular format are implementation-defined.

          Document properties

          No document properties are preserved. The archive has no base-uri.

          2.4. p:archive-manifest

          The p:archive-manifest creates an XML manifest file describing the contents of the archive appearing on its source port.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          formatxs:QName?()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0146It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedAdditional information provided for entries in p:archive-manifest is implementation-defined.
          Declaration

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

          • If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option. If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format. If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format.

          It is a dynamic error () if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.It is a dynamic error () 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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.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 () 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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

          The generated manifest has the format as described in . Implementations must supply an 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 . It is a dynamic error () 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 generated manifest has the format as described in . Implementations must supply an 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 . It is a dynamic error () 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.

          2.4.1. Overriding content types

          The override-content-types option can be used to partially override the content-type determination mechanism. If present, it must be an array of arrays, where the inner arrays consist of exactly two strings: The override-content-types option can be used to partially override the content-type determination mechanism. If present, it must be an array of arrays, where the inner arrays consist of exactly two strings:

          • The first member in an inner array must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if the specified value is not a valid XPath regular expression.The first member in an inner array must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if the specified value is not a valid XPath regular expression.

          • The second member in an inner array must be a valid a MIME content-type. It is a dynamic error () if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.The second member in an inner array must be a valid a MIME content-type. It is a dynamic error () 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 () if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.It is a dynamic error () if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          Determining an archive entry's content-type is as follows:

          • The XPath regular expressions (the first members of the inner arrays) will be matched against the path of the entry in the archive. This will be done in the order of appearance in the outer array (so order is significant). The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • If a match is found, the content-type (the second member of the inner array for which the match was found) is used as the entry's content-type.

          • If no match was found for all inner arrays, the normal (implementation-defined) mechanism for determining the content-type is used.

          For example: setting the override-content-types option to [ ['.rels$', 'application/xml'], ['^special/', 'application/octet-stream'] ] means that all files ending with .rels will get the content-type application/xml. All files in the archive's special directory (including sub-directories) will get the content-type application/octet-stream.For example: setting the override-content-types option to [ ['.rels$', 'application/xml'], ['^special/', 'application/octet-stream'] ] means that all files ending with .rels will get the content-type application/xml. All files in the archive's special directory (including sub-directories) will get the content-type application/octet-stream.

          Document properties

          No document properties are preserved. The manifest has no base-uri.

          2.5. p:cast-content-type

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          content-typexs:string ✔ 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0071It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.
          err:C0072It is a dynamic error if the c:data contains content is not a valid base64 string.
          err:C0073It is a dynamic error if the c:data element does not have a content-type attribute.
          err:C0074It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:D0049It is a dynamic error if the text value is not a well-formed XML document
          err:D0057It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the text document can not be converted into the XPath data model
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedThe precise nature of the conversion from XML to JSON is implementation-defined.
          DefinedCasting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.
          DefinedCasting from an HTML media type to a JSON media type is implementation-defined.
          DefinedCasting from an HTML media type to any other media type is implementation-defined.
          DefinedIt is implementation-defined whether other result formats are supported.
          DefinedCasting from a JSON media type to an HTML media type is implementation-defined.
          DefinedCasting from a JSON media type to any other media type is implementation-defined.
          DefinedThe precise way in which text documents are parsed into the XPath data model is implementation-defined.
          DefinedCasting from a text media type to any other media type is implementation-defined.
          DefinedCasting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.
          DefinedCasting from any other media type to any other media type is implementation-defined.
          Declaration

          <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 () 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 () if the p:cast-content-type step cannot perform the requested cast. The input document is transformed from one media type to another. It is a dynamic error () 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 () 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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          2.5.1. Casting from an XML media type

          • Casting from one XML media type to another simply changes the “content-type” document property.

          • Casting from an XML media type to an HTML media type changes the “content-type” document property and removes any serialization property.

          • Casting from an XML media type to a JSON media type converts the XML into JSON. The precise nature of the conversion from XML to JSON is implementation-defined. If the input document is an XML representation of JSON as defined in [XPath and XQuery Functions and Operators 3.1], implementations must produce the same result as fn:parse-json(fn:xml-to-json()) by default. If the input document has a c:param-set document element, an instance of map(xs:QName, xs:string)must be returned that represents the document's c:param elements. The serialization property is removed.

          • Casting from an XML media type to a text media type serializes the XML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.Casting from an XML media type to a text media type serializes the XML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an XML media type to any other media type must support the case where the input document is a c:data document. The resulting document will have the specified media type and a representation that is the content of the c:data element after decoding the base64 encoded content The serialization property is removed.

            It is a dynamic error () if the contains content is not a valid base64 string.It is a dynamic error () if the contains content is not a valid base64 string.

            It is a dynamic error () if the element does not have a content-type attribute.It is a dynamic error () if the element does not have a content-type attribute.

            It is a dynamic error () if the content-type is supplied and is not the same as the content-type specified on the element. It is a dynamic error () if the content-type is supplied and is not the same as the content-type specified on the element.

            Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.

          2.5.2. Casting from an HTML media type

          • Casting from an HTML media type to an XML media type changes “content-type” document property and removes any serialization property.

          • Casting from an HTML media type to another HTML media type changes “content-type” document property.

          • Casting from an HTML media type to a JSON media type is implementation-defined.

          • Casting an an HTML media type to a text media type serializes the HTML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.Casting an an HTML media type to a text media type serializes the HTML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an HTML media type to any other media type is implementation-defined.

          2.5.3. Casting from a JSON media type

          • Casting from a JSON media type to an XML media type converts the JSON into XML. An implementation must support the format specified in section “XML Representation of JSON” of [XPath and XQuery Functions and Operators 3.1] as default for the resulting XML. It is implementation-defined whether other result formats are supported. The serialization property is removed.

          • Casting from a JSON media type to an HTML media type is implementation-defined.

          • Casting from a JSON media type to another JSON media type changes “content-type” document property.

          • Casting from a JSON media type to a text media type serializes the JSON document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.Casting from a JSON media type to a text media type serializes the JSON document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from a JSON media type to any other media type is implementation-defined.

          2.5.4. Casting from a text media type

          • Casting from a text media type to an XML media type parses the text value of the document on source port by calling fn:parse-xml. It is a dynamic error () if the text value is not a well-formed XML document. The serialization property is removed.Casting from a text media type to an XML media type parses the text value of the document on source port by calling fn:parse-xml. It is a dynamic error () if the text value is not a well-formed XML document. The serialization property is removed.

          • Casting from a text media type to an HTML media type parses the text value of the document on source port into an XPath data model document that contains a tree of elements, attributes, and other nodes. The precise way in which text documents are parsed into the XPath data model is implementation-defined.It is a dynamic error () if the text document can not be converted into the XPath data model. The serialization property is removed.Casting from a text media type to an HTML media type parses the text value of the document on source port into an XPath data model document that contains a tree of elements, attributes, and other nodes. The precise way in which text documents are parsed into the XPath data model is implementation-defined.It is a dynamic error () if the text document can not be converted into the XPath data model. The serialization property is removed.

          • Casting from a text media type to a JSON media type parses the text value of the document on source port by calling fn:parse-json($doc, $par) where $doc is the text document and $par is the parameter option. It is a dynamic error () if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation. It is a dynamic error () if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys. It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present. The serialization property is removed. Casting from a text media type to a JSON media type parses the text value of the document on source port by calling fn:parse-json($doc, $par) where $doc is the text document and $par is the parameter option. It is a dynamic error () if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation. It is a dynamic error () if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys. It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present. The serialization property is removed.

          • Casting from a text media type to another text media type changes “content-type” document property.

          • Casting from a text media type to any other media type is implementation-defined.

          2.5.5. Casting from any other media type

          • Casting from a non-XML media type to an XML media type produces an XML document with a c:data document element. The original media type will be preserved in the content-type attribute on the c:data element.

            <c:data
              content-type = ContentType
              charset? = string
              encoding? = string>
                string
            </c:data>

            The content of the c:data element is the base64 encoded representation of the non-XML content. The serialization property is removed.

          • Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.

          • Casting from any other media type to any other media type is implementation-defined.

          Document properties

          All document properties are preserved except the content-type property which is updated accordingly and the serialization property which is removed by some casting methods.

          2.6. p:compare

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          alternate  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          differences ✔ any 
          Option nameTypeDefault value
          fail-if-not-equalxs:booleanfalse()
          methodxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0019It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.
          err:C0076It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.
          err:C0077It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.
          Implementation details
          ImplementationDescription
          DefinedImplementations of p:compare must support the deep-equal method; other supported methods are implementation-defined.
          DefinedIf 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.
          Declaration

          <p:declare-steptype="p:compare">
               <p:inputport="source"primary="true"content-types="any"/>
               <p:inputport="alternate"content-types="any"/>
               <p:outputport="result"primary="true"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 []). Implementations of p:comparemust support the deep-equalmethod; other supported methods are implementation-defined.It is a dynamic error () if the comparison method specified in p:compare is not supported by the implementation. It is a dynamic error () if the media types of the documents supplied are incompatible with the comparison method. 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 []). Implementations of p:comparemust support the deep-equalmethod; other supported methods are implementation-defined.It is a dynamic error () if the comparison method specified in p:compare is not supported by the implementation. It is a dynamic error () if the media types of the documents supplied are incompatible with the comparison method.

          It is a dynamic error () 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 document is produced with contents true if the documents are equal, otherwise false.It is a dynamic error () 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 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.

          Document properties

          No document properties are preserved. The comparison document has no base-uri.

          Erratum, April 2024

          The result output port has been made primary. This is consistent with the behavior of all known implementations.

          2.7. p:compress

          The p:compress step serializes the document appearing on its source port and outputs a compressed version of this on its result 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          formatxs:QName'gzip'
          parametersmap(xs:QName, item()*)?()
          serializationmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

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

          format

          The format of the compression can be specified using the format option. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed. The format of the compression can be specified using the format option. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed.

          parameters

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

          serialization

          The serialization option is provided to control the serialization of content before compression takes place. 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 [].The serialization option is provided to control the serialization of content before compression takes place. 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 [].

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly and the serialization property which is removed.

          2.8. p:count

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          limitxs:integer0
          Declaration

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

          Document properties

          No document properties are preserved. The count document has no base-uri.

          2.9. p:delete

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the match option matches the document node.
          err:C0062It is a dynamic error if the match option matches a namespace node.
          Declaration

          <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.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.If an element is selected by the match option, the entire subtree rooted at that element is deleted.

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

          This step cannot be used to remove namespaces. It is a dynamic error () 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.This step cannot be used to remove namespaces. It is a dynamic error () 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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.10. p:error

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          codexs:QName✔ 
          Declaration

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

          Document properties

          No document properties are preserved but that’s irrelevant as no document is ever produced.

          2.11. p:filter

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ text xml html 
          Option nameTypeRequired
          selectXPathExpression✔ 
          Declaration

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

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI of the selected node(s).

          2.12. p:hash

          The p:hash step generates a hash, or digital “fingerprint”, for some value and injects it into the source document.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault valueRequired
          algorithmxs:QName ✔ 
          valuexs:string ✔ 
          matchXSLTSelectionPattern'/*/node()' 
          parametersmap(xs:QName,item()*)?() 
          versionxs:string?() 
          Errors
          Error codeDescription
          err:C0036It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other algorithms are supported.
          Declaration

          <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”.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 [], [], and [] hashes. It is implementation-defined what other algorithms are supported. The resulting hash should be returned as a string of hexadecimal characters. A hash is constructed from the string specified in the value option using the specified algorithm and version. Implementations must support [], [], and [] 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 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 () 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 hash of the specified value is computed using the algorithm and parameters specified. It is a dynamic error () if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.13. p:http-request

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          report  application/json 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          assertxs:string'.?status-code lt 400' 
          authmap(xs:string, item()+)?() 
          headersmap(xs:string, xs:string)?() 
          methodxs:string?'GET' 
          parametersmap(xs:QName, item()*)?() 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0003It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.
          err:C0030It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).
          err:C0078It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.
          err:C0122It is a dynamic error if the given method is not supported.
          err:C0123It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.
          err:C0124It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.
          err:C0125It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.
          err:C0126It is a dynamic error if the XPath expression in assert evaluates to false.
          err:C0127It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.
          err:C0128It is a dynamic error if the URI’s scheme is unknown or not supported.
          err:C0131It is a dynamic error if the processor cannot support the requested encoding.
          err:C0132It is a dynamic error if the override content encoding cannot be supported.
          err:C0133It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.
          err:C0203It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which HTTP methods are supported.
          DefinedThe interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined.
          DefinedOther key value pairs in map “auth” are implementation-defined.
          DefinedIt is implementation-defined which other key/value pairs in the parameters option are supported.
          DefinedThe default behaviour in case of a redirect response is implementation-defined.
          DefinedIt is implementation-defined how a multipart boundary is constructed.
          Declaration

          <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.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().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 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: 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)

          This is the HTTP status code returned for the request.

          base-uri (an xs:anyURI)

          This is the URI of the last request made and is always available in the report even when the request does not return any documents. In the case of HTTP redirection, the base URI returned may be different from the original request URI.

          headers (a map(xs:string, xs:string))

          These are the HTTP headers returned for the request. The map may be empty. Header names are converted to lowercase.

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

          href

          The href option specifies the request’s IRI. Relative values are resolved against the base URI of the element on which the option is specified (the relevant p:with-option or the step element in the case of a syntactic shortcut value).The href option specifies the request’s IRI. Relative values are resolved against the base URI of the element on which the option is specified (the relevant p:with-option or the step element in the case of a syntactic shortcut value).

          Fragment identifiers are removed before making the request. Query parameters are passed through unchanged. It is a dynamic error () if the URI’s scheme is unknown or not supported. It is the pipeline author’s responsibility to escape problematic UTF-8 characters in the href value, for example with escape-html-uri(). Fragment identifiers are removed before making the request. Query parameters are passed through unchanged. It is a dynamic error () if the URI’s scheme is unknown or not supported. It is the pipeline author’s responsibility to escape problematic UTF-8 characters in the href value, for example with escape-html-uri().

          method

          The method specifies the HTTP request method. The value is implicitly turned into an uppercase string if necessary. It is implementation -defined which HTTP methods are supported. An implementation should implement at least the methods GET, POST, PUT, DELETE, and HEAD (for HTTP and HTTPS). It is a dynamic error () if the given method is not supported.The method specifies the HTTP request method. The value is implicitly turned into an uppercase string if necessary. It is implementation -defined which HTTP methods are supported. An implementation should implement at least the methods GET, POST, PUT, DELETE, and HEAD (for HTTP and HTTPS). It is a dynamic error () if the given method is not supported.

          serialization

          The serialization option is used to control the serialization of documents for the request body. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.The serialization option is used to control the serialization of documents for the request body. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.

          headers

          The key/value pairs in the headers map are used to construct the request headers. Each map key is used as a header name and the value associated with that key in the map is used as the header value.The key/value pairs in the headers map are used to construct the request headers. Each map key is used as a header name and the value associated with that key in the map is used as the header value.

          If a single document appears on the source port, then document properties on that document may be added as additional headers. For XML, HTML, and text documents with a serialization document property having an encoding key, a charset is appended to the created content-type header of the HTTP request. Properties in the http://www.w3.org/ns/xproc-http namespace will be added to the headers, using the local-name of the property QName as the header name. These properties are only copied if they are not specified in the header map. In other words, if the same header name appears in both places, the value from the map is used and the value from the document properties is ignored. (Header names are case-insensitive, so a case-insensitive comparison must be performed.) If multiple documents appear on the source port, none of their properties are used in the request headers.If a single document appears on the source port, then document properties on that document may be added as additional headers. For XML, HTML, and text documents with a serialization document property having an encoding key, a charset is appended to the created content-type header of the HTTP request. Properties in the http://www.w3.org/ns/xproc-http namespace will be added to the headers, using the local-name of the property QName as the header name. These properties are only copied if they are not specified in the header map. In other words, if the same header name appears in both places, the value from the map is used and the value from the document properties is ignored. (Header names are case-insensitive, so a case-insensitive comparison must be performed.) If multiple documents appear on the source port, none of their properties are used in the request headers.

          The behavior of the p:http-request depends on the headers specified. In particular:

          content-type

          If a content-type header is provided, it will be used. For a single document request, this overrides the content type value of the document. If the content type specified begins with “multipart/”, a multipart request will be sent to the server.

          It is a dynamic error () 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 () if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.

          transfer-encoding

          If a transfer-encoding header is provided, the request must be sent with that encoding. It is a dynamic error () if the processor cannot support the requested encoding.If a transfer-encoding header is provided, the request must be sent with that encoding. It is a dynamic error () if the processor cannot support the requested encoding.

          authorization

          The authorization header is used to authenticate a request. If the authoption is specified, any key or property that would have contributed a header named “authorization” (irrespective of case) is ignored. The authorization header is determined exclusively by the auth option when it is present.The authorization header is used to authenticate a request. If the authoption is specified, any key or property that would have contributed a header named “authorization” (irrespective of case) is ignored. The authorization header is determined exclusively by the auth option when it is present.

          HTTP headers are case-insensitive but keys in maps are not; be careful when specifying the request headers. It is a dynamic error () if the headers map contains two keys that are the same when compared in a case-insensitive manner. (That is, when fn:uppercase($key1) = fn:uppercase($key2).) HTTP headers are case-insensitive but keys in maps are not; be careful when specifying the request headers. It is a dynamic error () if the headers map contains two keys that are the same when compared in a case-insensitive manner. (That is, when fn:uppercase($key1) = fn:uppercase($key2).)

          auth

          Many web services are only available to authenticated users, that is, to users who have “logged in”. The auth option allows the pipeline author to specify information that may be required to generate an “Authorization” header. The standard values support HTTP “Basic” and “Digest” authentication, but other authentication methods are allowed.Many web services are only available to authenticated users, that is, to users who have “logged in”. The auth option allows the pipeline author to specify information that may be required to generate an “Authorization” header. The standard values support HTTP “Basic” and “Digest” authentication, but other authentication methods are allowed.

          The following standard keys are defined:

          username (xs:string)

          The username.

          password (xs:string)

          The password associated with the username.

          auth-method (xs:string)

          The authentication method. Appropriate values for the “auth-method” key are “Basic” or “Digest” but other values are allowed. If the authentication method is “Basic” or “Digest”, authentication is handled as per [RFC 2617]. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation -defined.

          send-authorization (xs:boolean)

          The “send-authorization” key can be used to attempt to allow the request to avoid an authentication challenge. If the “send-authorization” key is “true()”, and the authentication method specified by the value associated with the “auth-method” key supports generation of an “Authorization” header without a challenge, then the header is generated and sent on the first request. If the “send-authorization” key is absent or does not have the value “true”, the first request is sent without an “Authorization” header.

          Other key value pairs in map “auth” are implementation -defined.It is a dynamic error () if any key in the “auth” map is associated with a value that is not an instance of the required type.Other key value pairs in map “auth” are implementation -defined.It is a dynamic error () if any key in the “auth” map is associated with a value that is not an instance of the required type.

          If the initial response to the request is an authentication challenge, the values provided in the auth map and any relevant data from the challenge are used to generate an “Authorization” header and the request is sent again. If that authorization fails, the request is not retried.

          It is a dynamic error () if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported. All implementations must support “Basic” and “Digest” authentication per [].It is a dynamic error () if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported. All implementations must support “Basic” and “Digest” authentication per [].

          parameters

          The parameter option can be used to provide values for fine tuning the construction of the request and/or handling of the server response. A number of parameters are defined in this specification. It is implementation -defined which other key/value pairs in the parameters option are supported.The parameter option can be used to provide values for fine tuning the construction of the request and/or handling of the server response. A number of parameters are defined in this specification. It is implementation -defined which other key/value pairs in the parameters option are supported.

          override-content-type (xs:string)

          Ordinarily, the value of the content-type header provided in the server response controls the interpretation of any body in the response. If the “override-content-type” parameter is provided, then its value is used to interpret the body. The content-type header that appears on the report port is not changed. It is a dynamic error () 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 () if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).Ordinarily, the value of the content-type header provided in the server response controls the interpretation of any body in the response. If the “override-content-type” parameter is provided, then its value is used to interpret the body. The content-type header that appears on the report port is not changed. It is a dynamic error () 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 () if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          http-version (xs:string)

          The http-version parameter indicates which version of HTTP must be used for the request.

          accept-multipart (xs:boolean)

          If the accept-multipart parameter is present and explicitly has the value false(), a dynamic error will be raised, if a multipart response is received from the server. This feature is a convenience for pipeline authors as it will raise an error when the multipart request is received, rather than having the presence of a sequence raise an error further along in the pipeline, or simply producing anomalous results. It is a dynamic error () if the key “accept-multipart” as the value false() and a multipart response is detected.If the accept-multipart parameter is present and explicitly has the value false(), a dynamic error will be raised, if a multipart response is received from the server. This feature is a convenience for pipeline authors as it will raise an error when the multipart request is received, rather than having the presence of a sequence raise an error further along in the pipeline, or simply producing anomalous results. It is a dynamic error () if the key “accept-multipart” as the value false() and a multipart response is detected.

          override-content-encoding (xs:string)

          If the “override-content-encoding” parameter is present, the response will be treated as if the response contained a “content-encoding” header with the specified value. The content-encoding header that appears on the report port is not changed. It is a dynamic error () if the override content encoding cannot be supported. If the “override-content-encoding” parameter is present, the response will be treated as if the response contained a “content-encoding” header with the specified value. The content-encoding header that appears on the report port is not changed. It is a dynamic error () if the override content encoding cannot be supported.

          permit-expired-ssl-certificate (xs:boolean)

          If “permit-expired-ssl-certificate” is true, then the processor should not reject responses where the server provides an expired SSL certificate.

          permit-untrusted-ssl-certificate (xs:boolean)

          If “permit-untrusted-ssl-certificate” is true, then the processor should not reject response where the server provides an SSL certificate which is not trusted, for example, because the certificate authority (CA) is unknown.

          follow-redirect (xs:integer)

          The “follow-redirect” parameter allows the pipeline author to specify the step’s behaviour in the case of a redirect response. A value of 0 indicates that redirects are not to be followed, -1 indicates that redirects are to be followed indefinitely, and a specific number indicates the maximum number of redirects to follow. The default behaviour in case of a redirect response is implementation -defined.

          timeout (xs:integer)

          If a “timeout” is specified, it must be a non-negative integer. It controls the time the XProc processor waits for the request to be answered. If a value is given, it is taken as the number of seconds to wait for the response to be delivered. If no response is received after that time, the request is terminated and a status-code 408 is assumed.

          fail-on-timeout (xs:boolean)

          If “fail-on-timeout” is true, a dynamic error is raised if a 408 response is received (either as a consequence of setting a value for the “timeout” parameter or as status code returned by a server). It is a dynamic error () if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered. If “fail-on-timeout” is true, it prevents any dynamic error with code C0126 resulting from the assert option to be raised for request's timeout.If “fail-on-timeout” is true, a dynamic error is raised if a 408 response is received (either as a consequence of setting a value for the “timeout” parameter or as status code returned by a server). It is a dynamic error () if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered. If “fail-on-timeout” is true, it prevents any dynamic error with code C0126 resulting from the assert option to be raised for request's timeout.

          Note

          Please note that the “fail-on-timeout” parameter is different from the “timeout” option on the p:http-request step (see Controlling long running steps in XProc 3.0: An XML Pipeline Language). If the step does not finish in the specified time, D0053 is raised. If the request does not finish in time, and fail-on-timeout is true, C0078 is raised. The actual times after which a timeout is detected may also differ slightly.

          status-only (xs:boolean)

          If the “status-only” parameter is true, this indicates that the pipeline author is only interested in the response code. An empty sequence is always returned on the result port in this case. The implementation may save resources by ignoring the response body. The map on the report will contain the status code and an empty map for “headers”.If the “status-only” parameter is true, this indicates that the pipeline author is only interested in the response code. An empty sequence is always returned on the result port in this case. The implementation may save resources by ignoring the response body. The map on the report will contain the status code and an empty map for “headers”.

          suppress-cookies (xs:boolean)

          If the “suppress-cookies” parameter is true, the implementation must not send any cookies with the request.

          send-body-anyway (xs:boolean)

          If the “send-body-anyway” parameter is true, and one or more documents appear on the source port, a request body is constructed from the documents and sent with the request, even if the semantics of sending a body are not specified for the HTTP method in use. If the “send-body-anyway” parameter is true, and one or more documents appear on the source port, a request body is constructed from the documents and sent with the request, even if the semantics of sending a body are not specified for the HTTP method in use.

          It is a dynamic error () if any key in the “parameters” map is associated with a value that is not an instance of the required type.It is a dynamic error () if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          assert (xs:string)

          The assert option can be used by pipeline authors to raise a dynamic error if the response does not fulfill the expectations of the receiver. The option's value (if present) is interpreted as an XPath expression which will be executed using the map that appears on the report port as its context item. If the effective boolean value of the expression is false(), a dynamic error is raised. It is a dynamic error () if the XPath expression in assert evaluates to false. Implementations should provide an XML representation of the map used as the context item with the error document to enable pipelines to access the error's cause.The assert option can be used by pipeline authors to raise a dynamic error if the response does not fulfill the expectations of the receiver. The option's value (if present) is interpreted as an XPath expression which will be executed using the map that appears on the report port as its context item. If the effective boolean value of the expression is false(), a dynamic error is raised. It is a dynamic error () if the XPath expression in assert evaluates to false. Implementations should provide an XML representation of the map used as the context item with the error document to enable pipelines to access the error's cause.

          2.13.1. Construction of a multipart request

          If more than one document appears on the source port, or if the specified “content-type” header begins “multipart/”, a multipart request will be constructed, per []. The content type of the request is derived from the “content-type” header:If more than one document appears on the source port, or if the specified “content-type” header begins “multipart/”, a multipart request will be constructed, per []. The content type of the request is derived from the “content-type” header:

          • If the “content-type” header specifies a multipart content type, that value will be used as the content type. If the header includes a boundary parameter, that value will be used as the boundary. It is a dynamic error () if the specified boundary is not valid (for example, if it begins with two hyphens “--”). If the “content-type” header specifies a multipart content type, that value will be used as the content type. If the header includes a boundary parameter, that value will be used as the boundary. It is a dynamic error () if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          • If the “content-type” header is not specified, “multipart/mixed” will be used.

          • It is a dynamic error () if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type. It is a dynamic error () if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          A multipart request must have a boundary marker, if one isn’t specified in the content type, the implementation must construct one. It is implementation-defined how a multipart boundary is constructed. Implementations are not required to guarantee that the constructed value does not appear accidentally in the multipart data. If it does, the request will be malformed; pipeline authors must provide a boundary if they wish to assure that this cannot happen.

          Each document in the sequence is serialized. If the document has a “serialization” document property, its values are used to determine how serialization is performed.

          All of the document properties in the http://www.w3.org/ns/xproc-http namespace will be added as headers for the part, using the local-name of the property QName as the header name. In particular, this is how the “id”, “description”, “disposition” and other multipart headers can be provided.

          2.13.2. Managing a multipart response

          When a multipart response is received, each part is interpreted according to it’s content type and a pipeline document is constructed. Any additional headers associated with the part are added to the document properties of the constructed document.

          The multipart response is the resulting sequence of documents.

          Document properties

          No document properties are preserved.

          2.14. p:identity

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Declaration

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

          Document properties

          All document properties are preserved.

          2.15. p:insert

          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.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"values="('first-child','last-child','before','after')"select="'after'"/><!-- string --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          insertion ✔ xml html text 
          Output portPrimarySequenceContent types
          result✔  xml html text 
          Option nameTypeValuesDefault value
          matchXSLTSelectionPattern '/*'
          positionxs:string('first-child','last-child','before','after') 'after'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace node.
          err:C0024It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.
          err:C0025It is a dynamic error 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”.
          Declaration

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

          The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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 match option must be an XSLTSelectionPattern. It is a dynamic error () 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: The value of the position option must be an NMTOKEN in the following list:

          • “first-child” - the insertion is made as the first child of the match;

          • “last-child” - the insertion is made as the last child of the match;

          • “before” - the insertion is made as the immediate preceding sibling of the match;

          • “after” - the insertion is made as the immediate following sibling of the match.

          It is a dynamic error () 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 () if the selection pattern matches a document node and the value of the position is “before” or “after”.It is a dynamic error () 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 () 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.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.

          Document properties

          All document properties on the source port are preserved. The document properties on the insertion port are not preserved or present in the result document.All document properties on the source port are preserved. The document properties on the insertion port are not preserved or present in the result document.

          2.16. p:json-join

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeDefault value
          flatten-to-depthxs:string?'0'
          Errors
          Error codeDescription
          err:C0111 It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.
          err:C0119It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

          <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 step inspects the documents on port source in turn to create the resulting array:

          • If the document under inspection is a JSON document representing an array, the array is copied to the resulting array according to the setting of option flatten-to-depth.If the document under inspection is a JSON document representing an array, the array is copied to the resulting array according to the setting of option flatten-to-depth.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents, their XDM representation is appended to the resulting array.

          • It is implementation -defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, an entry is created as described above. It is a dynamic error () if a document of an unsupported document type appears on port source of p:json-join. It is implementation -defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, an entry is created as described above. It is a dynamic error () if a document of an unsupported document type appears on port source of p:json-join.

          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 () 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 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 () 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.

          Document properties

          No document properties are preserved. The joined document has no base-uri.

          2.17. p:json-merge

          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.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"values="('reject', 'use-first', 'use-last', 'use-any', 'combine')"select="'use-first'"/><!-- string -->     <p:optionname="key"as="xs:string"select="'concat("_",$p:index)'"/><!-- XPathExpression --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeValuesDefault value
          duplicatesxs:string('reject', 'use-first', 'use-last', 'use-any', 'combine') 'use-first'
          keyXPathExpression 'concat("_",$p:index)'
          Errors
          Error codeDescription
          err:C0106It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.
          err:C0107 It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.
          err:C0110It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

          <p:declare-steptype="p:json-merge">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"content-types="application/json"/>
               <p:optionname="duplicates"values="('reject', 'use-first', 'use-last', 'use-any', 'combine')"select="'use-first'"/><!-- string -->
               <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:The step inspects the documents on port source in turn to create the resulting map:

          • If the document under inspection is a JSON document representing a map, all key-value pairs are copied into the result map unless this map already contains an entry with the given key. In this case the value of option duplicates determines the policy for handling duplicate keys as specified for function map:merge in []. It is a dynamic error () if duplicate keys are encountered and option duplicates has value “reject”.If the document under inspection is a JSON document representing a map, all key-value pairs are copied into the result map unless this map already contains an entry with the given key. In this case the value of option duplicates determines the policy for handling duplicate keys as specified for function map:merge in []. It is a dynamic error () if duplicate keys are encountered and option duplicates has value “reject”.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents a new key-value pair is created and put into the resulting map. The key is created by evaluating the XPath expression in option key with the inspected document as context item. If the evaluation result is a single atomic value, it is taken as key. If the evaluation result is a node, its string value is taken as key. It is a dynamic error () if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function. Duplicate keys are handled as described above. The XDM representation of the inspected document is taken as value of the key-value pair.For every other type of JSON document, for XML documents, HTML documents, or text documents a new key-value pair is created and put into the resulting map. The key is created by evaluating the XPath expression in option key with the inspected document as context item. If the evaluation result is a single atomic value, it is taken as key. If the evaluation result is a node, its string value is taken as key. It is a dynamic error () if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function. Duplicate keys are handled as described above. The XDM representation of the inspected document is taken as value of the key-value pair.

          • It is implementation -defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, the key-value pair is created as described above. It is a dynamic error () if a document of a not supported document type appears on port source of p:json-merge. It is implementation -defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, the key-value pair is created as described above. It is a dynamic error () if a document of a not supported document type appears on port source of p:json-merge.

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

          Document properties

          No document properties are preserved. The merged document has no base-uri.

          2.18. p:label-elements

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          attributexs:QName'xml:id'
          labelXPathExpression'concat("_",$p:index)'
          matchXSLTSelectionPattern'*'
          replacexs:booleantrue()
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that expression matches anything other than element nodes.
          Declaration

          <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 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 () if that expression matches anything other than element nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.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.

          Document properties

          All document properties are preserved.

          2.19. p:load

          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>

          Summary

          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          content-typexs:string?() 
          document-propertiesmap(xs:QName, item()*)?() 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:D0011It is a dynamic error if the resource referenced by a p:load element does not exist or cannot be accessed.
          err:D0023It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.
          err:D0043It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.
          err:D0049It is a dynamic error if the loaded content is not a well-formed XML document.
          err:D0057It is a dynamic error if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the content-type specifies an encoding, which is not supported by the processor.
          err:D0062It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0078It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIn the absence of an explicit type, the content type is implementation-defined
          DefinedAdditional XML parameters are implementation-defined.
          DefinedText parameters are implementation-defined.
          DefinedAdditional JSON parameters are implementation-defined.
          DefinedThe precise way in which HTML documents are parsed into the XPath data model is implementation-defined.
          DefinedHTML parameters are implementation-defined.
          DefinedHow a processor interprets other media types is implementation-defined.
          DefinedParameters for other media types are implementation-defined.
          Declaration

          <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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

          The document identified by the href URI is loaded and returned. If the URI protocol supports redirection, then redirects must be followed.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 () if the resource referenced by a p:load element does not exist or cannot be accessed.It is a dynamic error () 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:

          1. If a content-type property is specified in document-properties or content-type is present, then the document must be interpreted according to that content type. It is a dynamic error () 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 () if the content-type is specified and the document-properties has a “content-type” that is not the same. If a content-type property is specified in document-properties or content-type is present, then the document must be interpreted according to that content type. It is a dynamic error () 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 () if the content-type is specified and the document-properties has a “content-type” that is not the same.

          2. If the document is retrieved with a URI protocol that specifies a content type (for example, http:), then the document must be interpreted according to that content type.

          3. In the absence of an explicit type, the content type is implementation-defined.

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

          2.19.1. Loading XML data

          For an XML media type, the content is loaded and parsed as XML.

          It is a dynamic error () if the loaded content is not a well-formed XML document.It is a dynamic error () if the loaded content is not a well-formed XML document.

          If the dtd-validate parameter is true, then DTD validation must be performed when parsing the document. It is a dynamic error () if a DTD validation is performed and either the document is not valid or no DTD is found. It is a dynamic error () if the dtd-validate parameter is true and the processor does not support DTD validation.If the dtd-validate parameter is true, then DTD validation must be performed when parsing the document. It is a dynamic error () if a DTD validation is performed and either the document is not valid or no DTD is found. It is a dynamic error () if the dtd-validate parameter is true and the processor does not support DTD validation.

          Additional XML parameters are implementation-defined.

          2.19.2. Loading text data

          For a text media type, the content is loaded as a text document. (A text document is an XPath data model document consisting of a single text node.)

          It is a dynamic error () if the content-type specifies an encoding, which is not supported by the processor.It is a dynamic error () if the content-type specifies an encoding, which is not supported by the processor.

          Text parameters are implementation-defined.

          2.19.3. Loading JSON data

          For a JSON media type, the content is loaded and parsed as JSON.

          The parameters specified for the fn:parse-json function in [XPath and XQuery Functions and Operators 3.1] must be supported. Additional JSON parameters are implementation-defined.

          It is a dynamic error () if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.It is a dynamic error () if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          It is a dynamic error () if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.It is a dynamic error () if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.

          It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          2.19.4. Loading HTML data

          For an HTML media type, the content is loaded and parsed into an XPath data model document that contains a tree of elements, attributes, and other nodes.

          The precise way in which HTML documents are parsed into the XPath data model is implementation-defined.

          It is a dynamic error () if the loaded document cannot be represented as an HTML document in the XPath data model.It is a dynamic error () if the loaded document cannot be represented as an HTML document in the XPath data model.

          HTML parameters are implementation-defined.

          2.19.5. Loading binary data

          An XProc processor may load other, arbitrary data types. How a processor interprets other media types is implementation-defined.

          Parameters for other media types are implementation-defined.

          Document properties

          The properties specified in document-properties are applied. If the properties do not specify a base-uri, the base-uri property will reflect the base URI of the loaded document. The properties specified in document-properties are applied. If the properties do not specify a base-uri, the base-uri property will reflect the base URI of the loaded document.

          2.20. p:make-absolute-uris

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          base-urixs:anyURI?() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than element or attribute nodes.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DependentIf 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.
          Declaration

          <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 () if the pattern matches anything other than element or attribute nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

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

          Document properties

          All document properties are preserved.

          2.21. p:namespace-delete

          The p:namespace-delete step deletes all of the namespaces identified by the specified prefixes from the document appearing on port source.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeRequired
          prefixesxs:string✔ 
          Errors
          Error codeDescription
          err:C0108It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.
          err:C0109It is a dynamic error if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.
          Declaration

          <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 () if any prefix is not in-scope at the point where the p:namespace-delete occurs.The value of option prefixes is taken as a space separated list of prefixes. It is a dynamic error () 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.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 () if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.It is a dynamic error () if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.

          Document properties

          All document properties are preserved.

          2.22. p:namespace-rename

          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"select="'all'"values="('all','elements','attributes')"/><!-- string --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeValuesDefault value
          apply-toxs:string('all','elements','attributes') 'all'
          fromxs:anyURI? ()
          toxs:anyURI? ()
          Errors
          Error codeDescription
          err:C0014It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.
          err:C0092It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.
          Declaration

          <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"select="'all'"values="('all','elements','attributes')"/><!-- string -->
          </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 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 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.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 () 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.It is a dynamic error () if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.

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

          • Namespace bindings: If the from option is present and its value is not the empty string, then every binding of a prefix (or the default namespace) in the input document whose value is the same as the value of the from option isNamespace bindings: If the from option is present and its value is not the empty string, then every binding of a prefix (or the default namespace) in the input document whose value is the same as the value of the from option is

            • replaced in the output with a binding to the value of the to option, provided it is present and not the empty string;replaced in the output with a binding to the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) absent from the output.otherwise (the to option is not specified or has an empty string as its value) absent from the output.

            If the from option is absent, or its value is the empty string, then no bindings are changed or removed.If the from option is absent, or its value is the empty string, then no bindings are changed or removed.

          • Elements and attributes: If the from option is present and its value is not the empty string, for every element and attribute, as appropriate, in the input whose namespace name is the same as the value of the from option, in the output its namespace name isElements and attributes: If the from option is present and its value is not the empty string, for every element and attribute, as appropriate, in the input whose namespace name is the same as the value of the from option, in the output its namespace name is

            • replaced with the value of the to option, provided it is present and not the empty string;replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) changed to have no value.otherwise (the to option is not specified or has an empty string as its value) changed to have no value.

            If the from option is absent, or its value is the empty string, then for every element and attribute, as appropriate, whose namespace name has no value, in the output its namespace name is set to the value of the to option.If the from option is absent, or its value is the empty string, then for every element and attribute, as appropriate, whose namespace name has no value, in the output its namespace name is set to the value of the to option.

            It is a dynamic error () if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.It is a dynamic error () if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          • Namespace attributes: If the from option is present and its value is not the empty string, for every namespace attribute in the input whose value is the same as the value of the from option, in the outputNamespace attributes: If the from option is present and its value is not the empty string, for every namespace attribute in the input whose value is the same as the value of the from option, in the output

            • the namespace attribute's value is replaced with the value of the to option, provided it is present and not the empty string;the namespace attribute's value is replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) the namespace attribute is absent.otherwise (the to option is not specified or has an empty string as its value) the namespace attribute is absent.

          Note

          The apply-to option is primarily intended to make it possible to avoid renaming attributes when the from option specifies no namespace, since many attributes are in no namespace.The apply-to option is primarily intended to make it possible to avoid renaming attributes when the from option specifies no namespace, since many attributes are in no namespace.

          Care should be taken when specifying no namespace with the to option. Prefixed names in content, for example QNames and XPath expressions, may end up with no appropriate namespace binding.Care should be taken when specifying no namespace with the to option. Prefixed names in content, for example QNames and XPath expressions, may end up with no appropriate namespace binding.

          Document properties

          All document properties are preserved.

          2.23. p:pack

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          alternate ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeRequired
          wrapperxs:QName✔ 
          Declaration

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

          Note

          In the common case, where the document element of a document in the result sequence has two element children, any comments, processing instructions, or white space text nodes that occur between them may have come from either of the input documents; this step does not attempt to distinguish which one.In the common case, where the document element of a document in the result sequence has two element children, any comments, processing instructions, or white space text nodes that occur between them may have come from either of the input documents; this step does not attempt to distinguish which one.

          Document properties

          No document properties are preserved. The result documents do not have a base-uri property.

          2.24. p:rename

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          new-namexs:QName ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0013It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.
          err:C0023It is a dynamic error if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.
          Declaration

          <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 () if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.

          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.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.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 () if the pattern matches a processing instruction and the new name has a non-null namespace. If the pattern matches processing instructions, then it is the processing instruction target that is renamed. It is a dynamic error () if the pattern matches a processing instruction and the new name has a non-null namespace.

          Document properties

          All document properties are preserved.

          2.25. p:replace

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          replacement  text xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace nodes.
          Declaration

          <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 () 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.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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, the result is a text document with the text node wrapped in a document node.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.26. p:set-attributes

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attributesmap(xs:QName, xs:anyAtomicType) ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than element nodes.
          err:C0059It is a dynamic error if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

          <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 () if that pattern matches anything other than element nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.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.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.

          IfThis step cannot be used to add namespace declarations. It is a dynamic error (the ) if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/. However, 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.IfThis step cannot be used to add namespace declarations. It is a dynamic error (the ) if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/. However, 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.

          Document properties

          All document properties are preserved.

          2.27. p:set-properties

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          propertiesmap(xs:QName,item()*) ✔ 
          mergexs:booleantrue() 
          Errors
          Error codeDescription
          err:C0069It is a dynamic error if the properties map contains a key equal to the string “content-type”.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0070It is a dynamic error 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 .
          Declaration

          <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.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.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 () 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 [].It is a dynamic error () 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 [].

          It is a dynamic error () if the properties map contains a key equal to the string “content-type”. It is a dynamic error () 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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

          Document properties

          If merge is true, document properties not overridden by settings in the properties map are preserved, otherwise the resulting document has only the content-type property and the properties specified in the properties map. In particular, if merge is false, the base-uri property will not be preserved. This means that the resulting document will not have a base URI if the properties map does not contain a base-uri entry. If merge is true, document properties not overridden by settings in the properties map are preserved, otherwise the resulting document has only the content-type property and the properties specified in the properties map. In particular, if merge is false, the base-uri property will not be preserved. This means that the resulting document will not have a base URI if the properties map does not contain a base-uri entry.

          2.28. p:sink

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Declaration

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

          Document properties

          Not applicable.

          2.29. p:sleep

          The p:sleep step introduces a delay.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          durationxs:nonNegativeInteger✔ 
          Declaration

          <p:declare-steptype="p:sleep">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"sequence="true"content-types="any"/>
               <p:optionname="duration"as="xs:nonNegativeInteger"required="true"/>
          </p:declare-step>

          The p:sleep step copies each of the documents on the source port to the result port without changing them. Before copying the documents, it pauses for a period of time not less than duration milliseconds.

          Note

          In multi-threaded implementations, there is no guarantee that this will pause the execution of more than one thread. However, any steps that depend on the output of this step will wait for this step to complete.

          Document properties

          All document properties are preserved.

          2.29. 2.30. p:split-sequence

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          matched✔ ✔ any 
          not-matched ✔ any 
          Option nameTypeDefault valueRequired
          testXPathExpression ✔ 
          initial-onlyxs:booleanfalse() 
          Errors
          Error codeDescription
          err:C0150It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.
          Declaration

          <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 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.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.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 () if evaluating the XPath expression in option test on a context document results in an error.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 () if evaluating the XPath expression in option test on a context document results in an error.

          Note

          In principle, this component cannot stream because it must buffer all of the input sequence in order to find the context size. In practice, if the test expression does not use the last() function, the implementation can stream and ignore the context size.

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

          Document properties

          All document properties are preserved.

          2.30. 2.31. p:store

          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 step, copying its input to the result port.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 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          result-uri  application/xml 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0050It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.
          Declaration

          <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 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 () if the URI scheme is not supported or the step cannot store to the specified location.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 () 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 element whose content is the absolute URI of the document stored by the step.The output of this step on the result-uri port is a document containing a single 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 [].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 [].

          Document properties

          All document properties are preserved.

          2.31. 2.32. p:string-replace

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          replaceXPathExpression✔ 
          Declaration

          <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 match option must be an XSLTSelectionPattern.

          The value of the replace option must be an XPathExpression.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.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 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.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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.32. 2.33. p:text-count

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Declaration

          <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 element whose contents is the string representing this count.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 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 (&#10;), that newline is ignored. (It is not a separator between that line and a following line that contains no characters.)

          Document properties

          No document properties are preserved. The count document does not have a base-uri property.

          2.33. 2.34. p:text-head

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

          <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:The p:text-head step returns on its result port lines from the text document that appears on its source port:

          • If the count option is positive, the p:text-head step returns the first count linesIf the count option is positive, the p:text-head step returns the first count lines

          • If the count option is zero, the p:text-head step returns all linesIf the count option is zero, the p:text-head step returns all lines

          • If the count option is negative, the p:text-head step returns all lines except the first count linesIf the count option is negative, the p:text-head step returns all lines except the first count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.34. 2.35. p:text-join

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault value
          override-content-typexs:string?()
          prefixxs:string?()
          separatorxs:string?()
          suffixxs:string?()
          Errors
          Error codeDescription
          err:C0001It is a dynamic error if the value of option override-content-type is not a text media type.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Declaration

          <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. 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 separator option is specified, its value will be inserted in between adjacent documents.When the separator option is specified, its value will be inserted in between adjacent documents.

          • When the prefix option is specified, the document appearing on the result port will always start with its value (also when there are no documents on the source port).When the prefix option is specified, the document appearing on the result port will always start with its value (also when there are no documents on the source port).

          • When the suffix option is specified, the document appearing on the result port will always end with its value (also when there are no documents on the source port).When the suffix option is specified, the document appearing on the result port will always end with its value (also when there are no documents on the source port).

          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 () 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 () if the value of option override-content-type is not a text media type. 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 () 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 () 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.

          Document properties

          No document properties are preserved. The joined document has no base-uri property.

          2.35. 2.36. p:text-replace

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault valueRequired
          patternxs:string ✔ 
          replacementxs:string ✔ 
          flagsxs:string?() 
          Errors
          Error codeDescription
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          Declaration

          <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. 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 function. The pattern option must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if the specified value is not a valid XPath regular expression.The pattern, replacement and flags options are specified the same as the parameters with the same names of the function. The pattern option must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () 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.

          Document properties

          All document properties are preserved.

          2.36. 2.37. p:text-sort

          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')"/><!-- string -->     <p:optionname="case-order"as="xs:string?"values="('upper-first', 'lower-first')"/><!-- string -->     <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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeValuesDefault value
          case-orderxs:string?('upper-first', 'lower-first') ()
          collationxs:string 'http://www.w3.org/2005/xpath-functions/collation/codepoint'
          langxs:language? ()
          orderxs:string('ascending', 'descending') 'ascending'
          sort-keyXPathExpression '.'
          stablexs:boolean true()
          Errors
          Error codeDescription
          err:C0098It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.
          err:C0099It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.
          Implementation details
          ImplementationDescription
          DefinedSupport for other collations is implementation-defined.
          Declaration

          <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')"/><!-- string -->
               <p:optionname="case-order"as="xs:string?"values="('upper-first', 'lower-first')"/><!-- string -->
               <p:optionname="lang"as="xs:language?"/>                     
               <p:optionname="collation"as="xs:string"select="'http://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.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.

          • The sort-key is used to obtain a sort key for each of the lines in the document appearing on source. The context item is the line as an instance of xs:string, the context position is the number of the line in the document on port source, the context size is the number of lines in this document. It is a dynamic error () if a dynamic XPath error occurred while applying sort-key to a line. It is a dynamic error () if the result of applying sort-key to a given line results in a sequence with more than one item. The sort-key is used to obtain a sort key for each of the lines in the document appearing on source. The context item is the line as an instance of xs:string, the context position is the number of the line in the document on port source, the context size is the number of lines in this document. It is a dynamic error () if a dynamic XPath error occurred while applying sort-key to a line. It is a dynamic error () if the result of applying sort-key to a given line results in a sequence with more than one item.

          • The order option defines whether the lines are processed in ascending or descending order. Its value must be one of ascending or descending. The default is ascending.The order option defines whether the lines are processed in ascending or descending order. Its value must be one of ascending or descending. The default is ascending.

          • The case-order option defines whether upper-case letters are to be collated before or after lower-case letters. Its value must be one of upper-first or lower-first. The default is language-dependent.The case-order option defines whether upper-case letters are to be collated before or after lower-case letters. Its value must be one of upper-first or lower-first. The default is language-dependent.

          • The lang option defines the language whose collating conventions are to be used. The xs:language data type represents natural language identifiers as defined by [] (currently represented by [] and [] or its successor(s).) The default depends on the processing environment. Its value must be a valid language code (e.g. en-EN). The lang option defines the language whose collating conventions are to be used. The xs:language data type represents natural language identifiers as defined by [] (currently represented by [] and [] or its successor(s).) The default depends on the processing environment. Its value must be a valid language code (e.g. en-EN).

          • The collation option identifies how strings are to be compared with each other. Its value must be a valid collation URI. The only collation XProc processors must support is the Unicode Codepoint Collation . This is also its default. Support for other collations is implementation-defined.The collation option identifies how strings are to be compared with each other. Its value must be a valid collation URI. The only collation XProc processors must support is the Unicode Codepoint Collation . This is also its default. Support for other collations is implementation-defined.

          • If the stable option is set to false this indicates that there is no requirement to retain the original order of items that have equal values for all the sort keys.If the stable option is set to false this indicates that there is no requirement to retain the original order of items that have equal values for all the sort keys.

          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 (&#10;), 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 (&#10;).

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

          Document properties

          All document properties are preserved.

          Erratum, April 2024

          The URI for the Unicode Codepoint Collation has been corrected to an http: URI rather than an https: one. The URI is an identifier and the correct identifier uses an http: URI. Implementations are encouraged to recognized collation URIs that begin with “https://www.w3.org/” and treat them as if they began “http://www.w3.org/”, with a warning, if practical.

          2.37. 2.38. p:text-tail

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

          <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:The p:text-tail step returns on its result port lines from the text document that appears on its source port:

          • If the count option is positive, the p:text-tail step returns the last count linesIf the count option is positive, the p:text-tail step returns the last count lines

          • If the count option is zero, the p:text-tail step returns all linesIf the count option is zero, the p:text-tail step returns all lines

          • If the count option is negative, the p:text-tail step returns all lines except the last count linesIf the count option is negative, the p:text-tail step returns all lines except the last count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.38. 2.39. p:unarchive

          The p:unarchive step outputs on its result port specific entries in an archive (for instance from a zip file).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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          exclude-filterRegularExpression()
          formatxs:QName?()
          include-filterRegularExpression()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0085It is a dynamic error if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0147It is a dynamic error if a specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the option is not a valid URI according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

          <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 format of the archive is determined as follows:

            • If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.

            • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format. If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format.

            • It is a dynamic error () if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.It is a dynamic error () 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 unarchiving. The semantics of the keys and the allowed values for these keys are implementation-defined.It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.The parameters option can be used to supply parameters to control the unarchiving. The semantics of the keys and the allowed values for these keys are implementation-defined.It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          • If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if a specified value is not a valid XPath regular expression.If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if a specified value is not a valid XPath regular expression.

            If neither the include-filter option nor the exclude-filter option is specified, the p:unarchive step outputs on its result port all entries in the archive.If neither the include-filter option nor the exclude-filter option is specified, the p:unarchive step outputs on its result port all entries in the archive.

            If the include-filter option or the exclude-filter option is specified, the p:archive step outputs on the result port the entries from the archive that conform to the following rules:If the include-filter option or the exclude-filter option is specified, the p:archive step outputs on the result port the entries from the archive that conform to the following rules:

            • If any include-filter pattern matches an archive entry's name, the entry is included in the output.If any include-filter pattern matches an archive entry's name, the entry is included in the output.

            • If any exclude-filter pattern matches an archive entry's name, the entry is excluded in the output.If any exclude-filter pattern matches an archive 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.

            • Names of entries in archives are always relative names. For instance, the name of a file called xyz.xml in a specs subdirectory in an archive is called in full specs/xyz.xml (and not /specs/xyz.xml).

            As a result: an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.As a result: an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.

            The regular expressions specified in the include-filter and exclude-filter options will be matched against the path of the entry in the archive. The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).The regular expressions specified in the include-filter and exclude-filter options will be matched against the path of the entry in the archive. The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • The relative-to option, when present, is used in creating the base URI of the unarchived documents. 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).The relative-to option, when present, is used in creating the base URI of the unarchived documents. 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).

          • The override-content-types option can be used to partially override the content-type determination mechanism, as described in .The override-content-types option can be used to partially override the content-type determination mechanism, as described in .

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

          • If the relative-to option is present: Function p:urify() is called with the value of this option as second parameter ($basedir) and with the relative path of this document as it was in the archive as first parameterIf the relative-to option is present: Function p:urify() is called with the value of this option as second parameter ($basedir) and with the relative path of this document as it was in the archive as first parameter

          • If the relative-to option is not present: Function p:urify()is called with the value of the base URI of the archive appended with a “/” as second parameter ($baseDir) and the relative path of this document as it was in the archive as first parameterIf the relative-to option is not present: Function p:urify()is called with the value of the base URI of the archive appended with a “/” as second parameter ($baseDir) and the relative path of this document as it was in the archive as first parameter

          It is a dynamic error () 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 () if the option is not a valid URI according to [].It is a dynamic error () 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 () if the option is not a valid URI according to [].

          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:

          • With the relative-to option set to file:///x/y/z: file:///x/y/z/specs/xyz.xmlWith the relative-to option set to file:///x/y/z: file:///x/y/z/specs/xyz.xml

          • Without a relative-to option set: file:///a/b/c.zip/specs/xyz.xmlWithout a relative-to option set: file:///a/b/c.zip/specs/xyz.xml

          Document properties

          No document properties are preserved. The base-uri property of each unarchived document is reflective of the base URI of the document.

          2.39. 2.40. p:uncompress

          The p:uncompress step expects on its source port a compressed document. It outputs an uncompressed version of this on its result port.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          content-typexs:string'application/octet-stream'
          formatxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0201It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the compression format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

          <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 compression format of the document appearing on the source port is determined as follows:

          • If the format option is specified, this determines the compression format. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed.If the format option is specified, this determines the compression format. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed.

          • If no format option is specified or its value is the empty sequence, the compression format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the compression format. Implementations should recognize archives in [] format. If no format option is specified or its value is the empty sequence, the compression format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the compression format. Implementations should recognize archives in [] format.

          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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.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 () 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:

          1. If the content-type option is specified, the uncompressed document must be interpreted according to that content-type. It is a dynamic error () 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 () if the p:uncompress step cannot perform the requested content-type cast. If the content-type option is specified, the uncompressed document must be interpreted according to that content-type. It is a dynamic error () 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 () if the p:uncompress step cannot perform the requested content-type cast.

          2. In the absence of an explicit type, the content will be interpreted as content type application/octet-stream.

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly.

          2.40. 2.41. p:unwrap

          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="text xml html"/>     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than the document node or element nodes.
          Declaration

          <p:declare-steptype="p:unwrap">
               <p:inputport="source"content-types="xml html"/>
               <p:outputport="result"content-types="text xml html"/>
               <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 () if that pattern matches anything other than the document node or element nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.

          Note

          The matching applies to the entire document, not just the “top-most” matches. A pattern of the form h:div will replace allh:div elements, not just the top-most ones.

          This step produces a single document. Special cases:

          • If the document element is unwrapped, the result might not be well-formed XML.

            For instance unwrapping the root element of <!-- COMMENT --><root-element/> will result in a document node with a single comment node child, which is not well-formed.

          • If a document consisting of only an empty root element is unwrapped, the result will be a document node without children. The result document’s content type will not change.

          • If a document consisting of a root element containing only text is unwrapped, the result will be a document node with a single text node child. The result document’s content type will become “text/plain”.

          As specified in the core language specification: if the content type changes, the serialization document property, if present, will be removed.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.41. 2.42. p:uuid

          The p:uuid step generates a [] and injects it into the source document.The p:uuid step generates a [] 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          parametersmap(xs:QName, item()*)?()
          versionxs:integer?()
          Errors
          Error codeDescription
          err:C0060It is a dynamic error if the processor does not support the specified version of the UUID algorithm.
          Implementation details
          ImplementationDescription
          DefinedIf the version is not specified, the version of UUID computed is implementation-defined.
          DefinedSupport for other versions of UUID is implementation-defined.
          DefinedThe names and values of parameters to p:uuid are implementation-defined.
          Declaration

          <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:optionname="parameters"as="map(xs:QName, item()*)?"/>    
          </p:declare-step>

          The value of the match option must be an XSLTSelectionPattern. The value of the version option must be an integer.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 () 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.If the version is specified, that version of UUID must be computed. It is a dynamic error () 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, is implementation-defined. Some UUID schemes require additional parameters which may be provided in the parameters option. and the mechanismThe names and values of byparameters whichto thep:uuid necessary inputs are made available for computing other versions, isare implementation-defined.Implementations must support version 4 UUIDs. Support for other versions of UUID, is implementation-defined. Some UUID schemes require additional parameters which may be provided in the parameters option. and the mechanismThe names and values of byparameters whichto thep:uuid necessary inputs are made available for computing other versions, isare 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.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 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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.42. 2.43. p:wrap-sequence

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeDefault valueRequired
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Declaration

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

          Document properties

          No document properties are preserved. The document produced has no base-uri property.

          2.43. 2.44. p:wrap

          The p:wrap step wraps matching nodes in the source document with a new parent element.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than document, element, text, processing instruction, and comment nodes.
          Declaration

          <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 () if the pattern matches anything other than document, element, text, processing instruction, and comment nodes. The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.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. 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.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.

          Document properties

          All document properties are preserved.

          2.44. 2.45. p:www-form-urldecode

          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>

          Summary

          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeRequired
          valuexs:string✔ 
          Errors
          Error codeDescription
          err:C0037It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.
          Declaration

          <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. 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 () if the value provided is not a properly x-www-form-urlencoded value. It is a dynamic error () 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.

          Document properties

          The resulting JSON document has no properties apart from content-type. In particular, it has no base-uri.

          2.45. 2.46. p:www-form-urlencode

          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:anyAtomicType+)"/></p:declare-step>

          Summary

          Output portPrimarySequenceContent types
          result✔  text/plain 
          Option nameTypeRequired
          parametersmap(xs:string,xs:anyAtomicType+)✔ 
          Declaration

          <p:declare-steptype="p:www-form-urlencode">
               <p:outputport="result"content-types="text/plain"/>
               <p:optionname="parameters"required="true"as="map(xs:string,xs:anyAtomicType+)"/>
          </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. 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.If more than one value is associated with a given key in parameters option, a name/value pair is created for each value.

          Document properties

          The resulting text document has no properties apart from content-type. In particular, it has no base-uri.

          2.46. 2.47. p:xinclude

          The p:xinclude step applies [] processing to the source document.The p:xinclude step applies [] 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          fixup-xml-basexs:booleanfalse()
          fixup-xml-langxs:booleanfalse()
          Errors
          Error codeDescription
          err:C0029It is a dynamic error if an XInclude error occurs during processing.
          Declaration

          <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 [].The value of the fixup-xml-base option must be a boolean. If it is true, base URI fixup will be performed as per [].

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

          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 () if an XInclude error occurs during processing. It is a dynamic error () if an XInclude error occurs during processing.

          Document properties

          All document properties are preserved.

          2.47. 2.48. p:xquery

          The p:xquery step applies an XQuery query to the sequence of documents provided on the source port.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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          query  text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          parametersmap(xs:QName,item()*)?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0009It is a dynamic error if the specified XQuery version is not available.
          err:C0101It is a dynamic error 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.
          err:C0102It is a dynamic error 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.
          err:C0103It is a dynamic error if any error occurs during XQuery’s static analysis phase.
          err:C0104It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.
          Implementation details
          ImplementationDescription
          DefinedSupport for XQueryX is implementation-defined.
          DefinedIt is implementation-defined which XQuery version(s) is/are supported.
          DefinedThe point in time returned as the current dateTime is implementation-defined.
          DefinedThe implicit timezone is implementation-defined.
          DependentThe set of available documents (those that may be retrieved with a URI) is implementation-dependent.
          DependentThe set of available collections is implementation-dependent.
          Declaration

          <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.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: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 document root element is c:query, the text descendants of this element are considered the query.

            <c:query>
                string
            </c:query>

          • If the document root element is in the XQueryX namespace, the document is treated as an XQueryX-encoded query. Support for XQueryX is implementation-defined.

          • Otherwise the serialization of the document must be treated as the query. The document's serialization property (if present) is used.

          If the step specifies a version, then that version of XQuery must be used to process the transformation. It is a dynamic error () 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.If the step specifies a version, then that version of XQuery must be used to process the transformation. It is a dynamic error () 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.The name/value pairs in option parameters are used to set the query’s external variables.

          It is a dynamic error () 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 () 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 () 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 () 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 () if any error occurs during XQuery’s static analysis phase. It is a dynamic error () if any error occurs during XQuery’s dynamic evaluation phase.It is a dynamic error () if any error occurs during XQuery’s static analysis phase. It is a dynamic error () 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:

          Statically known default collection type

          document()*

          Statically known namespaces:

          Unchanged from the implementation defaults. No namespace declarations in the XProc pipeline are automatically exposed in the static context.

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

          Context item

          The first document that appears on the source port. The first document that appears on the source port.

          Context position

          1

          Context size

          1

          Variable values

          Any parameters passed in the parameters option augment any implementation-defined variable bindings known to the XQuery processor. Any parameters passed in the parameters option augment any implementation-defined variable bindings known to the XQuery processor.

          Function implementations

          The function implementations provided by the XQuery processor.

          Current dateTime

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

          Implicit timezone

          The implicit timezone is implementation-defined.

          Available documents

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

          Available collections

          The set of available collections is implementation-dependent.

          Default collection

          The sequence of documents provided on the source port. The sequence of documents provided on the source port.

          2.47.1. 2.48.1. Example

          The following pipeline applies XInclude processing and schema validation before using XQuery:

          Example 1. A Sample Pipeline Document
          <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>

          Where countp.xq might contain:

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

          2.47.2. 2.48.2. Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the query. If the query does not establish a base URI, the document will not have one.

          2.48. 2.49. p:xslt

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          stylesheet  xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          secondary ✔ any 
          Option nameTypeDefault value
          global-context-itemitem()?()
          initial-modexs:QName?()
          output-base-urixs:anyURI?()
          parametersmap(xs:QName,item()*)?()
          populate-default-collectionxs:boolean?true()
          static-parametersmap(xs:QName,item()*)?()
          template-namexs:QName?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0007It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.
          err:C0008It is a dynamic error if the stylesheet does not support a given mode.
          err:C0038It is a dynamic error if the specified xslt version is not available.
          err:C0039It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.
          err:C0056It is a dynamic error if the stylesheet does not provide a given template.
          err:C0093 It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.
          err:C0094It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.
          err:C0095It is a dynamic error if an error occurred during the transformation.
          err:C0096It is a dynamic error if the transformation is terminated by XSLT message termination.
          err:C0105It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.
          err:C0121It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which XSLT version(s) is/are supported.
          DefinedWhether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher).
          DependentHow XSLT message termination errors are reported to the XProc processor is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          Declaration

          <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 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 () 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.If the step specifies a version, then that version of XSLT must be used to process the transformation. It is a dynamic error () 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 () 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.The XSLT stylesheet provided on the stylesheet port is invoked. It is a dynamic error () 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.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 () if an error occurred during the transformation. It is a dynamic error () 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).It is a dynamic error () if an error occurred during the transformation. It is a dynamic error () 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.

          2.48.1. 2.49.1. Invoking an XSLT 3.0 stylesheet

          The value of global-context-item is used as global context item for the stylesheet invocation. If no value is supplied, the following applies:The value of global-context-item is used as global context item for the stylesheet invocation. If no value is supplied, the following applies:

          • If there is a single document on the source port, this document will become the value of the global-context-item option.If there is a single document on the source port, this document will become the value of the global-context-item option.

          • If there are none or multiple documents on the source port, the global context item is absent.If there are none or multiple documents on the source port, the global context item is absent.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          If no value is supplied for template-name option an “Apply-template invocation” is performed. The documents that appear on source are taken to be the initial match selection. if populate-default-collection is true, they are also the default collection. If a value is supplied for the initial-mode option, this value is used as the initial-mode for the invocation. It is a dynamic error () if the stylesheet does not support a given mode. If no value is supplied, nothing is supplied to the invocation, so the default behaviour defined for XSLT 3.0 could be applied.If no value is supplied for template-name option an “Apply-template invocation” is performed. The documents that appear on source are taken to be the initial match selection. if populate-default-collection is true, they are also the default collection. If a value is supplied for the initial-mode option, this value is used as the initial-mode for the invocation. It is a dynamic error () if the stylesheet does not support a given mode. If no value is supplied, nothing is supplied to the invocation, so the default behaviour defined for XSLT 3.0 could be applied.

          If a value is supplied for option template-name a “Call template invocation” is performed. The documents on port source are taken as the default collection in this case. Option initial-mode is ignored. It is a dynamic error () if the stylesheet does not provide a given template.If a value is supplied for option template-name a “Call template invocation” is performed. The documents on port source are taken as the default collection in this case. Option initial-mode is ignored. It is a dynamic error () if the stylesheet does not provide a given template.

          Independent of the way the stylesheet is invoked, the principal result(s) will appear on output port result while secondary result(s) will appear on output port secondary. The order in which result documents appear on the secondary port is implementation -dependent. Whether the raw results are delivered or a result tree is constructed, depends on the (explicit or implicit) setting for attribute build-tree of in the output-definition for the respective result. If a result tree is constructed, the result will be a text document if it is a single text node wrapped into a document node. Otherwise it will be either an XML document or an HTML document depending on the attribute method on the output-definition for the respective result. If no result tree is constructed, the stylesheet invocation may additionally deliver a sequence of atomic values, maps, or arrays. For each item in this sequence a JSON document will be constructed and appear on the steps output port.Independent of the way the stylesheet is invoked, the principal result(s) will appear on output port result while secondary result(s) will appear on output port secondary. The order in which result documents appear on the secondary port is implementation -dependent. Whether the raw results are delivered or a result tree is constructed, depends on the (explicit or implicit) setting for attribute build-tree of in the output-definition for the respective result. If a result tree is constructed, the result will be a text document if it is a single text node wrapped into a document node. Otherwise it will be either an XML document or an HTML document depending on the attribute method on the output-definition for the respective result. If no result tree is constructed, the stylesheet invocation may additionally deliver a sequence of atomic values, maps, or arrays. For each item in this sequence a JSON document will be constructed and appear on the steps output port.

          Option output-base-uri sets the base output URI per XSLT 3.0 specification. If a final result tree is constructed, this URI is used to resolve a relative URI reference. If no value is supplied for output-base-uri, the base URI of the first document in the source port's sequence is used. If no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].Option output-base-uri sets the base output URI per XSLT 3.0 specification. If a final result tree is constructed, this URI is used to resolve a relative URI reference. If no value is supplied for output-base-uri, the base URI of the first document in the source port's sequence is used. If no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].

          Note

          If no result tree is constructed for one of secondary results, a sequence of documents sharing the same value for attribute href may appear on output port result.If no result tree is constructed for one of secondary results, a sequence of documents sharing the same value for attribute href may appear on output port result.

          2.48.2. 2.49.2. Invoking an XSLT 2.0 stylesheet

          If a sequence of documents is provided on the source port, the first document is used as the initial context node. The whole sequence is also the default collection. If no documents are provided on the source port, the initial context node is undefined and the default collection is empty. It is a dynamic error () if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.If a sequence of documents is provided on the source port, the first document is used as the initial context node. The whole sequence is also the default collection. If no documents are provided on the source port, the initial context node is undefined and the default collection is empty. It is a dynamic error () if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          The value of option global-context-item is ignored if a stylesheet is invoked as per XSLT 2.0. 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 () if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function. It is a dynamic error () if the specified initial mode cannot be applied to the specified stylesheet. It is a dynamic error () if the specified template name cannot be applied to the specified stylesheet. The value of option global-context-item is ignored if a stylesheet is invoked as per XSLT 2.0. 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 () if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function. It is a dynamic error () if the specified initial mode cannot be applied to the specified stylesheet. It is a dynamic error () if the specified template name cannot be applied to the specified stylesheet.

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

          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 no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].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 no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].

          2.48.3. 2.49.3. Invoking an XSLT 1.0 stylesheet

          The document provided for source is used the transformations source tree. It is a dynamic error () if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used. The values supplied for options global-context-item, initial-mode, and template-name are ignored. If XSLT 1.0 is used, an empty sequence of documents must appear on the secondary port. 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.The document provided for source is used the transformations source tree. It is a dynamic error () if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used. The values supplied for options global-context-item, initial-mode, and template-name are ignored. If XSLT 1.0 is used, an empty sequence of documents must appear on the secondary port. 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.

          The key/value pairs supplied in parameters are used to set top-level parameters in the stylesheet. If the value is an atomic value or a node, its string value is supplied to the stylesheet. It is a dynamic error () if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node. The key/value pairs supplied in parameters are used to set top-level parameters in the stylesheet. If the value is an atomic value or a node, its string value is supplied to the stylesheet. It is a dynamic error () if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the tranformation. If the transformation does not establish a base URI, the document will not have one.

          3. Step Errors

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

          A [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space).

          If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

          Dynamic errors raised by steps are divided into two categories: dynamic errors and step errors. The distinction is largely that “step errors” tend to be related to a particular step or small group of steps (e.g., validation error) whereas the “dynamic errors” apply to many more steps (e.g., URI not available). There is also precedent for some of the error codes dating back to XProc 1.0.

          Dynamic Errors
          err:XD0011

          It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          See: Handling of ZIP archives, p:load

          err:XD0023

          It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.

          See: Loading XML data

          err:XD0043

          It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.

          See: Loading XML data

          err:XD0049

          It is a dynamic error if the text value is not a well-formed XML document

          See: Casting from a text media type, Loading XML data

          err:XD0057

          It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          See: Casting from a text media type, Loading JSON data

          err:XD0058

          It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.

          See: Casting from a text media type, Loading JSON data

          err:XD0059

          It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          See: Casting from a text media type, Loading JSON data

          err:XD0060

          It is a dynamic error if the text document can not be converted into the XPath data model

          See: Casting from a text media type, Loading text data

          err:XD0062

          It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.

          See: p:load

          err:XD0064

          It is a dynamic error if the base URI is not both absolute and valid according to .

          See: p:archive, p:archive-manifest, p:load, p:make-absolute-uris, p:set-properties, p:unarchive

          err:XD0070

          It is a dynamic error 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 .

          See: p:set-properties

          err:XD0078

          It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.

          See: Loading HTML data

          err:XD0079

          It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.

          See: Overriding content types, p:cast-content-type, p:http-request, p:http-request, p:load, p:text-join, p:uncompress

          Step Errors
          err:XC0001

          It is a dynamic error if the value of option override-content-type is not a text media type.

          See: p:text-join

          err:XC0003

          It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.

          See: p:http-request

          err:XC0007

          It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0008

          It is a dynamic error if the stylesheet does not support a given mode.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0009

          It is a dynamic error if the specified XQuery version is not available.

          See: p:xquery

          err:XC0013

          It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.

          See: p:rename

          err:XC0014

          It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.

          See: p:namespace-rename

          err:XC0019

          It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.

          See: p:compare

          err:XC0023

          It is a dynamic error if the selection pattern matches a node which is not an element.

          See: p:add-attribute, p:delete, p:insert, p:label-elements, p:make-absolute-uris, p:rename, p:replace, p:set-attributes, p:unwrap, p:wrap

          err:XC0024

          It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.

          See: p:insert

          err:XC0025

          It is a dynamic error 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”.

          See: p:insert

          err:XC0029

          It is a dynamic error if an XInclude error occurs during processing.

          See: p:xinclude

          err:XC0030

          It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          See: p:http-request

          err:XC0036

          It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.

          See: p:hash

          err:XC0037

          It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.

          See: p:www-form-urldecode

          err:XC0038

          It is a dynamic error if the specified xslt version is not available.

          See: p:xslt

          err:XC0039

          It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0050

          It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.

          See: p:store

          err:XC0056

          It is a dynamic error if the stylesheet does not provide a given template.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0058

          It is a dynamic error if the all and relative options are both true.

          See: p:add-xml-base

          err:XC0059

          It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.

          See: p:add-attribute, p:set-attributes

          err:XC0060

          It is a dynamic error if the processor does not support the specified version of the UUID algorithm.

          See: p:uuid

          err:XC0062

          It is a dynamic error if the match option matches a namespace node.

          See: p:delete

          err:XC0069

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

          See: p:set-properties

          err:XC0071

          It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.

          See: p:cast-content-type

          err:XC0072

          It is a dynamic error if the c:data contains content is not a valid base64 string.

          See: Casting from an XML media type

          err:XC0073

          It is a dynamic error if the c:data element does not have a content-type attribute.

          See: Casting from an XML media type

          err:XC0074

          It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.

          See: Casting from an XML media type

          err:XC0076

          It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.

          See: p:compare

          err:XC0077

          It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.

          See: p:compare

          err:XC0078

          It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.

          See: p:http-request

          err:XC0079

          It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          See: p:archive, p:archive-manifest, p:cast-content-type, p:compress, p:unarchive, p:uncompress

          err:XC0080

          It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          See: Handling of ZIP archives

          err:XC0081

          It is a dynamic error if the format of the archive does not match the format as specified in the format option.

          See: p:archive, p:archive-manifest

          err:XC0084

          It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          See: p:archive

          err:XC0085

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

          See: p:archive, p:archive-manifest, p:unarchive

          err:XC0092

          It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          See: p:namespace-rename

          err:XC0093

          It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.

          See: p:xslt

          err:XC0094

          It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0095

          It is a dynamic error if an error occurred during the transformation.

          See: p:xslt

          err:XC0096

          It is a dynamic error if the transformation is terminated by XSLT message termination.

          See: p:xslt

          err:XC0098

          It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.

          See: p:text-sort

          err:XC0099

          It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.

          See: p:text-sort

          err:XC0100

          It is a dynamic error if the document on port manifest does not conform to the given schema.

          See: p:archive, The archive manifest

          err:XC0101

          It is a dynamic error 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.

          See: p:xquery

          err:XC0102

          It is a dynamic error 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.

          See: p:xquery

          err:XC0103

          It is a dynamic error if any error occurs during XQuery’s static analysis phase.

          See: p:xquery

          err:XC0104

          It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.

          See: p:xquery

          err:XC0105

          It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0106

          It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.

          See: p:json-merge

          err:XC0107

          It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.

          See: p:json-merge

          err:XC0108

          It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.

          See: p:namespace-delete

          err:XC0109

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

          See: p:namespace-delete

          err:XC0110

          It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.

          See: p:json-merge

          err:XC0111

          It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.

          See: p:json-join

          err:XC0112

          It is a dynamic error if more than one document appears on the port manifest.

          See: p:archive

          err:XC0118

          It is a dynamic error if an archive manifest is invalid according to the specification.

          See: The archive manifest

          err:XC0119

          It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.

          See: p:json-join

          err:XC0120

          It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.

          See: p:archive-manifest, p:unarchive

          err:XC0121

          It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0122

          It is a dynamic error if the given method is not supported.

          See: p:http-request

          err:XC0123

          It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0124

          It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0125

          It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.

          See: p:http-request

          err:XC0126

          It is a dynamic error if the XPath expression in assert evaluates to false.

          See: p:http-request

          err:XC0127

          It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.

          See: p:http-request

          err:XC0128

          It is a dynamic error if the URI’s scheme is unknown or not supported.

          See: p:http-request

          err:XC0131

          It is a dynamic error if the processor cannot support the requested encoding.

          See: p:http-request

          err:XC0132

          It is a dynamic error if the override content encoding cannot be supported.

          See: p:http-request

          err:XC0133

          It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          See: Construction of a multipart request

          err:XC0146

          It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          See: Overriding content types

          err:XC0147

          It is a dynamic error if the specified value is not a valid XPath regular expression.

          See: Overriding content types, p:text-replace, p:unarchive

          err:XC0150

          It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.

          See: p:split-sequence

          err:XC0201

          It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.

          See: p:uncompress

          err:XC0202

          It is a dynamic error if the compression format cannot be understood, determined and/or processed.

          See: p:compress, p:uncompress

          err:XC0203

          It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          See: Construction of a multipart request

          A. Conformance

          Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

          [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

          [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

          A.1. Implementation-defined features

          The following features are implementation-defined:

          1. The list of formats supported by the p:archive step is implementation-defined. See Section 2.3, “p:archive”.
          2. The list of archive formats that can be modified by p:archive is implementation-defined. See Section 2.3, “p:archive”.
          3. The semantics of any additional attributes, elements and their values are implementation-defined. See Section 2.3, “p:archive”.
          4. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          5. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.3, “p:archive”.
          6. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          7. It is implementation-defined how the step determines the archive's format. See Section 2.3, “p:archive”.
          8. The c:archive root element may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          9. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          10. It is implementation-defined what other compression methods are supported. See Section 2.3.1, “The archive manifest”.
          11. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          12. It is implementation-defined what compression levels are supported. See Section 2.3.1, “The archive manifest”.
          13. The c:entry elements may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          14. The p:archive step may support additional, implementation-defined commands for ZIP files. See Section 2.3.2, “Handling of ZIP archives”.
          15. The actual parameter names supported by p:archive for a particular format are implementation-defined. See Section 2.3.2, “Handling of ZIP archives”.
          16. It is implementation-defined what other formats are supported. See Section 2.4, “p:archive-manifest”.
          17. It is implementation-defined how the step determines the archive's format. See Section 2.4, “p:archive-manifest”.
          18. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.4, “p:archive-manifest”.
          19. Additional information provided for entries in p:archive-manifest is implementation-defined. See Section 2.4, “p:archive-manifest”.
          20. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.5, “p:cast-content-type”.
          21. The precise nature of the conversion from XML to JSON is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          22. Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          23. Casting from an HTML media type to a JSON media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          24. Casting from an HTML media type to any other media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          25. It is implementation-defined whether other result formats are supported. See Section 2.5.3, “Casting from a JSON media type”.
          26. Casting from a JSON media type to an HTML media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          27. Casting from a JSON media type to any other media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          28. The precise way in which text documents are parsed into the XPath data model is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          29. Casting from a text media type to any other media type is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          30. Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          31. Casting from any other media type to any other media type is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          32. Implementations of p:compare must support the deep-equal method; other supported methods are implementation-defined. See Section 2.6, “p:compare”.
          33. 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. See Section 2.6, “p:compare”.
          34. It is implementation-defined what other formats are supported. See Section 2.7, “p:compress”.
          35. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.7, “p:compress”.
          36. It is implementation-defined what other algorithms are supported. See Section 2.12, “p:hash”.
          37. It is implementation-defined which HTTP methods are supported. See Section 2.13, “p:http-request”.
          38. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined. See Section 2.13, “p:http-request”.
          39. Other key value pairs in map “auth” are implementation-defined. See Section 2.13, “p:http-request”.
          40. It is implementation-defined which other key/value pairs in the parameters option are supported. See Section 2.13, “p:http-request”.
          41. The default behaviour in case of a redirect response is implementation-defined. See Section 2.13, “p:http-request”.
          42. It is implementation-defined how a multipart boundary is constructed. See Section 2.13.1, “Construction of a multipart request”.
          43. It is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.16, “p:json-join”.
          44. It is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.17, “p:json-merge”.
          45. In the absence of an explicit type, the content type is implementation-defined See Section 2.19, “p:load”.
          46. Additional XML parameters are implementation-defined. See Section 2.19.1, “Loading XML data”.
          47. Text parameters are implementation-defined. See Section 2.19.2, “Loading text data”.
          48. Additional JSON parameters are implementation-defined. See Section 2.19.3, “Loading JSON data”.
          49. The precise way in which HTML documents are parsed into the XPath data model is implementation-defined. See Section 2.19.4, “Loading HTML data”.
          50. HTML parameters are implementation-defined. See Section 2.19.4, “Loading HTML data”.
          51. How a processor interprets other media types is implementation-defined. See Section 2.19.5, “Loading binary data”.
          52. Parameters for other media types are implementation-defined. See Section 2.19.5, “Loading binary data”.
          53. Support for other collations is implementation-defined. See Section 2.362.37, “p:text-sort”.
          54. It is implementation-defined what other formats are supported. See Section 2.382.39, “p:unarchive”.
          55. It is implementation-defined how the step determines the archive's format. See Section 2.382.39, “p:unarchive”.
          56. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.382.39, “p:unarchive”.
          57. It is implementation-defined what other formats are supported. See Section 2.392.40, “p:uncompress”.
          58. It is implementation-defined how the step determines the compression format. See Section 2.392.40, “p:uncompress”.
          59. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.392.40, “p:uncompress”.
          60. If the version is not specified, the version of UUID computed is implementation-defined. See Section 2.412.42, “p:uuid”.
          61. Support for other versions of UUID, and the mechanism by which the necessary inputs are made available for computing other versions, is implementation-defined. See Section 2.41, “p:uuid”.
          62. Support for other versions of UUID is implementation-defined. See Section 2.42, “p:uuid”.
          63. The names and values of parameters to p:uuid are implementation-defined. See Section 2.42, “p:uuid”.
          64. Support for XQueryX is implementation-defined. See Section 2.472.48, “p:xquery”.
          65. It is implementation-defined which XQuery version(s) is/are supported. See Section 2.48, “p:xquery”.
          66. The point in time returned as the current dateTime is implementation-defined. See Section 2.472.48, “p:xquery”.
          67. The implicit timezone is implementation-defined. See Section 2.472.48, “p:xquery”.
          68. It is implementation-defined which XSLT version(s) is/are supported. See Section 2.482.49, “p:xslt”.
          69. Whether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher). See Section 2.482.49, “p:xslt”.

          A.2. Implementation-dependent features

          The following features are implementation-dependent:

          1. 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. See Section 2.20, “p:make-absolute-uris”.
          2. The set of available documents (those that may be retrieved with a URI) is implementation-dependent. See Section 2.472.48, “p:xquery”.
          3. The set of available collections is implementation-dependent. See Section 2.472.48, “p:xquery”.
          4. How XSLT message termination errors are reported to the XProc processor is implementation-dependent. See Section 2.482.49, “p:xslt”.
          5. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.
          6. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.

          B. References

          B.1. Normative References

          [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

          [W3C XML Schema: Part 2] XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, editors. World Wide Web Consortium, 28 October 2004.

          [XPath 3.1] XML Path Language (XPath) 3.1. Jonathan Robie, Michael Dyck, Josh Spiegel, editors. W3C Recommendation. 21 March 2017.

          [XPath and XQuery Functions and Operators 3.1] XPath and XQuery Functions and Operators 3.1. Michael Kay, editor. W3C Recommendation. 21 March 2017

          [XSLT 3.0] XSL Transformations (XSLT) Version 3.0. Michael Kay, editor. W3C Recommendation. 8 June 2017.

          [XInclude] XML Inclusions (XInclude) Version 1.0 (Second Edition). Jonathan Marsh, David Orchard, and Daniel Veillard, editors. W3C Recommendation. 15 November 2006.

          [RFC 1321] RFC 1321: The MD5 Message-Digest Algorithm. R. Rivest. Network Working Group, IETF, April 1992.

          [RFC 2046] RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein, editors. Internet Engineering Task Force. November, 1996.

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

          [RFC 2617] RFC 2617: HTTP Authentication: Basic and Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. June, 1999 .

          [RFC 3986] RFC 3986: Uniform Resource Identifier (URI): General Syntax. T. Berners-Lee, R. Fielding, and L. Masinter, editors. Internet Engineering Task Force. January, 2005.

          [RFC 4646] RFC 4646: Tags for Identifying Languages. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [RFC 4647] RFC 4647: Matching of Language Tags. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [BCP 47] Best Current Practices 47. Concatenation of RFC 4646: Tags for Identifying Languages, ed. A. Phillips and M. Davis, September 2006, http://www.ietf.org/rfc/bcp/bcp47.txt, and RFC 4647: Matching of Language Tags, ed. A Phillips and M. Davis, September 2006, http://www.rfc-editor.org/rfc/bcp/bcp47.txt. Internet Engineering Task Force (IETF). September, 2006.

          [CRC32] “32-Bit Cyclic Redundancy Codes for Internet Applications”, The International Conference on Dependable Systems and Networks: 459. 10.1109/DSN.2002.1028931. P. Koopman. June 2002.

          C. Glossary

          dynamic error

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

          implementation-defined

          An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

          implementation-dependent

          An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

          D. Ancillary files

          This specification includes by reference a number of ancillary files.

          steps.xpl

          An XProc step library for the declared steps.

          E. Credits

          This document is derived from XProc: An XML Pipeline Language published by the W3C. It was developed by the XML Processing Model Working Group and edited by Norman Walsh, Alex Miłowski, and Henry Thompson.

          The editors of this specification extend their gratitude to everyone who contributed to this document and all of the versions that came before it.

          F. Change Log

          This appendix catalogs non-editorial changes made after the August 2020 “last call” draft:

          1. Allow the output of the p:insert step to be text. (issue 583.)

          2. Clarified that the manifest has precedence in the p:archive step. (issue 462.)

          3. Changed the type of several options from xs:token to xs:string (issue 490.)

          4. Changed the type of the parameters option from map(xs:string,xs:untypedAtomic+) to map(xs:string,xs:anyAtomicType+). (issue .) Changed the type of the parameters option from map(xs:string,xs:untypedAtomic+) to map(xs:string,xs:anyAtomicType+). (issue .)

          These are the non-editorial changes made after the February 2020 “last call” draft:

          1. For p:cast-content-type the expected result type for casting a c:param-set document to “application/json” was specified as map(xs:QName, xs:string). (2020-03-15)

          2. In p:http-request, instead of using all document properties (with a few explicit exceptions) as headers, only document properties in the http://www.w3.org/ns/xproc-http namespace will be used. (2020-03-18)

          3. Section 2.3.1, “The archive manifest”: An attribute c:entry/@content-type was added to the archive manifest, to be filled by the p:archive-manifest step. (2020-03-20)

          4. A static-parameters was added to . (2020-03-23)A static-parameters was added to . (2020-03-23)

          5. The override-content-types option was added to and . (2020-03-30)The override-content-types option was added to and . (2020-03-30)

          6. Clarified the regular expression matching for p:text-replace and p:unarchive. Added an error code for invalid regular expressions. (2020-04-02)

          7. Replaced errors XC0070 and XC0130 with XD0079. (2020-04-09)

          8. Changed signature of p:split-sequence so that any document can appear one port source. (2020-05-22)

          9. Change the behavior of the global-context-item option of . (2020-06-10)Change the behavior of the global-context-item option of . (2020-06-10)

          10. Clarified which steps may produce PSVI annotations. (2020-06-09)

          11. Clarified the behaviour in p:archive: A missing resource referenced by c:archive/c:entry/@href is only an error for command = 'create'. (2020-06-11)

          12. Option populate-default-collection is added to the signature of . (2020-06-20)Option populate-default-collection is added to the signature of . (2020-06-20)

          13. Clarified how the default content-type header of is constructed if a single document appears on source port. (2020-06-20)Clarified how the default content-type header of is constructed if a single document appears on source port. (2020-06-20)

          14. Added error (XD0079) to p:http-request and p:load for invalid content-types. (2020-06-23)

          15. Changed signature of the result port of to sequence="false" and adapted the prose accordingly. (2020-06-24)Changed signature of the result port of to sequence="false" and adapted the prose accordingly. (2020-06-24)

          \ No newline at end of file +

          XProc 3.0+: Standard Step Library

          Draft Community Group Report

          Editor's Draft at (build 46)
          Specification:
          Latest editor’s draft:
          https://spec.xproc.org/3.0/master/head/steps/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Errata:
          Changes:
          https://spec.xproc.org/3.0/steps/errata.htmlDiff against the 3.0 specification
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML, PDF (A4),and HTML with automatic change markup courtesy of PDF (US Letter)DeltaXML.

          Copyright © 2018, 2019, 2020, 2021, 2022 the Contributors to the XProc 3.0+: Standard Step Library specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the standard step vocabulary of XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

          If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

          Note

          This draft is the “editor’s working draft” and includes changes made after the XProc 3.0 standard step specification was released.

          This document is derived from XProc: An XML Pipeline Language published by the W3C.

          1. Introduction

          This specification describes the standard, required atomic XProc steps. A machine-readable description of these steps may be found in steps.xpl.

          Many atomic steps are available for [XProc 3.0]. They are described in several specifications. This specification describes the general background common to all steps. A conformant processor must implement all of the steps in this specification. Additional steps may also be implemented.

          The types given for options should be understood as follows:

          • Types in the XML Schema namespace, identified as QNames with the xs: prefix, as per the XML Schema specification with one exception. Anywhere an xs:QName is specified, an EQName is allowed.

          • XPathExpression: As a string per [W3C XML Schema: Part 2], including whitespace normalization, and the further requirement to be a conformant Expression per [XPath 3.1].

          • XSLTSelectionPattern: As a string per [XSLT 3.0] conforming to an XSLT selection pattern.

          • XPathSequenceType: An XPath sequence type.

          • ContentType: A media type as defined in [RFC 2046].

          • ContentTypes: As a whitespace separated list of media types as defined in [RFC 2046].

          Option values are often expressed using the shortcut syntax. In these cases, the option shortcuts are generally treated as value templates. However, for options of type map() or array(), an expression is required (there is no non-expression string which can ever be a legal value for a map or array). Given that every value entered this way will have to be a value template, and consequently every curly brace contained within the expression will have to be escaped, values of type map or array are defined to be expressions directly.

          Some aspects of documents are generally unchanged by steps:

          • When a step in this library produces an output document, the base URI of the output is the base URI of the step's primary input document unless the step's process explicitly sets an xml:base attribute or the step's description explicitly states how the base URI is constructed.

          • Steps are responsible for describing how document properties are transformed as documents flow through them. Many steps claim that the specified properties are preserved. Generally, it is the responsibility of the pipeline author to determine when this is inapropriate and take corrective action. However, it is the responsibility of the pipeline processor to assure that the content-type property is correct. If a step transforms a document in a manner that is inconsistent with the content-type property (accepting an XML document on the source port but producing a text document on the result, for example), the processor must assure that the content-type property is appropriate. If a step changes the content-type in this way, it must also remove the serialization property

          Also, in this specification, several steps use this element for result information:

          <c:result>
              string
          </c:result>

          When a step uses an XPath to compute an option value, the XPath context is as defined in [XProc 3.0].

          When a step specifies a particular version of a technology, implementations must implement that version or a subsequent version that is backwards compatible with that version. At user-option, they may implement other non-backwards compatible versions.

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

          As described in PSVIs in XProc in XProc 3.0: An XML Pipeline Language, steps may not produce PSVI output unless that behavior is explicitly described. In this specification, the steps that may produce PSVI output are the “identity” steps: p:identity, p:store, and p:split-sequence (which must preserve PSVI properties that appear on their inputs). In addition, the p:xslt and p:xquery steps may return documents with PSVI annotations.

          2. The required steps

          2. Step library

          A conformant processor must support all of these steps.

          2.1. p:add-attribute

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attribute-namexs:QName ✔ 
          attribute-valuexs:string ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the selection pattern matches a node which is not an element.
          err:C0059It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

          <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 () if the selection pattern matches a node which is not an element.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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. 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.

          Note

          If multiple attributes need to be set on the same element(s), the p:set-attributes step can be used to set them all at once.

          This step cannot be used to add namespace declarations. It is a dynamic error () if the QName value in the attribute-name option is “xmlns” or 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.This step cannot be used to add namespace declarations. It is a dynamic error () if the QName value in the attribute-name option is “xmlns” or 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.

          Document properties

          All document properties are preserved.

          2.2. p:add-xml-base

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          allxs:booleanfalse()
          relativexs:booleantrue()
          Errors
          Error codeDescription
          err:C0058It is a dynamic error if the all and relative options are both true.
          Declaration

          <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 all option must be a boolean.

          The value of the relative option must be a boolean.The value of the relative option must be a boolean.

          It is a dynamic error () if the all and relative options are bothtrue.It is a dynamic error () if the all and relative options are bothtrue.

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

          • For every element that is a child of the document node: force the element to have an xml:base attribute with the document's [base URI] property's value as its value.

          • For other elements:

            • If the all option has the value true, force the element to have an xml:base attribute with the element's [base URI] value as its value.If the all option has the value true, force the element to have an xml:base attribute with the element's [base URI] value as its value.

            • If the element's [base URI] is different from the its parent's [base URI], force the element to have an xml:base attribute with the following value: if the value of the relative option is true, a string which, when resolved against the parent's [base URI], will give the element's [base URI], otherwise the element's [base URI].If the element's [base URI] is different from the its parent's [base URI], force the element to have an xml:base attribute with the following value: if the value of the relative option is true, a string which, when resolved against the parent's [base URI], will give the element's [base URI], otherwise the element's [base URI].

            • Otherwise, if there is an xml:base attribute present, remove it.

          Document properties

          All document properties are preserved.

          2.3. p:archive

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

          Summary

          Input portPrimarySequenceContent typesDefault binding
          source✔ ✔ any 
          manifest ✔ xml p:empty
          archive ✔ any p:empty
          Output portPrimarySequenceContent typesDefault binding
          result✔  any 
          report  application/xml 
          Option nameTypeDefault value
          formatxs:QName'zip'
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0080It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0084It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0100It is a dynamic error if the document on port manifest does not conform to the given schema.
          err:C0112It is a dynamic error if more than one document appears on the port manifest.
          err:D0011It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedThe list of formats supported by the p:archive step is implementation-defined.
          DefinedThe list of archive formats that can be modified by p:archive is implementation-defined.
          DefinedThe semantics of any additional attributes, elements and their values are implementation-defined.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe c:archive root element may contain additional implementation-defined attributes.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what other compression methods are supported.
          DefinedThe default compression method is implementation-defined.
          DefinedIt is implementation-defined what compression levels are supported.
          DefinedThe c:entry elements may contain additional implementation-defined attributes.
          DefinedThe p:archive step may support additional, implementation-defined commands for ZIP files.
          DefinedThe actual parameter names supported by p:archive for a particular format are implementation-defined.
          Declaration

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

          source

          The (primary) source port is used to provide documents to be archived (for instance constructed by other steps). How and which of these documents are processed is governed by the document(s) appearing on the other input ports and the combination of options and parameters. See below for details. It is a dynamic error () if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.The (primary) source port is used to provide documents to be archived (for instance constructed by other steps). How and which of these documents are processed is governed by the document(s) appearing on the other input ports and the combination of options and parameters. See below for details. It is a dynamic error () if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          manifest

          The manifest port can receive a manifest document that tells the step how to construct the archive. If no manifest document is provided on this port, a default manifest is constructed automatically. See . It is a dynamic error () if the document on port manifest does not conform to the given schema. The manifest port can receive a manifest document that tells the step how to construct the archive. If no manifest document is provided on this port, a default manifest is constructed automatically. See . It is a dynamic error () if the document on port manifest does not conform to the given schema.

          It is a dynamic error () if more than one document appears on the port manifest.It is a dynamic error () if more than one document appears on the port manifest.

          The default input for this port is the empty sequence.

          archive

          The archive port is used to provide the step with existing archive(s) for operations like update, freshen or merge. Handling of ZIP files supports modifying archives appearing on the archive port (). The list of archive formats that can be modified by p:archive is implementation-defined. For instance an implementation that supports archive merging may accept more than one document on the archive port.The archive port is used to provide the step with existing archive(s) for operations like update, freshen or merge. Handling of ZIP files supports modifying archives appearing on the archive port (). The list of archive formats that can be modified by p:archive is implementation-defined. For instance an implementation that supports archive merging may accept more than one document on the archive port.

          The default input for this port is the empty sequence.

          The p:archive step has the following output ports:

          result

          The (primary) result port will output the resulting archive.The (primary) result port will output the resulting archive.

          report

          The report port will output a report about the archiving operation. This will be the same as the manifest (as provided on the manifest port or automatically created if there was no manifest provided), optionally amended with additional attributes and/or elements. The semantics of any additional attributes, elements and their values are implementation-defined.The report port will output a report about the archiving operation. This will be the same as the manifest (as provided on the manifest port or automatically created if there was no manifest provided), optionally amended with additional attributes and/or elements. The semantics of any additional attributes, elements and their values are implementation-defined.

          The p:archive step has the following options:

          format

          The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.

          parameters

          The parameters option can be used to supply parameters to control the archiving. The semantics of the keys and the allowed values for these keysSeveral parameters are defined for processing , but implementations are free to use additional parameters and to use parameters for controlling how other archive formats are processed. It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.The parameters option can be used to supply parameters to control the archiving. The semantics of the keys and the allowed values for these keysSeveral parameters are defined for processing , but implementations are free to use additional parameters and to use parameters for controlling how other archive formats are processed. It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          relative-to

          The relative-to option is used in creating a manifest when no manifest is provided on the manifest port. If a manifest is present this option is not used. If the option’s value is a relative URI, 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 () if the base URI is not both absolute and valid according to [].The relative-to option is used in creating a manifest when no manifest is provided on the manifest port. If a manifest is present this option is not used. If the option’s value is a relative URI, 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 () if the base URI is not both absolute and valid according to [].

          The format of the archive is determined as follows:

          • If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option.If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the archive port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format. If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the archive port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format.

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

          2.3.1. The archive manifest

          An archive manifest specifies which documents will be considered in processing the archive. Every entry in the archive must have a corresponding entry in the manifest; if no such entry is provided, one will be constructed automatically (see below). If manifest entries are provided for documents that are not in the archive, how those are processed depends on the archive type and the parameters passed to the step.

          A manifest is represented by a c:archive root element:

          <c:archive>
              (c:entry* &
               anyNonXProcElement*)
          </c:archive>

          The c:archive root element may contain additional implementation-defined attributes.

          All entries in the archive must be present as c:entry child elements:

          <c:entry
            name = string
            href = anyURI
            comment? = string
            method? = string
            level? = string
            content-type? = ContentType>
              anyElement*
          </c:entry>

          • The name attribute specifies the name of the entry in the archive.

          • The href attribute must be a valid URI according to [RFC 3986]. If its value is relative, it is made absolute against the base URI of the manifest. There are two possible cases:

            • If the (absolute) href value is exactly the same as the base URI of a document appearing on the source port, that document is associated with this entry. If this entry is to be added to the archive, the associated document will be used. (The serialization document property can be used to provide serialization properties.) If the (absolute) href value is exactly the same as the base URI of a document appearing on the source port, that document is associated with this entry. If this entry is to be added to the archive, the associated document will be used. (The serialization document property can be used to provide serialization properties.)

            • If no document on the source port has a base URI that is exactly the same as the (absolute) href value, the document at the specified URI is associated with this entry. These documents are stored in the archive “as is”; they must not be parsed and re-serialized.If no document on the source port has a base URI that is exactly the same as the (absolute) href value, the document at the specified URI is associated with this entry. These documents are stored in the archive “as is”; they must not be parsed and re-serialized.

          • The method attribute specifies how the entry should be compressed. The default compression method is implementation-defined. Implementations must support no compression, specified with the value none. It is implementation-defined what other compression methods are supported.

          • The level attribute specifies the level of compression. The default compression method is implementation-defined. It is implementation-defined what compression levels are supported.

          • The content-type attribute specifies the content-type of the entry as detected by the processor. It will be set by p:archive-manifest in constructing the manifest. It will be ignored by p:archive.

          The p:archive step should strive to retain the order of the c:entry elements when constructing the archive. For instance, an e-book in EPUB format has a non-compressed entry that must be first in the archive. It should be possible to construct such an archive using p:archive.

          The c:entry elements may contain additional implementation-defined attributes.

          If no manifest entry is provided for a document appearing on the source port, the step will create a manifest entry for the document. (If no document arrives on the manifest port at all, a complete manifest document will be created.)If no manifest entry is provided for a document appearing on the source port, the step will create a manifest entry for the document. (If no document arrives on the manifest port at all, a complete manifest document will be created.)

          In a constructed manifest entry:

          • The entry’s href value is the base URI of the document.

          • The entry’s name value is derived from the base URI of the document and the relative-to option.The entry’s name value is derived from the base URI of the document and the relative-to option.

            • First, the value of the relative-to option is made absolute. If the initial substring of the base URI is exactly the same as the resulting absolute value, then the name is the portion of the base URI that follows that initial substring. First, the value of the relative-to option is made absolute. If the initial substring of the base URI is exactly the same as the resulting absolute value, then the name is the portion of the base URI that follows that initial substring.

            • If there is no relative-to option or if its value is not the initial substring of the base URI of the document, the name is the path portion of the URI (per []). If the path portion begins with an initial slash, that slash is removed. If there is no relative-to option or if its value is not the initial substring of the base URI of the document, the name is the path portion of the URI (per []). If the path portion begins with an initial slash, that slash is removed.

          It is a dynamic error () if an archive manifest is invalid according to the specification.It is a dynamic error () if an archive manifest is invalid according to the specification.

          2.3.2. Handling of ZIP archives

          The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip. The format of the archive can be specified using the format option. Implementations must support the [] format, specified with the value zip.

          When ZIP archives are processed, every name in the manifest must be a relative path without a leading slash.

          The parameters option can be used to supply parameters to control the archiving. For the zip format, the following parameters must be supported:The parameters option can be used to supply parameters to control the archiving. For the zip format, the following parameters must be supported:

          command

          Specifies what operation to perform. If not specified, its default value is update. Implementations must support the values update, create, freshen, and delete. The p:archive step may support additional, implementation-defined commands for ZIP files. Unless otherwise specified, exactly zero or one ZIP archive can appear on the archive port for the commands described below. If no archive appears, a new archive will be created. Specifies what operation to perform. If not specified, its default value is update. Implementations must support the values update, create, freshen, and delete. The p:archive step may support additional, implementation-defined commands for ZIP files. Unless otherwise specified, exactly zero or one ZIP archive can appear on the archive port for the commands described below. If no archive appears, a new archive will be created.

          update

          When the command parameter is set to update, the ZIP archive will be updated:

          1. For every entry in the ZIP file:

            • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is updated with the document identified by the c:entry in the manifest.

            • If the manifest does not contain a matching c:entry, the ZIP entry name is resolved against the base URI of the ZIP file.

              • If a document exists at that URI and either has no timestamp or has a timestamp more than the timestamp in the ZIP file, the entry in the ZIP file will be updated with the document at the resolved URI.

              • If no document exists at that URI, or the document cannot be accessed, or the document has a timestamp and the timestamp in the ZIP archive is more recent than the timestamp of the document, then the ZIP entry is unchanged.

          2. For every c:entry in the manifest that does not have a matching entry in the ZIP file, the ZIP file will be updated by adding the document identified by the c:entry to the ZIP file.

          create

          When the command parameter is set to create, the ZIP archive will be created. Creating a ZIP archive behaves exactly like update except that any timestamps are ignored; every ZIP entry will be updated or created if there is a or matching document for it. The document must be obtained by dereferencing the URI in href. It is a dynamic error () if the resource referenced by the href option does not exist, cannot be accessed or is not a file.When the command parameter is set to create, the ZIP archive will be created. Creating a ZIP archive behaves exactly like update except that any timestamps are ignored; every ZIP entry will be updated or created if there is a or matching document for it. The document must be obtained by dereferencing the URI in href. It is a dynamic error () if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          freshen

          When the command parameter is set to freshen, existing files in the ZIP archive may be updated, but no new files will be added. Freshing a ZIP archive behaves exactly like update except that only entries that already exist in the ZIP archive are considered.

          delete

          When the command parameter is set to delete, exactly one document in ZIP format must appear on the archive port. For every entry in the ZIP file:When the command parameter is set to delete, exactly one document in ZIP format must appear on the archive port. For every entry in the ZIP file:

          • If the manifest contains a c:entry with a matching name, the entry in the ZIP file is removed from the ZIP archive.

          If the manifest contains c:entry elements which do not have a matching entry in the ZIP archive, they are simply ignored.

          level

          Specifies the default compression level for files added to or updated in the archive. If the level attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “smallest”, “fastest”, “default”, “huffman”, and “none”.

          method

          Specifies the default compression method for files added to or updated in the archive. If the method attribute is specified on a c:entry, its value takes precedence for that entry. Values that must be supported for ZIP files are: “none” and “deflated”.

          It is a dynamic error () if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.It is a dynamic error () if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          Implementations of other archive formats should use the same parameter names if applicable. The value spaces for these parameters may be format-specific though. The actual parameter names supported by p:archive for a particular format are implementation-defined.

          Document properties

          No document properties are preserved. The archive has no base-uri.

          2.4. p:archive-manifest

          The p:archive-manifest creates an XML manifest file describing the contents of the archive appearing on its source port.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          formatxs:QName?()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0081It is a dynamic error if the format of the archive does not match the format as specified in the format option.
          err:C0085It is a dynamic error if the format of the archive cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0146It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedAdditional information provided for entries in p:archive-manifest is implementation-defined.
          Declaration

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

          • If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option. If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.It is a dynamic error () if the format of the archive does not match the format as specified in the format option.

          • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format. If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format.

          It is a dynamic error () if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.It is a dynamic error () 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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.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 () 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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

          The generated manifest has the format as described in . Implementations must supply an 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 . It is a dynamic error () 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 generated manifest has the format as described in . Implementations must supply an 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 . It is a dynamic error () 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.

          2.4.1. Overriding content types

          The override-content-types option can be used to partially override the content-type determination mechanism. If present, it must be an array of arrays, where the inner arrays consist of exactly two strings: The override-content-types option can be used to partially override the content-type determination mechanism. If present, it must be an array of arrays, where the inner arrays consist of exactly two strings:

          • The first member in an inner array must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if the specified value is not a valid XPath regular expression.The first member in an inner array must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if the specified value is not a valid XPath regular expression.

          • The second member in an inner array must be a valid a MIME content-type. It is a dynamic error () if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.The second member in an inner array must be a valid a MIME content-type. It is a dynamic error () 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 () if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.It is a dynamic error () if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          Determining an archive entry's content-type is as follows:

          • The XPath regular expressions (the first members of the inner arrays) will be matched against the path of the entry in the archive. This will be done in the order of appearance in the outer array (so order is significant). The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • If a match is found, the content-type (the second member of the inner array for which the match was found) is used as the entry's content-type.

          • If no match was found for all inner arrays, the normal (implementation-defined) mechanism for determining the content-type is used.

          For example: setting the override-content-types option to [ ['.rels$', 'application/xml'], ['^special/', 'application/octet-stream'] ] means that all files ending with .rels will get the content-type application/xml. All files in the archive's special directory (including sub-directories) will get the content-type application/octet-stream.For example: setting the override-content-types option to [ ['.rels$', 'application/xml'], ['^special/', 'application/octet-stream'] ] means that all files ending with .rels will get the content-type application/xml. All files in the archive's special directory (including sub-directories) will get the content-type application/octet-stream.

          Document properties

          No document properties are preserved. The manifest has no base-uri.

          2.5. p:cast-content-type

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

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          content-typexs:string ✔ 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0071It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.
          err:C0072It is a dynamic error if the c:data contains content is not a valid base64 string.
          err:C0073It is a dynamic error if the c:data element does not have a content-type attribute.
          err:C0074It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:D0049It is a dynamic error if the text value is not a well-formed XML document
          err:D0057It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the text document can not be converted into the XPath data model
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          DefinedThe precise nature of the conversion from XML to JSON is implementation-defined.
          DefinedCasting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.
          DefinedCasting from an HTML media type to a JSON media type is implementation-defined.
          DefinedCasting from an HTML media type to any other media type is implementation-defined.
          DefinedIt is implementation-defined whether other result formats are supported.
          DefinedCasting from a JSON media type to an HTML media type is implementation-defined.
          DefinedCasting from a JSON media type to any other media type is implementation-defined.
          DefinedThe precise way in which text documents are parsed into the XPath data model is implementation-defined.
          DefinedCasting from a text media type to any other media type is implementation-defined.
          DefinedCasting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.
          DefinedCasting from any other media type to any other media type is implementation-defined.
          Declaration

          <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 () 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 () if the p:cast-content-type step cannot perform the requested cast. The input document is transformed from one media type to another. It is a dynamic error () 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 () 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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          2.5.1. Casting from an XML media type

          • Casting from one XML media type to another simply changes the “content-type” document property.

          • Casting from an XML media type to an HTML media type changes the “content-type” document property and removes any serialization property.

          • Casting from an XML media type to a JSON media type converts the XML into JSON. The precise nature of the conversion from XML to JSON is implementation-defined. If the input document is an XML representation of JSON as defined in [XPath and XQuery Functions and Operators 3.1], implementations must produce the same result as fn:parse-json(fn:xml-to-json()) by default. If the input document has a c:param-set document element, an instance of map(xs:QName, xs:string)must be returned that represents the document's c:param elements. The serialization property is removed.

          • Casting from an XML media type to a text media type serializes the XML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.Casting from an XML media type to a text media type serializes the XML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an XML media type to any other media type must support the case where the input document is a c:data document. The resulting document will have the specified media type and a representation that is the content of the c:data element after decoding the base64 encoded content The serialization property is removed.

            It is a dynamic error () if the contains content is not a valid base64 string.It is a dynamic error () if the contains content is not a valid base64 string.

            It is a dynamic error () if the element does not have a content-type attribute.It is a dynamic error () if the element does not have a content-type attribute.

            It is a dynamic error () if the content-type is supplied and is not the same as the content-type specified on the element. It is a dynamic error () if the content-type is supplied and is not the same as the content-type specified on the element.

            Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined.

          2.5.2. Casting from an HTML media type

          • Casting from an HTML media type to an XML media type changes “content-type” document property and removes any serialization property.

          • Casting from an HTML media type to another HTML media type changes “content-type” document property.

          • Casting from an HTML media type to a JSON media type is implementation-defined.

          • Casting an an HTML media type to a text media type serializes the HTML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.Casting an an HTML media type to a text media type serializes the HTML document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from an HTML media type to any other media type is implementation-defined.

          2.5.3. Casting from a JSON media type

          • Casting from a JSON media type to an XML media type converts the JSON into XML. An implementation must support the format specified in section “XML Representation of JSON” of [XPath and XQuery Functions and Operators 3.1] as default for the resulting XML. It is implementation-defined whether other result formats are supported. The serialization property is removed.

          • Casting from a JSON media type to an HTML media type is implementation-defined.

          • Casting from a JSON media type to another JSON media type changes “content-type” document property.

          • Casting from a JSON media type to a text media type serializes the JSON document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.Casting from a JSON media type to a text media type serializes the JSON document by calling fn:serialize($doc, $param) where $doc is the document on the source port and $param is the serialization property of this document. The resulting string is wrapped by a document node and returned on the result port. The serialization property is removed.

          • Casting from a JSON media type to any other media type is implementation-defined.

          2.5.4. Casting from a text media type

          • Casting from a text media type to an XML media type parses the text value of the document on source port by calling fn:parse-xml. It is a dynamic error () if the text value is not a well-formed XML document. The serialization property is removed.Casting from a text media type to an XML media type parses the text value of the document on source port by calling fn:parse-xml. It is a dynamic error () if the text value is not a well-formed XML document. The serialization property is removed.

          • Casting from a text media type to an HTML media type parses the text value of the document on source port into an XPath data model document that contains a tree of elements, attributes, and other nodes. The precise way in which text documents are parsed into the XPath data model is implementation-defined.It is a dynamic error () if the text document can not be converted into the XPath data model. The serialization property is removed.Casting from a text media type to an HTML media type parses the text value of the document on source port into an XPath data model document that contains a tree of elements, attributes, and other nodes. The precise way in which text documents are parsed into the XPath data model is implementation-defined.It is a dynamic error () if the text document can not be converted into the XPath data model. The serialization property is removed.

          • Casting from a text media type to a JSON media type parses the text value of the document on source port by calling fn:parse-json($doc, $par) where $doc is the text document and $par is the parameter option. It is a dynamic error () if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation. It is a dynamic error () if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys. It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present. The serialization property is removed. Casting from a text media type to a JSON media type parses the text value of the document on source port by calling fn:parse-json($doc, $par) where $doc is the text document and $par is the parameter option. It is a dynamic error () if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation. It is a dynamic error () if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys. It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present. The serialization property is removed.

          • Casting from a text media type to another text media type changes “content-type” document property.

          • Casting from a text media type to any other media type is implementation-defined.

          2.5.5. Casting from any other media type

          • Casting from a non-XML media type to an XML media type produces an XML document with a c:data document element. The original media type will be preserved in the content-type attribute on the c:data element.

            <c:data
              content-type = ContentType
              charset? = string
              encoding? = string>
                string
            </c:data>

            The content of the c:data element is the base64 encoded representation of the non-XML content. The serialization property is removed.

          • Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined.

          • Casting from any other media type to any other media type is implementation-defined.

          Document properties

          All document properties are preserved except the content-type property which is updated accordingly and the serialization property which is removed by some casting methods.

          2.6. p:compare

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          alternate  any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          differences ✔ any 
          Option nameTypeDefault value
          fail-if-not-equalxs:booleanfalse()
          methodxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0019It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.
          err:C0076It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.
          err:C0077It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.
          Implementation details
          ImplementationDescription
          DefinedImplementations of p:compare must support the deep-equal method; other supported methods are implementation-defined.
          DefinedIf 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.
          Declaration

          <p:declare-steptype="p:compare">
               <p:inputport="source"primary="true"content-types="any"/>
               <p:inputport="alternate"content-types="any"/>
               <p:outputport="result"primary="true"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 []). Implementations of p:comparemust support the deep-equalmethod; other supported methods are implementation-defined.It is a dynamic error () if the comparison method specified in p:compare is not supported by the implementation. It is a dynamic error () if the media types of the documents supplied are incompatible with the comparison method. 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 []). Implementations of p:comparemust support the deep-equalmethod; other supported methods are implementation-defined.It is a dynamic error () if the comparison method specified in p:compare is not supported by the implementation. It is a dynamic error () if the media types of the documents supplied are incompatible with the comparison method.

          It is a dynamic error () 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 document is produced with contents true if the documents are equal, otherwise false.It is a dynamic error () 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 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.

          Document properties

          No document properties are preserved. The comparison document has no base-uri.

          Erratum, April 2024

          The result output port has been made primary. This is consistent with the behavior of all known implementations.

          2.7. p:compress

          The p:compress step serializes the document appearing on its source port and outputs a compressed version of this on its result 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          formatxs:QName'gzip'
          parametersmap(xs:QName, item()*)?()
          serializationmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

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

          format

          The format of the compression can be specified using the format option. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed. The format of the compression can be specified using the format option. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed.

          parameters

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

          serialization

          The serialization option is provided to control the serialization of content before compression takes place. 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 [].The serialization option is provided to control the serialization of content before compression takes place. 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 [].

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly and the serialization property which is removed.

          2.8. p:count

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault value
          limitxs:integer0
          Declaration

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

          Document properties

          No document properties are preserved. The count document has no base-uri.

          2.9. p:delete

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the match option matches the document node.
          err:C0062It is a dynamic error if the match option matches a namespace node.
          Declaration

          <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.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.If an element is selected by the match option, the entire subtree rooted at that element is deleted.

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

          This step cannot be used to remove namespaces. It is a dynamic error () 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.This step cannot be used to remove namespaces. It is a dynamic error () 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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.10. p:error

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          codexs:QName✔ 
          Declaration

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

          Document properties

          No document properties are preserved but that’s irrelevant as no document is ever produced.

          2.11. p:filter

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ text xml html 
          Option nameTypeRequired
          selectXPathExpression✔ 
          Declaration

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

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI of the selected node(s).

          2.12. p:hash

          The p:hash step generates a hash, or digital “fingerprint”, for some value and injects it into the source document.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault valueRequired
          algorithmxs:QName ✔ 
          valuexs:string ✔ 
          matchXSLTSelectionPattern'/*/node()' 
          parametersmap(xs:QName,item()*)?() 
          versionxs:string?() 
          Errors
          Error codeDescription
          err:C0036It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other algorithms are supported.
          Declaration

          <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”.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 [], [], and [] hashes. It is implementation-defined what other algorithms are supported. The resulting hash should be returned as a string of hexadecimal characters. A hash is constructed from the string specified in the value option using the specified algorithm and version. Implementations must support [], [], and [] 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 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 () 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 hash of the specified value is computed using the algorithm and parameters specified. It is a dynamic error () if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.

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

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.13. p:http-request

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          report  application/json 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          assertxs:string'.?status-code lt 400' 
          authmap(xs:string, item()+)?() 
          headersmap(xs:string, xs:string)?() 
          methodxs:string?'GET' 
          parametersmap(xs:QName, item()*)?() 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0003It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.
          err:C0030It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).
          err:C0078It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.
          err:C0122It is a dynamic error if the given method is not supported.
          err:C0123It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.
          err:C0124It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.
          err:C0125It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.
          err:C0126It is a dynamic error if the XPath expression in assert evaluates to false.
          err:C0127It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.
          err:C0128It is a dynamic error if the URI’s scheme is unknown or not supported.
          err:C0131It is a dynamic error if the processor cannot support the requested encoding.
          err:C0132It is a dynamic error if the override content encoding cannot be supported.
          err:C0133It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.
          err:C0203It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which HTTP methods are supported.
          DefinedThe interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined.
          DefinedOther key value pairs in map “auth” are implementation-defined.
          DefinedIt is implementation-defined which other key/value pairs in the parameters option are supported.
          DefinedThe default behaviour in case of a redirect response is implementation-defined.
          DefinedIt is implementation-defined how a multipart boundary is constructed.
          Declaration

          <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.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().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 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: 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)

          This is the HTTP status code returned for the request.

          base-uri (an xs:anyURI)

          This is the URI of the last request made and is always available in the report even when the request does not return any documents. In the case of HTTP redirection, the base URI returned may be different from the original request URI.

          headers (a map(xs:string, xs:string))

          These are the HTTP headers returned for the request. The map may be empty. Header names are converted to lowercase.

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

          href

          The href option specifies the request’s IRI. Relative values are resolved against the base URI of the element on which the option is specified (the relevant p:with-option or the step element in the case of a syntactic shortcut value).The href option specifies the request’s IRI. Relative values are resolved against the base URI of the element on which the option is specified (the relevant p:with-option or the step element in the case of a syntactic shortcut value).

          Fragment identifiers are removed before making the request. Query parameters are passed through unchanged. It is a dynamic error () if the URI’s scheme is unknown or not supported. It is the pipeline author’s responsibility to escape problematic UTF-8 characters in the href value, for example with escape-html-uri(). Fragment identifiers are removed before making the request. Query parameters are passed through unchanged. It is a dynamic error () if the URI’s scheme is unknown or not supported. It is the pipeline author’s responsibility to escape problematic UTF-8 characters in the href value, for example with escape-html-uri().

          method

          The method specifies the HTTP request method. The value is implicitly turned into an uppercase string if necessary. It is implementation -defined which HTTP methods are supported. An implementation should implement at least the methods GET, POST, PUT, DELETE, and HEAD (for HTTP and HTTPS). It is a dynamic error () if the given method is not supported.The method specifies the HTTP request method. The value is implicitly turned into an uppercase string if necessary. It is implementation -defined which HTTP methods are supported. An implementation should implement at least the methods GET, POST, PUT, DELETE, and HEAD (for HTTP and HTTPS). It is a dynamic error () if the given method is not supported.

          serialization

          The serialization option is used to control the serialization of documents for the request body. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.The serialization option is used to control the serialization of documents for the request body. If a document has a “serialization” document property, the effective value of the serialization options is the union of the two maps, where the entries in the “serialization” document property take precedence.

          headers

          The key/value pairs in the headers map are used to construct the request headers. Each map key is used as a header name and the value associated with that key in the map is used as the header value.The key/value pairs in the headers map are used to construct the request headers. Each map key is used as a header name and the value associated with that key in the map is used as the header value.

          If a single document appears on the source port, then document properties on that document may be added as additional headers. For XML, HTML, and text documents with a serialization document property having an encoding key, a charset is appended to the created content-type header of the HTTP request. Properties in the http://www.w3.org/ns/xproc-http namespace will be added to the headers, using the local-name of the property QName as the header name. These properties are only copied if they are not specified in the header map. In other words, if the same header name appears in both places, the value from the map is used and the value from the document properties is ignored. (Header names are case-insensitive, so a case-insensitive comparison must be performed.) If multiple documents appear on the source port, none of their properties are used in the request headers.If a single document appears on the source port, then document properties on that document may be added as additional headers. For XML, HTML, and text documents with a serialization document property having an encoding key, a charset is appended to the created content-type header of the HTTP request. Properties in the http://www.w3.org/ns/xproc-http namespace will be added to the headers, using the local-name of the property QName as the header name. These properties are only copied if they are not specified in the header map. In other words, if the same header name appears in both places, the value from the map is used and the value from the document properties is ignored. (Header names are case-insensitive, so a case-insensitive comparison must be performed.) If multiple documents appear on the source port, none of their properties are used in the request headers.

          The behavior of the p:http-request depends on the headers specified. In particular:

          content-type

          If a content-type header is provided, it will be used. For a single document request, this overrides the content type value of the document. If the content type specified begins with “multipart/”, a multipart request will be sent to the server.

          It is a dynamic error () 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 () if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.

          transfer-encoding

          If a transfer-encoding header is provided, the request must be sent with that encoding. It is a dynamic error () if the processor cannot support the requested encoding.If a transfer-encoding header is provided, the request must be sent with that encoding. It is a dynamic error () if the processor cannot support the requested encoding.

          authorization

          The authorization header is used to authenticate a request. If the authoption is specified, any key or property that would have contributed a header named “authorization” (irrespective of case) is ignored. The authorization header is determined exclusively by the auth option when it is present.The authorization header is used to authenticate a request. If the authoption is specified, any key or property that would have contributed a header named “authorization” (irrespective of case) is ignored. The authorization header is determined exclusively by the auth option when it is present.

          HTTP headers are case-insensitive but keys in maps are not; be careful when specifying the request headers. It is a dynamic error () if the headers map contains two keys that are the same when compared in a case-insensitive manner. (That is, when fn:uppercase($key1) = fn:uppercase($key2).) HTTP headers are case-insensitive but keys in maps are not; be careful when specifying the request headers. It is a dynamic error () if the headers map contains two keys that are the same when compared in a case-insensitive manner. (That is, when fn:uppercase($key1) = fn:uppercase($key2).)

          auth

          Many web services are only available to authenticated users, that is, to users who have “logged in”. The auth option allows the pipeline author to specify information that may be required to generate an “Authorization” header. The standard values support HTTP “Basic” and “Digest” authentication, but other authentication methods are allowed.Many web services are only available to authenticated users, that is, to users who have “logged in”. The auth option allows the pipeline author to specify information that may be required to generate an “Authorization” header. The standard values support HTTP “Basic” and “Digest” authentication, but other authentication methods are allowed.

          The following standard keys are defined:

          username (xs:string)

          The username.

          password (xs:string)

          The password associated with the username.

          auth-method (xs:string)

          The authentication method. Appropriate values for the “auth-method” key are “Basic” or “Digest” but other values are allowed. If the authentication method is “Basic” or “Digest”, authentication is handled as per [RFC 2617]. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation -defined.

          send-authorization (xs:boolean)

          The “send-authorization” key can be used to attempt to allow the request to avoid an authentication challenge. If the “send-authorization” key is “true()”, and the authentication method specified by the value associated with the “auth-method” key supports generation of an “Authorization” header without a challenge, then the header is generated and sent on the first request. If the “send-authorization” key is absent or does not have the value “true”, the first request is sent without an “Authorization” header.

          Other key value pairs in map “auth” are implementation -defined.It is a dynamic error () if any key in the “auth” map is associated with a value that is not an instance of the required type.Other key value pairs in map “auth” are implementation -defined.It is a dynamic error () if any key in the “auth” map is associated with a value that is not an instance of the required type.

          If the initial response to the request is an authentication challenge, the values provided in the auth map and any relevant data from the challenge are used to generate an “Authorization” header and the request is sent again. If that authorization fails, the request is not retried.

          It is a dynamic error () if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported. All implementations must support “Basic” and “Digest” authentication per [].It is a dynamic error () if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported. All implementations must support “Basic” and “Digest” authentication per [].

          parameters

          The parameter option can be used to provide values for fine tuning the construction of the request and/or handling of the server response. A number of parameters are defined in this specification. It is implementation -defined which other key/value pairs in the parameters option are supported.The parameter option can be used to provide values for fine tuning the construction of the request and/or handling of the server response. A number of parameters are defined in this specification. It is implementation -defined which other key/value pairs in the parameters option are supported.

          override-content-type (xs:string)

          Ordinarily, the value of the content-type header provided in the server response controls the interpretation of any body in the response. If the “override-content-type” parameter is provided, then its value is used to interpret the body. The content-type header that appears on the report port is not changed. It is a dynamic error () 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 () if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).Ordinarily, the value of the content-type header provided in the server response controls the interpretation of any body in the response. If the “override-content-type” parameter is provided, then its value is used to interpret the body. The content-type header that appears on the report port is not changed. It is a dynamic error () 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 () if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          http-version (xs:string)

          The http-version parameter indicates which version of HTTP must be used for the request.

          accept-multipart (xs:boolean)

          If the accept-multipart parameter is present and explicitly has the value false(), a dynamic error will be raised, if a multipart response is received from the server. This feature is a convenience for pipeline authors as it will raise an error when the multipart request is received, rather than having the presence of a sequence raise an error further along in the pipeline, or simply producing anomalous results. It is a dynamic error () if the key “accept-multipart” as the value false() and a multipart response is detected.If the accept-multipart parameter is present and explicitly has the value false(), a dynamic error will be raised, if a multipart response is received from the server. This feature is a convenience for pipeline authors as it will raise an error when the multipart request is received, rather than having the presence of a sequence raise an error further along in the pipeline, or simply producing anomalous results. It is a dynamic error () if the key “accept-multipart” as the value false() and a multipart response is detected.

          override-content-encoding (xs:string)

          If the “override-content-encoding” parameter is present, the response will be treated as if the response contained a “content-encoding” header with the specified value. The content-encoding header that appears on the report port is not changed. It is a dynamic error () if the override content encoding cannot be supported. If the “override-content-encoding” parameter is present, the response will be treated as if the response contained a “content-encoding” header with the specified value. The content-encoding header that appears on the report port is not changed. It is a dynamic error () if the override content encoding cannot be supported.

          permit-expired-ssl-certificate (xs:boolean)

          If “permit-expired-ssl-certificate” is true, then the processor should not reject responses where the server provides an expired SSL certificate.

          permit-untrusted-ssl-certificate (xs:boolean)

          If “permit-untrusted-ssl-certificate” is true, then the processor should not reject response where the server provides an SSL certificate which is not trusted, for example, because the certificate authority (CA) is unknown.

          follow-redirect (xs:integer)

          The “follow-redirect” parameter allows the pipeline author to specify the step’s behaviour in the case of a redirect response. A value of 0 indicates that redirects are not to be followed, -1 indicates that redirects are to be followed indefinitely, and a specific number indicates the maximum number of redirects to follow. The default behaviour in case of a redirect response is implementation -defined.

          timeout (xs:integer)

          If a “timeout” is specified, it must be a non-negative integer. It controls the time the XProc processor waits for the request to be answered. If a value is given, it is taken as the number of seconds to wait for the response to be delivered. If no response is received after that time, the request is terminated and a status-code 408 is assumed.

          fail-on-timeout (xs:boolean)

          If “fail-on-timeout” is true, a dynamic error is raised if a 408 response is received (either as a consequence of setting a value for the “timeout” parameter or as status code returned by a server). It is a dynamic error () if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered. If “fail-on-timeout” is true, it prevents any dynamic error with code C0126 resulting from the assert option to be raised for request's timeout.If “fail-on-timeout” is true, a dynamic error is raised if a 408 response is received (either as a consequence of setting a value for the “timeout” parameter or as status code returned by a server). It is a dynamic error () if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered. If “fail-on-timeout” is true, it prevents any dynamic error with code C0126 resulting from the assert option to be raised for request's timeout.

          Note

          Please note that the “fail-on-timeout” parameter is different from the “timeout” option on the p:http-request step (see Controlling long running steps in XProc 3.0: An XML Pipeline Language). If the step does not finish in the specified time, D0053 is raised. If the request does not finish in time, and fail-on-timeout is true, C0078 is raised. The actual times after which a timeout is detected may also differ slightly.

          status-only (xs:boolean)

          If the “status-only” parameter is true, this indicates that the pipeline author is only interested in the response code. An empty sequence is always returned on the result port in this case. The implementation may save resources by ignoring the response body. The map on the report will contain the status code and an empty map for “headers”.If the “status-only” parameter is true, this indicates that the pipeline author is only interested in the response code. An empty sequence is always returned on the result port in this case. The implementation may save resources by ignoring the response body. The map on the report will contain the status code and an empty map for “headers”.

          suppress-cookies (xs:boolean)

          If the “suppress-cookies” parameter is true, the implementation must not send any cookies with the request.

          send-body-anyway (xs:boolean)

          If the “send-body-anyway” parameter is true, and one or more documents appear on the source port, a request body is constructed from the documents and sent with the request, even if the semantics of sending a body are not specified for the HTTP method in use. If the “send-body-anyway” parameter is true, and one or more documents appear on the source port, a request body is constructed from the documents and sent with the request, even if the semantics of sending a body are not specified for the HTTP method in use.

          It is a dynamic error () if any key in the “parameters” map is associated with a value that is not an instance of the required type.It is a dynamic error () if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          assert (xs:string)

          The assert option can be used by pipeline authors to raise a dynamic error if the response does not fulfill the expectations of the receiver. The option's value (if present) is interpreted as an XPath expression which will be executed using the map that appears on the report port as its context item. If the effective boolean value of the expression is false(), a dynamic error is raised. It is a dynamic error () if the XPath expression in assert evaluates to false. Implementations should provide an XML representation of the map used as the context item with the error document to enable pipelines to access the error's cause.The assert option can be used by pipeline authors to raise a dynamic error if the response does not fulfill the expectations of the receiver. The option's value (if present) is interpreted as an XPath expression which will be executed using the map that appears on the report port as its context item. If the effective boolean value of the expression is false(), a dynamic error is raised. It is a dynamic error () if the XPath expression in assert evaluates to false. Implementations should provide an XML representation of the map used as the context item with the error document to enable pipelines to access the error's cause.

          2.13.1. Construction of a multipart request

          If more than one document appears on the source port, or if the specified “content-type” header begins “multipart/”, a multipart request will be constructed, per []. The content type of the request is derived from the “content-type” header:If more than one document appears on the source port, or if the specified “content-type” header begins “multipart/”, a multipart request will be constructed, per []. The content type of the request is derived from the “content-type” header:

          • If the “content-type” header specifies a multipart content type, that value will be used as the content type. If the header includes a boundary parameter, that value will be used as the boundary. It is a dynamic error () if the specified boundary is not valid (for example, if it begins with two hyphens “--”). If the “content-type” header specifies a multipart content type, that value will be used as the content type. If the header includes a boundary parameter, that value will be used as the boundary. It is a dynamic error () if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          • If the “content-type” header is not specified, “multipart/mixed” will be used.

          • It is a dynamic error () if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type. It is a dynamic error () if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          A multipart request must have a boundary marker, if one isn’t specified in the content type, the implementation must construct one. It is implementation-defined how a multipart boundary is constructed. Implementations are not required to guarantee that the constructed value does not appear accidentally in the multipart data. If it does, the request will be malformed; pipeline authors must provide a boundary if they wish to assure that this cannot happen.

          Each document in the sequence is serialized. If the document has a “serialization” document property, its values are used to determine how serialization is performed.

          All of the document properties in the http://www.w3.org/ns/xproc-http namespace will be added as headers for the part, using the local-name of the property QName as the header name. In particular, this is how the “id”, “description”, “disposition” and other multipart headers can be provided.

          2.13.2. Managing a multipart response

          When a multipart response is received, each part is interpreted according to it’s content type and a pipeline document is constructed. Any additional headers associated with the part are added to the document properties of the constructed document.

          The multipart response is the resulting sequence of documents.

          Document properties

          No document properties are preserved.

          2.14. p:identity

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Declaration

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

          Document properties

          All document properties are preserved.

          2.15. p:insert

          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.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"values="('first-child','last-child','before','after')"select="'after'"/><!-- string --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          insertion ✔ xml html text 
          Output portPrimarySequenceContent types
          result✔  xml html text 
          Option nameTypeValuesDefault value
          matchXSLTSelectionPattern '/*'
          positionxs:string('first-child','last-child','before','after') 'after'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace node.
          err:C0024It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.
          err:C0025It is a dynamic error 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”.
          Declaration

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

          The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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 match option must be an XSLTSelectionPattern. It is a dynamic error () 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: The value of the position option must be an NMTOKEN in the following list:

          • “first-child” - the insertion is made as the first child of the match;

          • “last-child” - the insertion is made as the last child of the match;

          • “before” - the insertion is made as the immediate preceding sibling of the match;

          • “after” - the insertion is made as the immediate following sibling of the match.

          It is a dynamic error () 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 () if the selection pattern matches a document node and the value of the position is “before” or “after”.It is a dynamic error () 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 () 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.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.

          Document properties

          All document properties on the source port are preserved. The document properties on the insertion port are not preserved or present in the result document.All document properties on the source port are preserved. The document properties on the insertion port are not preserved or present in the result document.

          2.16. p:json-join

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

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeDefault value
          flatten-to-depthxs:string?'0'
          Errors
          Error codeDescription
          err:C0111 It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.
          err:C0119It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

          <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 step inspects the documents on port source in turn to create the resulting array:

          • If the document under inspection is a JSON document representing an array, the array is copied to the resulting array according to the setting of option flatten-to-depth.If the document under inspection is a JSON document representing an array, the array is copied to the resulting array according to the setting of option flatten-to-depth.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents, their XDM representation is appended to the resulting array.

          • It is implementation -defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, an entry is created as described above. It is a dynamic error () if a document of an unsupported document type appears on port source of p:json-join. It is implementation -defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, an entry is created as described above. It is a dynamic error () if a document of an unsupported document type appears on port source of p:json-join.

          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 () 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 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 () 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.

          Document properties

          No document properties are preserved. The joined document has no base-uri.

          2.17. p:json-merge

          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.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"values="('reject', 'use-first', 'use-last', 'use-any', 'combine')"select="'use-first'"/><!-- string -->     <p:optionname="key"as="xs:string"select="'concat("_",$p:index)'"/><!-- XPathExpression --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeValuesDefault value
          duplicatesxs:string('reject', 'use-first', 'use-last', 'use-any', 'combine') 'use-first'
          keyXPathExpression 'concat("_",$p:index)'
          Errors
          Error codeDescription
          err:C0106It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.
          err:C0107 It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.
          err:C0110It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents.
          Declaration

          <p:declare-steptype="p:json-merge">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"content-types="application/json"/>
               <p:optionname="duplicates"values="('reject', 'use-first', 'use-last', 'use-any', 'combine')"select="'use-first'"/><!-- string -->
               <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:The step inspects the documents on port source in turn to create the resulting map:

          • If the document under inspection is a JSON document representing a map, all key-value pairs are copied into the result map unless this map already contains an entry with the given key. In this case the value of option duplicates determines the policy for handling duplicate keys as specified for function map:merge in []. It is a dynamic error () if duplicate keys are encountered and option duplicates has value “reject”.If the document under inspection is a JSON document representing a map, all key-value pairs are copied into the result map unless this map already contains an entry with the given key. In this case the value of option duplicates determines the policy for handling duplicate keys as specified for function map:merge in []. It is a dynamic error () if duplicate keys are encountered and option duplicates has value “reject”.

          • For every other type of JSON document, for XML documents, HTML documents, or text documents a new key-value pair is created and put into the resulting map. The key is created by evaluating the XPath expression in option key with the inspected document as context item. If the evaluation result is a single atomic value, it is taken as key. If the evaluation result is a node, its string value is taken as key. It is a dynamic error () if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function. Duplicate keys are handled as described above. The XDM representation of the inspected document is taken as value of the key-value pair.For every other type of JSON document, for XML documents, HTML documents, or text documents a new key-value pair is created and put into the resulting map. The key is created by evaluating the XPath expression in option key with the inspected document as context item. If the evaluation result is a single atomic value, it is taken as key. If the evaluation result is a node, its string value is taken as key. It is a dynamic error () if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function. Duplicate keys are handled as described above. The XDM representation of the inspected document is taken as value of the key-value pair.

          • It is implementation -defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, the key-value pair is created as described above. It is a dynamic error () if a document of a not supported document type appears on port source of p:json-merge. It is implementation -defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. If a processor supports a given type of documents, the key-value pair is created as described above. It is a dynamic error () if a document of a not supported document type appears on port source of p:json-merge.

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

          Document properties

          No document properties are preserved. The merged document has no base-uri.

          2.18. p:label-elements

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          attributexs:QName'xml:id'
          labelXPathExpression'concat("_",$p:index)'
          matchXSLTSelectionPattern'*'
          replacexs:booleantrue()
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that expression matches anything other than element nodes.
          Declaration

          <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 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 () if that expression matches anything other than element nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.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.

          Document properties

          All document properties are preserved.

          2.19. p:load

          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>

          Summary

          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          content-typexs:string?() 
          document-propertiesmap(xs:QName, item()*)?() 
          parametersmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:D0011It is a dynamic error if the resource referenced by a p:load element does not exist or cannot be accessed.
          err:D0023It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.
          err:D0043It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.
          err:D0049It is a dynamic error if the loaded content is not a well-formed XML document.
          err:D0057It is a dynamic error if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.
          err:D0058It is a dynamic error if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.
          err:D0059It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.
          err:D0060It is a dynamic error if the content-type specifies an encoding, which is not supported by the processor.
          err:D0062It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0078It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIn the absence of an explicit type, the content type is implementation-defined
          DefinedAdditional XML parameters are implementation-defined.
          DefinedText parameters are implementation-defined.
          DefinedAdditional JSON parameters are implementation-defined.
          DefinedThe precise way in which HTML documents are parsed into the XPath data model is implementation-defined.
          DefinedHTML parameters are implementation-defined.
          DefinedHow a processor interprets other media types is implementation-defined.
          DefinedParameters for other media types are implementation-defined.
          Declaration

          <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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

          The document identified by the href URI is loaded and returned. If the URI protocol supports redirection, then redirects must be followed.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 () if the resource referenced by a p:load element does not exist or cannot be accessed.It is a dynamic error () 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:

          1. If a content-type property is specified in document-properties or content-type is present, then the document must be interpreted according to that content type. It is a dynamic error () 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 () if the content-type is specified and the document-properties has a “content-type” that is not the same. If a content-type property is specified in document-properties or content-type is present, then the document must be interpreted according to that content type. It is a dynamic error () 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 () if the content-type is specified and the document-properties has a “content-type” that is not the same.

          2. If the document is retrieved with a URI protocol that specifies a content type (for example, http:), then the document must be interpreted according to that content type.

          3. In the absence of an explicit type, the content type is implementation-defined.

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

          2.19.1. Loading XML data

          For an XML media type, the content is loaded and parsed as XML.

          It is a dynamic error () if the loaded content is not a well-formed XML document.It is a dynamic error () if the loaded content is not a well-formed XML document.

          If the dtd-validate parameter is true, then DTD validation must be performed when parsing the document. It is a dynamic error () if a DTD validation is performed and either the document is not valid or no DTD is found. It is a dynamic error () if the dtd-validate parameter is true and the processor does not support DTD validation.If the dtd-validate parameter is true, then DTD validation must be performed when parsing the document. It is a dynamic error () if a DTD validation is performed and either the document is not valid or no DTD is found. It is a dynamic error () if the dtd-validate parameter is true and the processor does not support DTD validation.

          Additional XML parameters are implementation-defined.

          2.19.2. Loading text data

          For a text media type, the content is loaded as a text document. (A text document is an XPath data model document consisting of a single text node.)

          It is a dynamic error () if the content-type specifies an encoding, which is not supported by the processor.It is a dynamic error () if the content-type specifies an encoding, which is not supported by the processor.

          Text parameters are implementation-defined.

          2.19.3. Loading JSON data

          For a JSON media type, the content is loaded and parsed as JSON.

          The parameters specified for the fn:parse-json function in [XPath and XQuery Functions and Operators 3.1] must be supported. Additional JSON parameters are implementation-defined.

          It is a dynamic error () if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.It is a dynamic error () if the loaded content does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          It is a dynamic error () if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.It is a dynamic error () if the parameter duplicates is reject and the value of loaded content contains a JSON object with duplicate keys.

          It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.It is a dynamic error () if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          2.19.4. Loading HTML data

          For an HTML media type, the content is loaded and parsed into an XPath data model document that contains a tree of elements, attributes, and other nodes.

          The precise way in which HTML documents are parsed into the XPath data model is implementation-defined.

          It is a dynamic error () if the loaded document cannot be represented as an HTML document in the XPath data model.It is a dynamic error () if the loaded document cannot be represented as an HTML document in the XPath data model.

          HTML parameters are implementation-defined.

          2.19.5. Loading binary data

          An XProc processor may load other, arbitrary data types. How a processor interprets other media types is implementation-defined.

          Parameters for other media types are implementation-defined.

          Document properties

          The properties specified in document-properties are applied. If the properties do not specify a base-uri, the base-uri property will reflect the base URI of the loaded document. The properties specified in document-properties are applied. If the properties do not specify a base-uri, the base-uri property will reflect the base URI of the loaded document.

          2.20. p:make-absolute-uris

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          base-urixs:anyURI?() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than element or attribute nodes.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DependentIf 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.
          Declaration

          <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 () if the pattern matches anything other than element or attribute nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

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

          Document properties

          All document properties are preserved.

          2.21. p:namespace-delete

          The p:namespace-delete step deletes all of the namespaces identified by the specified prefixes from the document appearing on port source.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeRequired
          prefixesxs:string✔ 
          Errors
          Error codeDescription
          err:C0108It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.
          err:C0109It is a dynamic error if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.
          Declaration

          <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 () if any prefix is not in-scope at the point where the p:namespace-delete occurs.The value of option prefixes is taken as a space separated list of prefixes. It is a dynamic error () 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.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 () if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.It is a dynamic error () if a namespace is to be removed from an attribute and the element already has an attribute with the resulting name.

          Document properties

          All document properties are preserved.

          2.22. p:namespace-rename

          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"select="'all'"values="('all','elements','attributes')"/><!-- string --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeValuesDefault value
          apply-toxs:string('all','elements','attributes') 'all'
          fromxs:anyURI? ()
          toxs:anyURI? ()
          Errors
          Error codeDescription
          err:C0014It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.
          err:C0092It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.
          Declaration

          <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"select="'all'"values="('all','elements','attributes')"/><!-- string -->
          </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 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 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.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 () 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.It is a dynamic error () if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.

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

          • Namespace bindings: If the from option is present and its value is not the empty string, then every binding of a prefix (or the default namespace) in the input document whose value is the same as the value of the from option isNamespace bindings: If the from option is present and its value is not the empty string, then every binding of a prefix (or the default namespace) in the input document whose value is the same as the value of the from option is

            • replaced in the output with a binding to the value of the to option, provided it is present and not the empty string;replaced in the output with a binding to the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) absent from the output.otherwise (the to option is not specified or has an empty string as its value) absent from the output.

            If the from option is absent, or its value is the empty string, then no bindings are changed or removed.If the from option is absent, or its value is the empty string, then no bindings are changed or removed.

          • Elements and attributes: If the from option is present and its value is not the empty string, for every element and attribute, as appropriate, in the input whose namespace name is the same as the value of the from option, in the output its namespace name isElements and attributes: If the from option is present and its value is not the empty string, for every element and attribute, as appropriate, in the input whose namespace name is the same as the value of the from option, in the output its namespace name is

            • replaced with the value of the to option, provided it is present and not the empty string;replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) changed to have no value.otherwise (the to option is not specified or has an empty string as its value) changed to have no value.

            If the from option is absent, or its value is the empty string, then for every element and attribute, as appropriate, whose namespace name has no value, in the output its namespace name is set to the value of the to option.If the from option is absent, or its value is the empty string, then for every element and attribute, as appropriate, whose namespace name has no value, in the output its namespace name is set to the value of the to option.

            It is a dynamic error () if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.It is a dynamic error () if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          • Namespace attributes: If the from option is present and its value is not the empty string, for every namespace attribute in the input whose value is the same as the value of the from option, in the outputNamespace attributes: If the from option is present and its value is not the empty string, for every namespace attribute in the input whose value is the same as the value of the from option, in the output

            • the namespace attribute's value is replaced with the value of the to option, provided it is present and not the empty string;the namespace attribute's value is replaced with the value of the to option, provided it is present and not the empty string;

            • otherwise (the to option is not specified or has an empty string as its value) the namespace attribute is absent.otherwise (the to option is not specified or has an empty string as its value) the namespace attribute is absent.

          Note

          The apply-to option is primarily intended to make it possible to avoid renaming attributes when the from option specifies no namespace, since many attributes are in no namespace.The apply-to option is primarily intended to make it possible to avoid renaming attributes when the from option specifies no namespace, since many attributes are in no namespace.

          Care should be taken when specifying no namespace with the to option. Prefixed names in content, for example QNames and XPath expressions, may end up with no appropriate namespace binding.Care should be taken when specifying no namespace with the to option. Prefixed names in content, for example QNames and XPath expressions, may end up with no appropriate namespace binding.

          Document properties

          All document properties are preserved.

          2.23. p:pack

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          alternate ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeRequired
          wrapperxs:QName✔ 
          Declaration

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

          Note

          In the common case, where the document element of a document in the result sequence has two element children, any comments, processing instructions, or white space text nodes that occur between them may have come from either of the input documents; this step does not attempt to distinguish which one.In the common case, where the document element of a document in the result sequence has two element children, any comments, processing instructions, or white space text nodes that occur between them may have come from either of the input documents; this step does not attempt to distinguish which one.

          Document properties

          No document properties are preserved. The result documents do not have a base-uri property.

          2.24. p:rename

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          new-namexs:QName ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0013It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.
          err:C0023It is a dynamic error if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.
          Declaration

          <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 () if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () if the pattern matches anything other than element, attribute, or processing instruction nodes, or if it matches more than one attribute on a single element.

          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.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.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 () if the pattern matches a processing instruction and the new name has a non-null namespace. If the pattern matches processing instructions, then it is the processing instruction target that is renamed. It is a dynamic error () if the pattern matches a processing instruction and the new name has a non-null namespace.

          Document properties

          All document properties are preserved.

          2.25. p:replace

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          replacement  text xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches an attribute or a namespace nodes.
          Declaration

          <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 () 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.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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, the result is a text document with the text node wrapped in a document node.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.26. p:set-attributes

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault valueRequired
          attributesmap(xs:QName, xs:anyAtomicType) ✔ 
          matchXSLTSelectionPattern'/*' 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than element nodes.
          err:C0059It is a dynamic error if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.
          Declaration

          <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 () if that pattern matches anything other than element nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.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.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.

          IfThis step cannot be used to add namespace declarations. It is a dynamic error (the ) if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/. However, 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.IfThis step cannot be used to add namespace declarations. It is a dynamic error (the ) if the name of any attribute is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/. However, 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.

          Document properties

          All document properties are preserved.

          2.27. p:set-properties

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault valueRequired
          propertiesmap(xs:QName,item()*) ✔ 
          mergexs:booleantrue() 
          Errors
          Error codeDescription
          err:C0069It is a dynamic error if the properties map contains a key equal to the string “content-type”.
          err:D0064It is a dynamic error if the base URI is not both absolute and valid according to .
          err:D0070It is a dynamic error 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 .
          Declaration

          <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.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.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 () 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 [].It is a dynamic error () 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 [].

          It is a dynamic error () if the properties map contains a key equal to the string “content-type”. It is a dynamic error () 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 () if the base URI is not both absolute and valid according to [].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 () if the base URI is not both absolute and valid according to [].

          Document properties

          If merge is true, document properties not overridden by settings in the properties map are preserved, otherwise the resulting document has only the content-type property and the properties specified in the properties map. In particular, if merge is false, the base-uri property will not be preserved. This means that the resulting document will not have a base URI if the properties map does not contain a base-uri entry. If merge is true, document properties not overridden by settings in the properties map are preserved, otherwise the resulting document has only the content-type property and the properties specified in the properties map. In particular, if merge is false, the base-uri property will not be preserved. This means that the resulting document will not have a base URI if the properties map does not contain a base-uri entry.

          2.28. p:sink

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Declaration

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

          Document properties

          Not applicable.

          2.29. p:sleep

          The p:sleep step introduces a delay.

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeRequired
          durationxs:nonNegativeInteger✔ 
          Declaration

          <p:declare-steptype="p:sleep">
               <p:inputport="source"sequence="true"content-types="any"/>
               <p:outputport="result"sequence="true"content-types="any"/>
               <p:optionname="duration"as="xs:nonNegativeInteger"required="true"/>
          </p:declare-step>

          The p:sleep step copies each of the documents on the source port to the result port without changing them. Before copying the documents, it pauses for a period of time not less than duration milliseconds.

          Note

          In multi-threaded implementations, there is no guarantee that this will pause the execution of more than one thread. However, any steps that depend on the output of this step will wait for this step to complete.

          Document properties

          All document properties are preserved.

          2.29. 2.30. p:split-sequence

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          Output portPrimarySequenceContent types
          matched✔ ✔ any 
          not-matched ✔ any 
          Option nameTypeDefault valueRequired
          testXPathExpression ✔ 
          initial-onlyxs:booleanfalse() 
          Errors
          Error codeDescription
          err:C0150It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.
          Declaration

          <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 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.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.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 () if evaluating the XPath expression in option test on a context document results in an error.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 () if evaluating the XPath expression in option test on a context document results in an error.

          Note

          In principle, this component cannot stream because it must buffer all of the input sequence in order to find the context size. In practice, if the test expression does not use the last() function, the implementation can stream and ignore the context size.

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

          Document properties

          All document properties are preserved.

          2.30. 2.31. p:store

          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 step, copying its input to the result port.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 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          result-uri  application/xml 
          Option nameTypeDefault valueRequired
          hrefxs:anyURI ✔ 
          serializationmap(xs:QName,item()*)?() 
          Errors
          Error codeDescription
          err:C0050It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.
          Declaration

          <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 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 () if the URI scheme is not supported or the step cannot store to the specified location.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 () 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 element whose content is the absolute URI of the document stored by the step.The output of this step on the result-uri port is a document containing a single 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 [].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 [].

          Document properties

          All document properties are preserved.

          2.31. 2.32. p:string-replace

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

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeRequired
          matchXSLTSelectionPattern✔ 
          replaceXPathExpression✔ 
          Declaration

          <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 match option must be an XSLTSelectionPattern.

          The value of the replace option must be an XPathExpression.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.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 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.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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.32. 2.33. p:text-count

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Declaration

          <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 element whose contents is the string representing this count.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 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 (&#10;), that newline is ignored. (It is not a separator between that line and a following line that contains no characters.)

          Document properties

          No document properties are preserved. The count document does not have a base-uri property.

          2.33. 2.34. p:text-head

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

          <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:The p:text-head step returns on its result port lines from the text document that appears on its source port:

          • If the count option is positive, the p:text-head step returns the first count linesIf the count option is positive, the p:text-head step returns the first count lines

          • If the count option is zero, the p:text-head step returns all linesIf the count option is zero, the p:text-head step returns all lines

          • If the count option is negative, the p:text-head step returns all lines except the first count linesIf the count option is negative, the p:text-head step returns all lines except the first count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.34. 2.35. p:text-join

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault value
          override-content-typexs:string?()
          prefixxs:string?()
          separatorxs:string?()
          suffixxs:string?()
          Errors
          Error codeDescription
          err:C0001It is a dynamic error if the value of option override-content-type is not a text media type.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Declaration

          <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. 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 separator option is specified, its value will be inserted in between adjacent documents.When the separator option is specified, its value will be inserted in between adjacent documents.

          • When the prefix option is specified, the document appearing on the result port will always start with its value (also when there are no documents on the source port).When the prefix option is specified, the document appearing on the result port will always start with its value (also when there are no documents on the source port).

          • When the suffix option is specified, the document appearing on the result port will always end with its value (also when there are no documents on the source port).When the suffix option is specified, the document appearing on the result port will always end with its value (also when there are no documents on the source port).

          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 () 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 () if the value of option override-content-type is not a text media type. 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 () 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 () 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.

          Document properties

          No document properties are preserved. The joined document has no base-uri property.

          2.35. 2.36. p:text-replace

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeDefault valueRequired
          patternxs:string ✔ 
          replacementxs:string ✔ 
          flagsxs:string?() 
          Errors
          Error codeDescription
          err:C0147It is a dynamic error if the specified value is not a valid XPath regular expression.
          Declaration

          <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. 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 function. The pattern option must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if the specified value is not a valid XPath regular expression.The pattern, replacement and flags options are specified the same as the parameters with the same names of the function. The pattern option must be a regular expression as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () 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.

          Document properties

          All document properties are preserved.

          2.36. 2.37. p:text-sort

          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')"/><!-- string -->     <p:optionname="case-order"as="xs:string?"values="('upper-first', 'lower-first')"/><!-- string -->     <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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeValuesDefault value
          case-orderxs:string?('upper-first', 'lower-first') ()
          collationxs:string 'http://www.w3.org/2005/xpath-functions/collation/codepoint'
          langxs:language? ()
          orderxs:string('ascending', 'descending') 'ascending'
          sort-keyXPathExpression '.'
          stablexs:boolean true()
          Errors
          Error codeDescription
          err:C0098It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.
          err:C0099It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.
          Implementation details
          ImplementationDescription
          DefinedSupport for other collations is implementation-defined.
          Declaration

          <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')"/><!-- string -->
               <p:optionname="case-order"as="xs:string?"values="('upper-first', 'lower-first')"/><!-- string -->
               <p:optionname="lang"as="xs:language?"/>                     
               <p:optionname="collation"as="xs:string"select="'http://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.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.

          • The sort-key is used to obtain a sort key for each of the lines in the document appearing on source. The context item is the line as an instance of xs:string, the context position is the number of the line in the document on port source, the context size is the number of lines in this document. It is a dynamic error () if a dynamic XPath error occurred while applying sort-key to a line. It is a dynamic error () if the result of applying sort-key to a given line results in a sequence with more than one item. The sort-key is used to obtain a sort key for each of the lines in the document appearing on source. The context item is the line as an instance of xs:string, the context position is the number of the line in the document on port source, the context size is the number of lines in this document. It is a dynamic error () if a dynamic XPath error occurred while applying sort-key to a line. It is a dynamic error () if the result of applying sort-key to a given line results in a sequence with more than one item.

          • The order option defines whether the lines are processed in ascending or descending order. Its value must be one of ascending or descending. The default is ascending.The order option defines whether the lines are processed in ascending or descending order. Its value must be one of ascending or descending. The default is ascending.

          • The case-order option defines whether upper-case letters are to be collated before or after lower-case letters. Its value must be one of upper-first or lower-first. The default is language-dependent.The case-order option defines whether upper-case letters are to be collated before or after lower-case letters. Its value must be one of upper-first or lower-first. The default is language-dependent.

          • The lang option defines the language whose collating conventions are to be used. The xs:language data type represents natural language identifiers as defined by [] (currently represented by [] and [] or its successor(s).) The default depends on the processing environment. Its value must be a valid language code (e.g. en-EN). The lang option defines the language whose collating conventions are to be used. The xs:language data type represents natural language identifiers as defined by [] (currently represented by [] and [] or its successor(s).) The default depends on the processing environment. Its value must be a valid language code (e.g. en-EN).

          • The collation option identifies how strings are to be compared with each other. Its value must be a valid collation URI. The only collation XProc processors must support is the Unicode Codepoint Collation . This is also its default. Support for other collations is implementation-defined.The collation option identifies how strings are to be compared with each other. Its value must be a valid collation URI. The only collation XProc processors must support is the Unicode Codepoint Collation . This is also its default. Support for other collations is implementation-defined.

          • If the stable option is set to false this indicates that there is no requirement to retain the original order of items that have equal values for all the sort keys.If the stable option is set to false this indicates that there is no requirement to retain the original order of items that have equal values for all the sort keys.

          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 (&#10;), 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 (&#10;).

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

          Document properties

          All document properties are preserved.

          Erratum, April 2024

          The URI for the Unicode Codepoint Collation has been corrected to an http: URI rather than an https: one. The URI is an identifier and the correct identifier uses an http: URI. Implementations are encouraged to recognized collation URIs that begin with “https://www.w3.org/” and treat them as if they began “http://www.w3.org/”, with a warning, if practical.

          2.37. 2.38. p:text-tail

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  text 
          Option nameTypeRequired
          countxs:integer✔ 
          Declaration

          <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:The p:text-tail step returns on its result port lines from the text document that appears on its source port:

          • If the count option is positive, the p:text-tail step returns the last count linesIf the count option is positive, the p:text-tail step returns the last count lines

          • If the count option is zero, the p:text-tail step returns all linesIf the count option is zero, the p:text-tail step returns all lines

          • If the count option is negative, the p:text-tail step returns all lines except the last count linesIf the count option is negative, the p:text-tail step returns all lines except the last count lines

          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 (&#10;).

          Document properties

          All document properties are preserved.

          2.38. 2.39. p:unarchive

          The p:unarchive step outputs on its result port specific entries in an archive (for instance from a zip file).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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          exclude-filterRegularExpression()
          formatxs:QName?()
          include-filterRegularExpression()
          override-content-typesarray(array(xs:string))?()
          parametersmap(xs:QName, item()*)?()
          relative-toxs:anyURI?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0085It is a dynamic error if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.
          err:C0120It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.
          err:C0147It is a dynamic error if a specified value is not a valid XPath regular expression.
          err:D0064It is a dynamic error if the option is not a valid URI according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the archive's format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

          <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 format of the archive is determined as follows:

            • If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.If the format option is specified, this determines the format of the archive. Implementations must support the [] format, specified with the value zip. It is implementation-defined what other formats are supported.

            • If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format. If no format option is specified or if its value is the empty sequence, the archive's format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the archive's format. Implementations should recognize archives in [] format.

            • It is a dynamic error () if the format of the archive does not match the specified format, cannot be understood, determined and/or processed.It is a dynamic error () 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 unarchiving. The semantics of the keys and the allowed values for these keys are implementation-defined.It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.The parameters option can be used to supply parameters to control the unarchiving. The semantics of the keys and the allowed values for these keys are implementation-defined.It is a dynamic error () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          • If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if a specified value is not a valid XPath regular expression.If present, the value of the include-filter or exclude-filter option must be a sequence of strings, each one representing a regular expressions as specified in [], section 7.61 “Regular Expression Syntax”. It is a dynamic error () if a specified value is not a valid XPath regular expression.

            If neither the include-filter option nor the exclude-filter option is specified, the p:unarchive step outputs on its result port all entries in the archive.If neither the include-filter option nor the exclude-filter option is specified, the p:unarchive step outputs on its result port all entries in the archive.

            If the include-filter option or the exclude-filter option is specified, the p:archive step outputs on the result port the entries from the archive that conform to the following rules:If the include-filter option or the exclude-filter option is specified, the p:archive step outputs on the result port the entries from the archive that conform to the following rules:

            • If any include-filter pattern matches an archive entry's name, the entry is included in the output.If any include-filter pattern matches an archive entry's name, the entry is included in the output.

            • If any exclude-filter pattern matches an archive entry's name, the entry is excluded in the output.If any exclude-filter pattern matches an archive 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.

            • Names of entries in archives are always relative names. For instance, the name of a file called xyz.xml in a specs subdirectory in an archive is called in full specs/xyz.xml (and not /specs/xyz.xml).

            As a result: an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.As a result: an item is included if it matches (at least) one of the include-filter values and none of the exclude-filter values.

            The regular expressions specified in the include-filter and exclude-filter options will be matched against the path of the entry in the archive. The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).The regular expressions specified in the include-filter and exclude-filter options will be matched against the path of the entry in the archive. The matching is done unanchored: it is a match if the regular expression matches part of the entry's path. Informally: matching behaves like applying the XPath matches#2 function, like in matches($path-in-archive, $regular-expression).

            Note

            Depending on how archives are constructed, the path of an entry in an archive can be with or without a leading slash. Usually it will be without. For archives constructed by p:archive no leading slash will be present.

          • The relative-to option, when present, is used in creating the base URI of the unarchived documents. 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).The relative-to option, when present, is used in creating the base URI of the unarchived documents. 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).

          • The override-content-types option can be used to partially override the content-type determination mechanism, as described in .The override-content-types option can be used to partially override the content-type determination mechanism, as described in .

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

          • If the relative-to option is present: Function p:urify() is called with the value of this option as second parameter ($basedir) and with the relative path of this document as it was in the archive as first parameterIf the relative-to option is present: Function p:urify() is called with the value of this option as second parameter ($basedir) and with the relative path of this document as it was in the archive as first parameter

          • If the relative-to option is not present: Function p:urify()is called with the value of the base URI of the archive appended with a “/” as second parameter ($baseDir) and the relative path of this document as it was in the archive as first parameterIf the relative-to option is not present: Function p:urify()is called with the value of the base URI of the archive appended with a “/” as second parameter ($baseDir) and the relative path of this document as it was in the archive as first parameter

          It is a dynamic error () 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 () if the option is not a valid URI according to [].It is a dynamic error () 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 () if the option is not a valid URI according to [].

          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:

          • With the relative-to option set to file:///x/y/z: file:///x/y/z/specs/xyz.xmlWith the relative-to option set to file:///x/y/z: file:///x/y/z/specs/xyz.xml

          • Without a relative-to option set: file:///a/b/c.zip/specs/xyz.xmlWithout a relative-to option set: file:///a/b/c.zip/specs/xyz.xml

          Document properties

          No document properties are preserved. The base-uri property of each unarchived document is reflective of the base URI of the document.

          2.39. 2.40. p:uncompress

          The p:uncompress step expects on its source port a compressed document. It outputs an uncompressed version of this on its result port.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  any 
          Output portPrimarySequenceContent types
          result✔  any 
          Option nameTypeDefault value
          content-typexs:string'application/octet-stream'
          formatxs:QName?()
          parametersmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0079It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.
          err:C0201It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.
          err:C0202It is a dynamic error if the compression format cannot be understood, determined and/or processed.
          err:D0079It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined what other formats are supported.
          DefinedIt is implementation-defined how the step determines the compression format.
          DefinedThe semantics of the keys and the allowed values for these keys are implementation-defined.
          Declaration

          <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 compression format of the document appearing on the source port is determined as follows:

          • If the format option is specified, this determines the compression format. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed.If the format option is specified, this determines the compression format. Implementations must support the [] format, specified with the value gzip. It is implementation-defined what other formats are supported.It is a dynamic error () if the compression format cannot be understood, determined and/or processed.

          • If no format option is specified or its value is the empty sequence, the compression format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the compression format. Implementations should recognize archives in [] format. If no format option is specified or its value is the empty sequence, the compression format will be determined by the step, using the content-type document-property of the document on the source port and/or by inspecting its contents. It is implementation-defined how the step determines the compression format. Implementations should recognize archives in [] format.

          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 () if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.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 () 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:

          1. If the content-type option is specified, the uncompressed document must be interpreted according to that content-type. It is a dynamic error () 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 () if the p:uncompress step cannot perform the requested content-type cast. If the content-type option is specified, the uncompressed document must be interpreted according to that content-type. It is a dynamic error () 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 () if the p:uncompress step cannot perform the requested content-type cast.

          2. In the absence of an explicit type, the content will be interpreted as content type application/octet-stream.

          Document properties

          All document properties are preserved, except for the content-type property which is updated accordingly.

          2.40. 2.41. p:unwrap

          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="text xml html"/>     <p:optionname="match"as="xs:string"select="'/*'"/>         <!-- XSLTSelectionPattern --></p:declare-step>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if that pattern matches anything other than the document node or element nodes.
          Declaration

          <p:declare-steptype="p:unwrap">
               <p:inputport="source"content-types="xml html"/>
               <p:outputport="result"content-types="text xml html"/>
               <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 () if that pattern matches anything other than the document node or element nodes.The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.

          Note

          The matching applies to the entire document, not just the “top-most” matches. A pattern of the form h:div will replace allh:div elements, not just the top-most ones.

          This step produces a single document. Special cases:

          • If the document element is unwrapped, the result might not be well-formed XML.

            For instance unwrapping the root element of <!-- COMMENT --><root-element/> will result in a document node with a single comment node child, which is not well-formed.

          • If a document consisting of only an empty root element is unwrapped, the result will be a document node without children. The result document’s content type will not change.

          • If a document consisting of a root element containing only text is unwrapped, the result will be a document node with a single text node child. The result document’s content type will become “text/plain”.

          As specified in the core language specification: if the content type changes, the serialization document property, if present, will be removed.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. In all other cases, all document properties are preserved.

          2.41. 2.42. p:uuid

          The p:uuid step generates a [] and injects it into the source document.The p:uuid step generates a [] 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  text xml html 
          Option nameTypeDefault value
          matchXSLTSelectionPattern'/*'
          parametersmap(xs:QName, item()*)?()
          versionxs:integer?()
          Errors
          Error codeDescription
          err:C0060It is a dynamic error if the processor does not support the specified version of the UUID algorithm.
          Implementation details
          ImplementationDescription
          DefinedIf the version is not specified, the version of UUID computed is implementation-defined.
          DefinedSupport for other versions of UUID is implementation-defined.
          DefinedThe names and values of parameters to p:uuid are implementation-defined.
          Declaration

          <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:optionname="parameters"as="map(xs:QName, item()*)?"/>    
          </p:declare-step>

          The value of the match option must be an XSLTSelectionPattern. The value of the version option must be an integer.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 () 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.If the version is specified, that version of UUID must be computed. It is a dynamic error () 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, is implementation-defined. Some UUID schemes require additional parameters which may be provided in the parameters option. and the mechanismThe names and values of byparameters whichto thep:uuid necessary inputs are made available for computing other versions, isare implementation-defined.Implementations must support version 4 UUIDs. Support for other versions of UUID, is implementation-defined. Some UUID schemes require additional parameters which may be provided in the parameters option. and the mechanismThe names and values of byparameters whichto thep:uuid necessary inputs are made available for computing other versions, isare 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.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 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.

          Document properties

          If the resulting document contains exactly one text node, the content-type property is changed to text/plain and the serialization property is removed, while all other document properties are preserved. For other document types, all document properties are preserved.

          2.42. 2.43. p:wrap-sequence

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ text xml html 
          Output portPrimarySequenceContent types
          result✔ ✔ application/xml 
          Option nameTypeDefault valueRequired
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Declaration

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

          Document properties

          No document properties are preserved. The document produced has no base-uri property.

          2.43. 2.44. p:wrap

          The p:wrap step wraps matching nodes in the source document with a new parent element.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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  application/xml 
          Option nameTypeDefault valueRequired
          matchXSLTSelectionPattern ✔ 
          wrapperxs:QName ✔ 
          group-adjacentXPathExpression() 
          Errors
          Error codeDescription
          err:C0023It is a dynamic error if the pattern matches anything other than document, element, text, processing instruction, and comment nodes.
          Declaration

          <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 () if the pattern matches anything other than document, element, text, processing instruction, and comment nodes. The value of the match option must be an XSLTSelectionPattern. It is a dynamic error () 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.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.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. 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.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.

          Document properties

          All document properties are preserved.

          2.44. 2.45. p:www-form-urldecode

          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>

          Summary

          Output portPrimarySequenceContent types
          result✔  application/json 
          Option nameTypeRequired
          valuexs:string✔ 
          Errors
          Error codeDescription
          err:C0037It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.
          Declaration

          <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. 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 () if the value provided is not a properly x-www-form-urlencoded value. It is a dynamic error () 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.

          Document properties

          The resulting JSON document has no properties apart from content-type. In particular, it has no base-uri.

          2.45. 2.46. p:www-form-urlencode

          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:anyAtomicType+)"/></p:declare-step>

          Summary

          Output portPrimarySequenceContent types
          result✔  text/plain 
          Option nameTypeRequired
          parametersmap(xs:string,xs:anyAtomicType+)✔ 
          Declaration

          <p:declare-steptype="p:www-form-urlencode">
               <p:outputport="result"content-types="text/plain"/>
               <p:optionname="parameters"required="true"as="map(xs:string,xs:anyAtomicType+)"/>
          </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. 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.If more than one value is associated with a given key in parameters option, a name/value pair is created for each value.

          Document properties

          The resulting text document has no properties apart from content-type. In particular, it has no base-uri.

          2.46. 2.47. p:xinclude

          The p:xinclude step applies [] processing to the source document.The p:xinclude step applies [] 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>

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml html 
          Option nameTypeDefault value
          fixup-xml-basexs:booleanfalse()
          fixup-xml-langxs:booleanfalse()
          Errors
          Error codeDescription
          err:C0029It is a dynamic error if an XInclude error occurs during processing.
          Declaration

          <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 [].The value of the fixup-xml-base option must be a boolean. If it is true, base URI fixup will be performed as per [].

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

          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 () if an XInclude error occurs during processing. It is a dynamic error () if an XInclude error occurs during processing.

          Document properties

          All document properties are preserved.

          2.47. 2.48. p:xquery

          The p:xquery step applies an XQuery query to the sequence of documents provided on the source port.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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          query  text xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          Option nameTypeDefault value
          parametersmap(xs:QName,item()*)?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0009It is a dynamic error if the specified XQuery version is not available.
          err:C0101It is a dynamic error 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.
          err:C0102It is a dynamic error 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.
          err:C0103It is a dynamic error if any error occurs during XQuery’s static analysis phase.
          err:C0104It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.
          Implementation details
          ImplementationDescription
          DefinedSupport for XQueryX is implementation-defined.
          DefinedIt is implementation-defined which XQuery version(s) is/are supported.
          DefinedThe point in time returned as the current dateTime is implementation-defined.
          DefinedThe implicit timezone is implementation-defined.
          DependentThe set of available documents (those that may be retrieved with a URI) is implementation-dependent.
          DependentThe set of available collections is implementation-dependent.
          Declaration

          <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.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: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 document root element is c:query, the text descendants of this element are considered the query.

            <c:query>
                string
            </c:query>

          • If the document root element is in the XQueryX namespace, the document is treated as an XQueryX-encoded query. Support for XQueryX is implementation-defined.

          • Otherwise the serialization of the document must be treated as the query. The document's serialization property (if present) is used.

          If the step specifies a version, then that version of XQuery must be used to process the transformation. It is a dynamic error () 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.If the step specifies a version, then that version of XQuery must be used to process the transformation. It is a dynamic error () 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.The name/value pairs in option parameters are used to set the query’s external variables.

          It is a dynamic error () 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 () 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 () 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 () 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 () if any error occurs during XQuery’s static analysis phase. It is a dynamic error () if any error occurs during XQuery’s dynamic evaluation phase.It is a dynamic error () if any error occurs during XQuery’s static analysis phase. It is a dynamic error () 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:

          Statically known default collection type

          document()*

          Statically known namespaces:

          Unchanged from the implementation defaults. No namespace declarations in the XProc pipeline are automatically exposed in the static context.

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

          Context item

          The first document that appears on the source port. The first document that appears on the source port.

          Context position

          1

          Context size

          1

          Variable values

          Any parameters passed in the parameters option augment any implementation-defined variable bindings known to the XQuery processor. Any parameters passed in the parameters option augment any implementation-defined variable bindings known to the XQuery processor.

          Function implementations

          The function implementations provided by the XQuery processor.

          Current dateTime

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

          Implicit timezone

          The implicit timezone is implementation-defined.

          Available documents

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

          Available collections

          The set of available collections is implementation-dependent.

          Default collection

          The sequence of documents provided on the source port. The sequence of documents provided on the source port.

          2.47.1. 2.48.1. Example

          The following pipeline applies XInclude processing and schema validation before using XQuery:

          Example 1. A Sample Pipeline Document
          <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>

          Where countp.xq might contain:

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

          2.47.2. 2.48.2. Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the query. If the query does not establish a base URI, the document will not have one.

          2.48. 2.49. p:xslt

          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>

          Summary

          Input portPrimarySequenceContent types
          source✔ ✔ any 
          stylesheet  xml 
          Output portPrimarySequenceContent types
          result✔ ✔ any 
          secondary ✔ any 
          Option nameTypeDefault value
          global-context-itemitem()?()
          initial-modexs:QName?()
          output-base-urixs:anyURI?()
          parametersmap(xs:QName,item()*)?()
          populate-default-collectionxs:boolean?true()
          static-parametersmap(xs:QName,item()*)?()
          template-namexs:QName?()
          versionxs:string?()
          Errors
          Error codeDescription
          err:C0007It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.
          err:C0008It is a dynamic error if the stylesheet does not support a given mode.
          err:C0038It is a dynamic error if the specified xslt version is not available.
          err:C0039It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.
          err:C0056It is a dynamic error if the stylesheet does not provide a given template.
          err:C0093 It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.
          err:C0094It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.
          err:C0095It is a dynamic error if an error occurred during the transformation.
          err:C0096It is a dynamic error if the transformation is terminated by XSLT message termination.
          err:C0105It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.
          err:C0121It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined which XSLT version(s) is/are supported.
          DefinedWhether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher).
          DependentHow XSLT message termination errors are reported to the XProc processor is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          DependentThe order in which result documents appear on the secondary port is implementation-dependent.
          Declaration

          <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 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 () 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.If the step specifies a version, then that version of XSLT must be used to process the transformation. It is a dynamic error () 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 () 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.The XSLT stylesheet provided on the stylesheet port is invoked. It is a dynamic error () 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.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 () if an error occurred during the transformation. It is a dynamic error () 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).It is a dynamic error () if an error occurred during the transformation. It is a dynamic error () 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.

          2.48.1. 2.49.1. Invoking an XSLT 3.0 stylesheet

          The value of global-context-item is used as global context item for the stylesheet invocation. If no value is supplied, the following applies:The value of global-context-item is used as global context item for the stylesheet invocation. If no value is supplied, the following applies:

          • If there is a single document on the source port, this document will become the value of the global-context-item option.If there is a single document on the source port, this document will become the value of the global-context-item option.

          • If there are none or multiple documents on the source port, the global context item is absent.If there are none or multiple documents on the source port, the global context item is absent.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          If no value is supplied for template-name option an “Apply-template invocation” is performed. The documents that appear on source are taken to be the initial match selection. if populate-default-collection is true, they are also the default collection. If a value is supplied for the initial-mode option, this value is used as the initial-mode for the invocation. It is a dynamic error () if the stylesheet does not support a given mode. If no value is supplied, nothing is supplied to the invocation, so the default behaviour defined for XSLT 3.0 could be applied.If no value is supplied for template-name option an “Apply-template invocation” is performed. The documents that appear on source are taken to be the initial match selection. if populate-default-collection is true, they are also the default collection. If a value is supplied for the initial-mode option, this value is used as the initial-mode for the invocation. It is a dynamic error () if the stylesheet does not support a given mode. If no value is supplied, nothing is supplied to the invocation, so the default behaviour defined for XSLT 3.0 could be applied.

          If a value is supplied for option template-name a “Call template invocation” is performed. The documents on port source are taken as the default collection in this case. Option initial-mode is ignored. It is a dynamic error () if the stylesheet does not provide a given template.If a value is supplied for option template-name a “Call template invocation” is performed. The documents on port source are taken as the default collection in this case. Option initial-mode is ignored. It is a dynamic error () if the stylesheet does not provide a given template.

          Independent of the way the stylesheet is invoked, the principal result(s) will appear on output port result while secondary result(s) will appear on output port secondary. The order in which result documents appear on the secondary port is implementation -dependent. Whether the raw results are delivered or a result tree is constructed, depends on the (explicit or implicit) setting for attribute build-tree of in the output-definition for the respective result. If a result tree is constructed, the result will be a text document if it is a single text node wrapped into a document node. Otherwise it will be either an XML document or an HTML document depending on the attribute method on the output-definition for the respective result. If no result tree is constructed, the stylesheet invocation may additionally deliver a sequence of atomic values, maps, or arrays. For each item in this sequence a JSON document will be constructed and appear on the steps output port.Independent of the way the stylesheet is invoked, the principal result(s) will appear on output port result while secondary result(s) will appear on output port secondary. The order in which result documents appear on the secondary port is implementation -dependent. Whether the raw results are delivered or a result tree is constructed, depends on the (explicit or implicit) setting for attribute build-tree of in the output-definition for the respective result. If a result tree is constructed, the result will be a text document if it is a single text node wrapped into a document node. Otherwise it will be either an XML document or an HTML document depending on the attribute method on the output-definition for the respective result. If no result tree is constructed, the stylesheet invocation may additionally deliver a sequence of atomic values, maps, or arrays. For each item in this sequence a JSON document will be constructed and appear on the steps output port.

          Option output-base-uri sets the base output URI per XSLT 3.0 specification. If a final result tree is constructed, this URI is used to resolve a relative URI reference. If no value is supplied for output-base-uri, the base URI of the first document in the source port's sequence is used. If no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].Option output-base-uri sets the base output URI per XSLT 3.0 specification. If a final result tree is constructed, this URI is used to resolve a relative URI reference. If no value is supplied for output-base-uri, the base URI of the first document in the source port's sequence is used. If no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].

          Note

          If no result tree is constructed for one of secondary results, a sequence of documents sharing the same value for attribute href may appear on output port result.If no result tree is constructed for one of secondary results, a sequence of documents sharing the same value for attribute href may appear on output port result.

          2.48.2. 2.49.2. Invoking an XSLT 2.0 stylesheet

          If a sequence of documents is provided on the source port, the first document is used as the initial context node. The whole sequence is also the default collection. If no documents are provided on the source port, the initial context node is undefined and the default collection is empty. It is a dynamic error () if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.If a sequence of documents is provided on the source port, the first document is used as the initial context node. The whole sequence is also the default collection. If no documents are provided on the source port, the initial context node is undefined and the default collection is empty. It is a dynamic error () if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.The populate-default-collection option is used to control whether all the documents appearing on source port form the default collection for the XSLT transformation.

          The value of option global-context-item is ignored if a stylesheet is invoked as per XSLT 2.0. 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 () if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function. It is a dynamic error () if the specified initial mode cannot be applied to the specified stylesheet. It is a dynamic error () if the specified template name cannot be applied to the specified stylesheet. The value of option global-context-item is ignored if a stylesheet is invoked as per XSLT 2.0. 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 () if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function. It is a dynamic error () if the specified initial mode cannot be applied to the specified stylesheet. It is a dynamic error () if the specified template name cannot be applied to the specified stylesheet.

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

          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 no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].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 no document is supplied on port source the base URI of the document on port stylesheet is used. It is a dynamic error () if a document appearing on the secondary port has a base URI that is not both absolute and valid according to [].

          2.48.3. 2.49.3. Invoking an XSLT 1.0 stylesheet

          The document provided for source is used the transformations source tree. It is a dynamic error () if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used. The values supplied for options global-context-item, initial-mode, and template-name are ignored. If XSLT 1.0 is used, an empty sequence of documents must appear on the secondary port. 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.The document provided for source is used the transformations source tree. It is a dynamic error () if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used. The values supplied for options global-context-item, initial-mode, and template-name are ignored. If XSLT 1.0 is used, an empty sequence of documents must appear on the secondary port. 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.

          The key/value pairs supplied in parameters are used to set top-level parameters in the stylesheet. If the value is an atomic value or a node, its string value is supplied to the stylesheet. It is a dynamic error () if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node. The key/value pairs supplied in parameters are used to set top-level parameters in the stylesheet. If the value is an atomic value or a node, its string value is supplied to the stylesheet. It is a dynamic error () if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          Document properties

          No document properties are preserved. The base-uri property of each document will reflect the base URI specified by the tranformation. If the transformation does not establish a base URI, the document will not have one.

          3. Step Errors

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

          A [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space).

          If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

          Dynamic errors raised by steps are divided into two categories: dynamic errors and step errors. The distinction is largely that “step errors” tend to be related to a particular step or small group of steps (e.g., validation error) whereas the “dynamic errors” apply to many more steps (e.g., URI not available). There is also precedent for some of the error codes dating back to XProc 1.0.

          Dynamic Errors
          err:XD0011

          It is a dynamic error if the resource referenced by the href option does not exist, cannot be accessed or is not a file.

          See: Handling of ZIP archives, p:load

          err:XD0023

          It is a dynamic error if a DTD validation is performed and either the document is not valid or no DTD is found.

          See: Loading XML data

          err:XD0043

          It is a dynamic error if the dtd-validate parameter is true and the processor does not support DTD validation.

          See: Loading XML data

          err:XD0049

          It is a dynamic error if the text value is not a well-formed XML document

          See: Casting from a text media type, Loading XML data

          err:XD0057

          It is a dynamic error if the text document does not conform to the JSON grammar, unless the parameter liberal is true and the processor chooses to accept the deviation.

          See: Casting from a text media type, Loading JSON data

          err:XD0058

          It is a dynamic error if the parameter duplicates is reject and the text document contains a JSON object with duplicate keys.

          See: Casting from a text media type, Loading JSON data

          err:XD0059

          It is a dynamic error if the parameter map contains an entry whose key is defined in the specification of fn:parse-json and whose value is not valid for that key, or if it contains an entry with the key fallback when the parameter escape with true() is also present.

          See: Casting from a text media type, Loading JSON data

          err:XD0060

          It is a dynamic error if the text document can not be converted into the XPath data model

          See: Casting from a text media type, Loading text data

          err:XD0062

          It is a dynamic error if the content-type is specified and the document-properties has a “content-type” that is not the same.

          See: p:load

          err:XD0064

          It is a dynamic error if the base URI is not both absolute and valid according to .

          See: p:archive, p:archive-manifest, p:load, p:make-absolute-uris, p:set-properties, p:unarchive

          err:XD0070

          It is a dynamic error 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 .

          See: p:set-properties

          err:XD0078

          It is a dynamic error if the loaded document cannot be represented as an HTML document in the XPath data model.

          See: Loading HTML data

          err:XD0079

          It is a dynamic error if a supplied content-type is not a valid media type of the form “type/subtype+ext” or “type/subtype”.

          See: Overriding content types, p:cast-content-type, p:http-request, p:http-request, p:load, p:text-join, p:uncompress

          Step Errors
          err:XC0001

          It is a dynamic error if the value of option override-content-type is not a text media type.

          See: p:text-join

          err:XC0003

          It is a dynamic error if a “username” or a “password” key is present without specifying a value for the “auth-method” key, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.

          See: p:http-request

          err:XC0007

          It is a dynamic error if any key in parameters is associated to a value which is not an instance of the XQuery 1.0 and XPath 2.0 Data Model, e.g. with a map, an array, or a function.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0008

          It is a dynamic error if the stylesheet does not support a given mode.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0009

          It is a dynamic error if the specified XQuery version is not available.

          See: p:xquery

          err:XC0013

          It is a dynamic error if the pattern matches a processing instruction and the new name has a non-null namespace.

          See: p:rename

          err:XC0014

          It is a dynamic error if the XML namespace (http://www.w3.org/XML/1998/namespace) or the XMLNS namespace (http://www.w3.org/2000/xmlns/) is the value of either the from option or the to option.

          See: p:namespace-rename

          err:XC0019

          It is a dynamic error if the documents are not equal according to the specified comparison method, and the value of the fail-if-not-equal option is true.

          See: p:compare

          err:XC0023

          It is a dynamic error if the selection pattern matches a node which is not an element.

          See: p:add-attribute, p:delete, p:insert, p:label-elements, p:make-absolute-uris, p:rename, p:replace, p:set-attributes, p:unwrap, p:wrap

          err:XC0024

          It is a dynamic error if the selection pattern matches a document node and the value of the position is “before” or “after”.

          See: p:insert

          err:XC0025

          It is a dynamic error 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”.

          See: p:insert

          err:XC0029

          It is a dynamic error if an XInclude error occurs during processing.

          See: p:xinclude

          err:XC0030

          It is a dynamic error if the response body cannot be interpreted as requested (e.g. application/json to override application/xml content).

          See: p:http-request

          err:XC0036

          It is a dynamic error if the requested hash algorithm is not one that the processor understands or if the value or parameters are not appropriate for that algorithm.

          See: p:hash

          err:XC0037

          It is a dynamic error if the value provided is not a properly x-www-form-urlencoded value.

          See: p:www-form-urldecode

          err:XC0038

          It is a dynamic error if the specified xslt version is not available.

          See: p:xslt

          err:XC0039

          It is a dynamic error if the source port does not contain exactly one XML document or one HTML document if XSLT 1.0 is used.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0050

          It is a dynamic error if the URI scheme is not supported or the step cannot store to the specified location.

          See: p:store

          err:XC0056

          It is a dynamic error if the stylesheet does not provide a given template.

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0058

          It is a dynamic error if the all and relative options are both true.

          See: p:add-xml-base

          err:XC0059

          It is a dynamic error if the QName value in the attribute-name option is “xmlns” or uses the prefix “xmlns” or any other prefix that resolves to the namespace name http://www.w3.org/2000/xmlns/.

          See: p:add-attribute, p:set-attributes

          err:XC0060

          It is a dynamic error if the processor does not support the specified version of the UUID algorithm.

          See: p:uuid

          err:XC0062

          It is a dynamic error if the match option matches a namespace node.

          See: p:delete

          err:XC0069

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

          See: p:set-properties

          err:XC0071

          It is a dynamic error if the p:cast-content-type step cannot perform the requested cast.

          See: p:cast-content-type

          err:XC0072

          It is a dynamic error if the c:data contains content is not a valid base64 string.

          See: Casting from an XML media type

          err:XC0073

          It is a dynamic error if the c:data element does not have a content-type attribute.

          See: Casting from an XML media type

          err:XC0074

          It is a dynamic error if the content-type is supplied and is not the same as the content-type specified on the c:data element.

          See: Casting from an XML media type

          err:XC0076

          It is a dynamic error if the comparison method specified in p:compare is not supported by the implementation.

          See: p:compare

          err:XC0077

          It is a dynamic error if the media types of the documents supplied are incompatible with the comparison method.

          See: p:compare

          err:XC0078

          It is a dynamic error if the value associated with the “fail-on-timeout” is associated with true() and a HTTP status code 408 is encountered.

          See: p:http-request

          err:XC0079

          It is a dynamic error if the map parameters contains an entry whose key is defined by the implementation and whose value is not valid for that key.

          See: p:archive, p:archive-manifest, p:cast-content-type, p:compress, p:unarchive, p:uncompress

          err:XC0080

          It is a dynamic error if the number of documents on the archive does not match the expected number of archive input documents for the given format and command.

          See: Handling of ZIP archives

          err:XC0081

          It is a dynamic error if the format of the archive does not match the format as specified in the format option.

          See: p:archive, p:archive-manifest

          err:XC0084

          It is a dynamic error if two or more documents appear on the p:archive step's source port that have the same base URI or if any document that appears on the source port has no base URI.

          See: p:archive

          err:XC0085

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

          See: p:archive, p:archive-manifest, p:unarchive

          err:XC0092

          It is a dynamic error if as a consequence of changing or removing the namespace of an attribute the attribute's name is not unique on the respective element.

          See: p:namespace-rename

          err:XC0093

          It is a dynamic error if a static error occurs during the static analysis of the XSLT stylesheet.

          See: p:xslt

          err:XC0094

          It is a dynamic error if any document supplied on the source port is not an XML document, an HTML documents, or a Text document if XSLT 2.0 is used.

          See: Invoking an XSLT 2.0 stylesheet

          err:XC0095

          It is a dynamic error if an error occurred during the transformation.

          See: p:xslt

          err:XC0096

          It is a dynamic error if the transformation is terminated by XSLT message termination.

          See: p:xslt

          err:XC0098

          It is a dynamic error if a dynamic XPath error occurred while applying sort-key to a line.

          See: p:text-sort

          err:XC0099

          It is a dynamic error if the result of applying sort-key to a given line results in a sequence with more than one item.

          See: p:text-sort

          err:XC0100

          It is a dynamic error if the document on port manifest does not conform to the given schema.

          See: p:archive, The archive manifest

          err:XC0101

          It is a dynamic error 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.

          See: p:xquery

          err:XC0102

          It is a dynamic error 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.

          See: p:xquery

          err:XC0103

          It is a dynamic error if any error occurs during XQuery’s static analysis phase.

          See: p:xquery

          err:XC0104

          It is a dynamic error if any error occurs during XQuery’s dynamic evaluation phase.

          See: p:xquery

          err:XC0105

          It is a dynamic error if an XSLT 1.0 stylesheet is invoked and option parameters contains a value that is not an atomic value or a node.

          See: Invoking an XSLT 1.0 stylesheet

          err:XC0106

          It is a dynamic error if duplicate keys are encountered and option duplicates has value “reject”.

          See: p:json-merge

          err:XC0107

          It is a dynamic error if a document of a not supported document type appears on port source of p:json-merge.

          See: p:json-merge

          err:XC0108

          It is a dynamic error if any prefix is not in-scope at the point where the p:namespace-delete occurs.

          See: p:namespace-delete

          err:XC0109

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

          See: p:namespace-delete

          err:XC0110

          It is a dynamic error if the evaluation of the XPath expression in option key for a given item returns either a sequence, an array, a map, or a function.

          See: p:json-merge

          err:XC0111

          It is a dynamic error if a document of an unsupported document type appears on port source of p:json-join.

          See: p:json-join

          err:XC0112

          It is a dynamic error if more than one document appears on the port manifest.

          See: p:archive

          err:XC0118

          It is a dynamic error if an archive manifest is invalid according to the specification.

          See: The archive manifest

          err:XC0119

          It is a dynamic error if flatten is neither “unbounded”, nor a string that may be cast to a non-negative integer.

          See: p:json-join

          err:XC0120

          It is a dynamic error if the relative-to option is not present and the document on the source port does not have a base URI.

          See: p:archive-manifest, p:unarchive

          err:XC0121

          It is a dynamic error if a document appearing on the secondary port has a base URI that is not both absolute and valid according to .

          See: Invoking an XSLT 3.0 stylesheet, Invoking an XSLT 2.0 stylesheet

          err:XC0122

          It is a dynamic error if the given method is not supported.

          See: p:http-request

          err:XC0123

          It is a dynamic error if any key in the “auth” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0124

          It is a dynamic error if any key in the “parameters” map is associated with a value that is not an instance of the required type.

          See: p:http-request

          err:XC0125

          It is a dynamic error if the key “accept-multipart” as the value false() and a multipart response is detected.

          See: p:http-request

          err:XC0126

          It is a dynamic error if the XPath expression in assert evaluates to false.

          See: p:http-request

          err:XC0127

          It is a dynamic error if the headers map contains two keys that are the same when compared in a case-insensitive manner.

          See: p:http-request

          err:XC0128

          It is a dynamic error if the URI’s scheme is unknown or not supported.

          See: p:http-request

          err:XC0131

          It is a dynamic error if the processor cannot support the requested encoding.

          See: p:http-request

          err:XC0132

          It is a dynamic error if the override content encoding cannot be supported.

          See: p:http-request

          err:XC0133

          It is a dynamic error if more than one document appears on the source port and a content-type header is present and the content type specified is not a multipart content type.

          See: Construction of a multipart request

          err:XC0146

          It is a dynamic error if the specified value for the override-content-types option is not an array of arrays, where the inner arrays have exactly two members of type xs:string.

          See: Overriding content types

          err:XC0147

          It is a dynamic error if the specified value is not a valid XPath regular expression.

          See: Overriding content types, p:text-replace, p:unarchive

          err:XC0150

          It is a dynamic error if evaluating the XPath expression in option test on a context document results in an error.

          See: p:split-sequence

          err:XC0201

          It is a dynamic error if the p:uncompress step cannot perform the requested content-type cast.

          See: p:uncompress

          err:XC0202

          It is a dynamic error if the compression format cannot be understood, determined and/or processed.

          See: p:compress, p:uncompress

          err:XC0203

          It is a dynamic error if the specified boundary is not valid (for example, if it begins with two hyphens “--”).

          See: Construction of a multipart request

          A. Conformance

          Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

          [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

          [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

          A.1. Implementation-defined features

          The following features are implementation-defined:

          1. The list of formats supported by the p:archive step is implementation-defined. See Section 2.3, “p:archive”.
          2. The list of archive formats that can be modified by p:archive is implementation-defined. See Section 2.3, “p:archive”.
          3. The semantics of any additional attributes, elements and their values are implementation-defined. See Section 2.3, “p:archive”.
          4. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          5. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.3, “p:archive”.
          6. It is implementation-defined what other formats are supported. See Section 2.3, “p:archive”.
          7. It is implementation-defined how the step determines the archive's format. See Section 2.3, “p:archive”.
          8. The c:archive root element may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          9. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          10. It is implementation-defined what other compression methods are supported. See Section 2.3.1, “The archive manifest”.
          11. The default compression method is implementation-defined. See Section 2.3.1, “The archive manifest”.
          12. It is implementation-defined what compression levels are supported. See Section 2.3.1, “The archive manifest”.
          13. The c:entry elements may contain additional implementation-defined attributes. See Section 2.3.1, “The archive manifest”.
          14. The p:archive step may support additional, implementation-defined commands for ZIP files. See Section 2.3.2, “Handling of ZIP archives”.
          15. The actual parameter names supported by p:archive for a particular format are implementation-defined. See Section 2.3.2, “Handling of ZIP archives”.
          16. It is implementation-defined what other formats are supported. See Section 2.4, “p:archive-manifest”.
          17. It is implementation-defined how the step determines the archive's format. See Section 2.4, “p:archive-manifest”.
          18. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.4, “p:archive-manifest”.
          19. Additional information provided for entries in p:archive-manifest is implementation-defined. See Section 2.4, “p:archive-manifest”.
          20. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.5, “p:cast-content-type”.
          21. The precise nature of the conversion from XML to JSON is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          22. Casting from an XML media type to any other media type when the input document is not a c:data document is implementation-defined. See Section 2.5.1, “Casting from an XML media type”.
          23. Casting from an HTML media type to a JSON media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          24. Casting from an HTML media type to any other media type is implementation-defined. See Section 2.5.2, “Casting from an HTML media type”.
          25. It is implementation-defined whether other result formats are supported. See Section 2.5.3, “Casting from a JSON media type”.
          26. Casting from a JSON media type to an HTML media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          27. Casting from a JSON media type to any other media type is implementation-defined. See Section 2.5.3, “Casting from a JSON media type”.
          28. The precise way in which text documents are parsed into the XPath data model is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          29. Casting from a text media type to any other media type is implementation-defined. See Section 2.5.4, “Casting from a text media type”.
          30. Casting from any other media type to a HTML media type, a JSON media type or a text document is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          31. Casting from any other media type to any other media type is implementation-defined. See Section 2.5.5, “Casting from any other media type”.
          32. Implementations of p:compare must support the deep-equal method; other supported methods are implementation-defined. See Section 2.6, “p:compare”.
          33. 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. See Section 2.6, “p:compare”.
          34. It is implementation-defined what other formats are supported. See Section 2.7, “p:compress”.
          35. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.7, “p:compress”.
          36. It is implementation-defined what other algorithms are supported. See Section 2.12, “p:hash”.
          37. It is implementation-defined which HTTP methods are supported. See Section 2.13, “p:http-request”.
          38. The interpretation of values associated with the “auth-method” key other than “Basic” or “Digest” is implementation-defined. See Section 2.13, “p:http-request”.
          39. Other key value pairs in map “auth” are implementation-defined. See Section 2.13, “p:http-request”.
          40. It is implementation-defined which other key/value pairs in the parameters option are supported. See Section 2.13, “p:http-request”.
          41. The default behaviour in case of a redirect response is implementation-defined. See Section 2.13, “p:http-request”.
          42. It is implementation-defined how a multipart boundary is constructed. See Section 2.13.1, “Construction of a multipart request”.
          43. It is implementation-defined if p:json-join is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.16, “p:json-join”.
          44. It is implementation-defined if p:json-merge is able to process document types not mentioned yet, i.e. types of binary documents. See Section 2.17, “p:json-merge”.
          45. In the absence of an explicit type, the content type is implementation-defined See Section 2.19, “p:load”.
          46. Additional XML parameters are implementation-defined. See Section 2.19.1, “Loading XML data”.
          47. Text parameters are implementation-defined. See Section 2.19.2, “Loading text data”.
          48. Additional JSON parameters are implementation-defined. See Section 2.19.3, “Loading JSON data”.
          49. The precise way in which HTML documents are parsed into the XPath data model is implementation-defined. See Section 2.19.4, “Loading HTML data”.
          50. HTML parameters are implementation-defined. See Section 2.19.4, “Loading HTML data”.
          51. How a processor interprets other media types is implementation-defined. See Section 2.19.5, “Loading binary data”.
          52. Parameters for other media types are implementation-defined. See Section 2.19.5, “Loading binary data”.
          53. Support for other collations is implementation-defined. See Section 2.362.37, “p:text-sort”.
          54. It is implementation-defined what other formats are supported. See Section 2.382.39, “p:unarchive”.
          55. It is implementation-defined how the step determines the archive's format. See Section 2.382.39, “p:unarchive”.
          56. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.382.39, “p:unarchive”.
          57. It is implementation-defined what other formats are supported. See Section 2.392.40, “p:uncompress”.
          58. It is implementation-defined how the step determines the compression format. See Section 2.392.40, “p:uncompress”.
          59. The semantics of the keys and the allowed values for these keys are implementation-defined. See Section 2.392.40, “p:uncompress”.
          60. If the version is not specified, the version of UUID computed is implementation-defined. See Section 2.412.42, “p:uuid”.
          61. Support for other versions of UUID, and the mechanism by which the necessary inputs are made available for computing other versions, is implementation-defined. See Section 2.41, “p:uuid”.
          62. Support for other versions of UUID is implementation-defined. See Section 2.42, “p:uuid”.
          63. The names and values of parameters to p:uuid are implementation-defined. See Section 2.42, “p:uuid”.
          64. Support for XQueryX is implementation-defined. See Section 2.472.48, “p:xquery”.
          65. It is implementation-defined which XQuery version(s) is/are supported. See Section 2.48, “p:xquery”.
          66. The point in time returned as the current dateTime is implementation-defined. See Section 2.472.48, “p:xquery”.
          67. The implicit timezone is implementation-defined. See Section 2.472.48, “p:xquery”.
          68. It is implementation-defined which XSLT version(s) is/are supported. See Section 2.482.49, “p:xslt”.
          69. Whether static parameters are supported is implementation-defined and depends on the XSLT version (which must be 3.0 or higher). See Section 2.482.49, “p:xslt”.

          A.2. Implementation-dependent features

          The following features are implementation-dependent:

          1. 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. See Section 2.20, “p:make-absolute-uris”.
          2. The set of available documents (those that may be retrieved with a URI) is implementation-dependent. See Section 2.472.48, “p:xquery”.
          3. The set of available collections is implementation-dependent. See Section 2.472.48, “p:xquery”.
          4. How XSLT message termination errors are reported to the XProc processor is implementation-dependent. See Section 2.482.49, “p:xslt”.
          5. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.
          6. The order in which result documents appear on the secondary port is implementation-dependent. See Section 2.49, “p:xslt”.

          B. References

          B.1. Normative References

          [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

          [W3C XML Schema: Part 2] XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, editors. World Wide Web Consortium, 28 October 2004.

          [XPath 3.1] XML Path Language (XPath) 3.1. Jonathan Robie, Michael Dyck, Josh Spiegel, editors. W3C Recommendation. 21 March 2017.

          [XPath and XQuery Functions and Operators 3.1] XPath and XQuery Functions and Operators 3.1. Michael Kay, editor. W3C Recommendation. 21 March 2017

          [XSLT 3.0] XSL Transformations (XSLT) Version 3.0. Michael Kay, editor. W3C Recommendation. 8 June 2017.

          [XInclude] XML Inclusions (XInclude) Version 1.0 (Second Edition). Jonathan Marsh, David Orchard, and Daniel Veillard, editors. W3C Recommendation. 15 November 2006.

          [RFC 1321] RFC 1321: The MD5 Message-Digest Algorithm. R. Rivest. Network Working Group, IETF, April 1992.

          [RFC 2046] RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein, editors. Internet Engineering Task Force. November, 1996.

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

          [RFC 2617] RFC 2617: HTTP Authentication: Basic and Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. June, 1999 .

          [RFC 3986] RFC 3986: Uniform Resource Identifier (URI): General Syntax. T. Berners-Lee, R. Fielding, and L. Masinter, editors. Internet Engineering Task Force. January, 2005.

          [RFC 4646] RFC 4646: Tags for Identifying Languages. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [RFC 4647] RFC 4647: Matching of Language Tags. A. Phillips and M. Davis, editors. Internet Engineering Task Force. September, 2006.

          [BCP 47] Best Current Practices 47. Concatenation of RFC 4646: Tags for Identifying Languages, ed. A. Phillips and M. Davis, September 2006, http://www.ietf.org/rfc/bcp/bcp47.txt, and RFC 4647: Matching of Language Tags, ed. A Phillips and M. Davis, September 2006, http://www.rfc-editor.org/rfc/bcp/bcp47.txt. Internet Engineering Task Force (IETF). September, 2006.

          [CRC32] “32-Bit Cyclic Redundancy Codes for Internet Applications”, The International Conference on Dependable Systems and Networks: 459. 10.1109/DSN.2002.1028931. P. Koopman. June 2002.

          C. Glossary

          dynamic error

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

          implementation-defined

          An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

          implementation-dependent

          An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

          D. Ancillary files

          This specification includes by reference a number of ancillary files.

          steps.xpl

          An XProc step library for the declared steps.

          E. Credits

          This document is derived from XProc: An XML Pipeline Language published by the W3C. It was developed by the XML Processing Model Working Group and edited by Norman Walsh, Alex Miłowski, and Henry Thompson.

          The editors of this specification extend their gratitude to everyone who contributed to this document and all of the versions that came before it.

          F. Change Log

          This appendix catalogs non-editorial changes made after the August 2020 “last call” draft:

          1. Allow the output of the p:insert step to be text. (issue 583.)

          2. Clarified that the manifest has precedence in the p:archive step. (issue 462.)

          3. Changed the type of several options from xs:token to xs:string (issue 490.)

          4. Changed the type of the parameters option from map(xs:string,xs:untypedAtomic+) to map(xs:string,xs:anyAtomicType+). (issue .) Changed the type of the parameters option from map(xs:string,xs:untypedAtomic+) to map(xs:string,xs:anyAtomicType+). (issue .)

          These are the non-editorial changes made after the February 2020 “last call” draft:

          1. For p:cast-content-type the expected result type for casting a c:param-set document to “application/json” was specified as map(xs:QName, xs:string). (2020-03-15)

          2. In p:http-request, instead of using all document properties (with a few explicit exceptions) as headers, only document properties in the http://www.w3.org/ns/xproc-http namespace will be used. (2020-03-18)

          3. Section 2.3.1, “The archive manifest”: An attribute c:entry/@content-type was added to the archive manifest, to be filled by the p:archive-manifest step. (2020-03-20)

          4. A static-parameters was added to . (2020-03-23)A static-parameters was added to . (2020-03-23)

          5. The override-content-types option was added to and . (2020-03-30)The override-content-types option was added to and . (2020-03-30)

          6. Clarified the regular expression matching for p:text-replace and p:unarchive. Added an error code for invalid regular expressions. (2020-04-02)

          7. Replaced errors XC0070 and XC0130 with XD0079. (2020-04-09)

          8. Changed signature of p:split-sequence so that any document can appear one port source. (2020-05-22)

          9. Change the behavior of the global-context-item option of . (2020-06-10)Change the behavior of the global-context-item option of . (2020-06-10)

          10. Clarified which steps may produce PSVI annotations. (2020-06-09)

          11. Clarified the behaviour in p:archive: A missing resource referenced by c:archive/c:entry/@href is only an error for command = 'create'. (2020-06-11)

          12. Option populate-default-collection is added to the signature of . (2020-06-20)Option populate-default-collection is added to the signature of . (2020-06-20)

          13. Clarified how the default content-type header of is constructed if a single document appears on source port. (2020-06-20)Clarified how the default content-type header of is constructed if a single document appears on source port. (2020-06-20)

          14. Added error (XD0079) to p:http-request and p:load for invalid content-types. (2020-06-23)

          15. Changed signature of the result port of to sequence="false" and adapted the prose accordingly. (2020-06-24)Changed signature of the result port of to sequence="false" and adapted the prose accordingly. (2020-06-24)

          \ No newline at end of file diff --git a/master/head/text/diff.html b/master/head/text/diff.html index 5b7ec912f..0bb3aef3b 100644 --- a/master/head/text/diff.html +++ b/master/head/text/diff.html @@ -15,4 +15,4 @@ Previous Next -

          XProc 3.0: text steps

          Draft Community Group Report

          Editor's Draft at (build 4547)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/text/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: text steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the optional text related steps for XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

          If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

          1. Introduction

          This specification describes the optional text related XProc steps. A machine-readable description of these steps may be found in steps.xpl.

          Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

          2. p:markdown-to-html

          The p:markdown-to-html step converts a text document in Markdown to XHTML.

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  html 
          Option nameTypeDefault value
          parametersmap(xs:QName, item()*)?()
          Implementation details
          ImplementationDescription
          DefinedThe flavor(s) of Markdown supported and the parameters allowed are implementation-defined.
          Declaration

          <p:declare-steptype="p:markdown-to-html">
               <p:inputport="source"primary="true"content-types="text"/>
               <p:outputport="result"primary="true"content-types="html"/>
               <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
          </p:declare-step>

          The p:markdown-to-html step transforms a text document containing Markdown, for example [CommonMark], into HTML. The flavor(s) of Markdown supported and the parameters allowed are implementation-defined.

          Document properties

          No document properties are preserved.

          A. Conformance

          Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

          [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

          [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

          A.1. Implementation-defined features

          The following features are implementation-defined:

          1. The flavor(s) of Markdown supported and the parameters allowed are implementation-defined. See Section 2, “p:markdown-to-html”.

          C. Glossary

          implementation-defined

          An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

          implementation-dependent

          An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

          D. Ancillary files

          This specification includes by reference a number of ancillary files.

          steps.xpl

          An XProc step library for the declared steps.

          \ No newline at end of file +

          XProc 3.0: text steps

          Draft Community Group Report

          Editor's Draft at (build 4546)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/text/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: text steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the optional text related steps for XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

          If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

          1. Introduction

          This specification describes the optional text related XProc steps. A machine-readable description of these steps may be found in steps.xpl.

          Familarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

          2. p:markdown-to-html

          The p:markdown-to-html step converts a text document in Markdown to XHTML.

          Summary

          Input portPrimarySequenceContent types
          source✔  text 
          Output portPrimarySequenceContent types
          result✔  html 
          Option nameTypeDefault value
          parametersmap(xs:QName, item()*)?()
          Implementation details
          ImplementationDescription
          DefinedThe flavor(s) of Markdown supported and the parameters allowed are implementation-defined.
          Declaration

          <p:declare-steptype="p:markdown-to-html">
               <p:inputport="source"primary="true"content-types="text"/>
               <p:outputport="result"primary="true"content-types="html"/>
               <p:optionname="parameters"as="map(xs:QName, item()*)?"/>    
          </p:declare-step>

          The p:markdown-to-html step transforms a text document containing Markdown, for example [CommonMark], into HTML. The flavor(s) of Markdown supported and the parameters allowed are implementation-defined.

          Document properties

          No document properties are preserved.

          A. Conformance

          Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

          [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

          [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

          A.1. Implementation-defined features

          The following features are implementation-defined:

          1. The flavor(s) of Markdown supported and the parameters allowed are implementation-defined. See Section 2, “p:markdown-to-html”.

          C. Glossary

          implementation-defined

          An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

          implementation-dependent

          An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

          D. Ancillary files

          This specification includes by reference a number of ancillary files.

          steps.xpl

          An XProc step library for the declared steps.

          \ No newline at end of file diff --git a/master/head/text/index.html b/master/head/text/index.html index 909a1baae..ddffb205e 100644 --- a/master/head/text/index.html +++ b/master/head/text/index.html @@ -1,4 +1,4 @@ -XProc 3.0: text steps

          XProc 3.0: text steps

          Draft Community Group Report

          Editor's Draft at (build 47)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/text/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: text steps specification, published by the XProc Next Community Group under the W3C +XProc 3.0: text steps

          XProc 3.0: text steps

          Draft Community Group Report

          Editor's Draft at (build 46)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/text/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: text steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the optional text related steps for XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          diff --git a/master/head/validation/diff.html b/master/head/validation/diff.html index 1450943bf..86598a0d4 100644 --- a/master/head/validation/diff.html +++ b/master/head/validation/diff.html @@ -15,4 +15,4 @@ Previous Next -

          XProc 3.0: validation steps

          Draft Community Group Report

          Editor's Draft at (build 4547)
          Latest editor’s draft:
          https://spec.xproc.org/master/head/validation/
          Editors:
          Norman Walsh
          Achim Berndzen
          Gerrit Imsieke
          Erik Siegel
          Participate:
          GitHub xproc/3.0-steps
          Report an issue
          Changes:
          Diff against current “status quo” draft
          Commits for this specification

          This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

          Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: validation steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

          Abstract

          This specification describes the p:validate-with-nvdl, p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, p:validate-with-json-schema, and p:validate-with-dtd step for XProc 3.0: An XML Pipeline Language.

          Status of this Document

          This document is an editor's draft that has no official standing.

          This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

          If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

          This document is derived from XProc: An XML Pipeline Language published by the W3C.

          1. Introduction

          This specification describes the p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, p:validate-with-nvdl, and p:validate-with-json-schema, and p:validate-with-dtd steps. Each is independently optional. A machine-readable description of these steps may be found in steps.xpl.

          Familiarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

          As described in PSVIs in XProc in XProc 3.0: An XML Pipeline Language, steps may not produce PSVI output unless that behavior is explicitly described. In this specification, the steps that may produce PSVI output are p:validate-with-nvdl, p:validate-with-schematron and p:validate-with-xml-schema.

          2. Common Options and Outputs

          All steps in this specification provide a boolean option assert-valid. If any of the validated documents is found to be invalid according to the respective schema, and possibly other parameters that influence determination of validity, a dynamic error is raised.

          Note

          Historically, the validation steps (apart from p:validate-with-schematron) could only report errors by setting assert-valid to true and catching the errors. A c:errors document on the error port of the corresponding p:catch recovery pipeline had to be sent to an output, either verbatim or after postprocessing. Now, if assert-valid is false, an XVRL document will be available on the report port of the validation step. It uses the XVRL severity vocabulary to indicate whether the validation failed, and to which degree. This allows more nuance in reporting errors. Previously, assert-valid="true" on p:validate-with-schematron would always throw an error even if the reported findings were only intended as less severe, for example if the schema author used info or warning in sch:report/@role.

          If no such error is raised, each step generates at least one validation report document on its report port. Unless another format is requested, the mandatory report document for all steps except p:validate-with-schematronshould be an [XVRL] document. A report format may be requested by the report-format option. The supported values for the report-format option are implementation-defined. A processor should at least support the value “xvrl” for the XML validation steps and “svrl” for p:validate-with-schematron.

          It is a dynamic error (err:XC0117) if a report-format option was specified that the processor does not support.

          If a step performs multiple validations on a single document (for example, embedded Schematron validations in a Relax NG schema), all individual XVRL reports need to be consolidated into a single XVRL report by the step.

          Each of the validation steps has a parameters option. The parameters supported by the validation steps and their semantics are implementation-defined, and they can be different for each validation step. A special key in the c namespace, http://www.w3.org/ns/xproc-step, called c:compile, can hold a map itself that controls schema compilation. Schema compilation is, for example, the process of converting a Schematron schema into an XSLT stylesheet. The c:compile map will be used as parameters for the compilation process.

          Map entries in the xvrl namespace, http://www.xproc.org/ns/xvrl will be passed as parameters to the XVRL generation process. XProc implementations that implement any of the XML validation steps should support the basic parameters that are defined in the [XVRL] specification, xvrl:default-severity, xvrl:language, xvrl:map-to-severity, and xvrl:xpath-notation.

          3. Validate with NVDL

          The p:validate-with-nvdl step applies [NVDL] validation to the source document.

          Summary

          Input portPrimarySequenceContent typesDefault binding
          source✔  xml html 
          nvdl  xml 
          schemas ✔ text xml p:empty
          Output portPrimarySequenceContent typesDefault binding
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          parametersmap(xs:QName,item()*)?()
          report-formatxs:string'xvrl'
          Errors
          Error codeDescription
          err:C0053It is a dynamic error if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.
          err:C0154It is a dynamic error if the document supplied on nvdl port is not a valid NVDL document.
          Declaration

          <p:declare-steptype="p:validate-with-nvdl">     <p:inputport="source"primary="true"content-types="xml html"/>     <p:inputport="nvdl"content-types="xml"/>     <p:inputport="schemas"sequence="true"content-types="text xml">          <p:empty/>     </p:input>     <p:outputport="result"primary="true"content-types="xml html"/>     <p:outputport="report"sequence="true"content-types="xml json"/>     <p:optionname="assert-valid"select="true()"as="xs:boolean"/>     <p:optionname="report-format"select="'xvrl'"as="xs:string"/>     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     </p:declare-step>

          The source document is validated using the namespace dispatching rules contained in the nvdl document. It is a dynamic error (err:XC0154) if the document supplied on nvdl port is not a valid NVDL document.

          The dispatching rules may contain URI references that point to the actual schemas to be used. As long as these schemas are accessible, it is not necessary to pass anything on the schemas port. However, if one or more schemas are provided on the schemas port, then these schemas should be used in validation.

          It is a dynamic error (err:XC0053) if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.

          The output from this step is a copy of the input. The output of this step may include PSVI annotations.

          Note

          Should the step also provide the dtd-attribute-values and dtd-id-idref-warnings options for Relax NG validations? Is there a way to instruct Jing to use these options, maybe in NVDL extension attributes? Probably not in the foreseeable future.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties on the schemas and nvdl ports are preserved. No document properties are preserved on the report port.

          4. Validate with RELAX NG

          The p:validate-with-relax-ng step applies [RELAX NG] validation to the source document.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          schema  text xml 
          Output portPrimarySequenceContent types
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          dtd-attribute-valuesxs:booleanfalse()
          dtd-id-idref-warningsxs:booleanfalse()
          parametersmap(xs:QName,item()*)?()
          report-formatxs:string'xvrl'
          Errors
          Error codeDescription
          err:C0153It is a dynamic error if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.
          err:C0155It is a dynamic error if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.
          Implementation details
          ImplementationDescription
          DefinedSupport for is implementation-defined.
          Declaration

          <p:declare-steptype="p:validate-with-relax-ng">     <p:inputport="source"primary="true"content-types="xml html"/>     <p:inputport="schema"content-types="text xml"/>     <p:outputport="result"primary="true"content-types="xml html"/>     <p:outputport="report"sequence="true"content-types="xml json"/>     <p:optionname="dtd-attribute-values"select="false()"as="xs:boolean"/>     <p:optionname="dtd-id-idref-warnings"select="false()"as="xs:boolean"/>     <p:optionname="assert-valid"select="true()"as="xs:boolean"/>     <p:optionname="report-format"select="'xvrl'"as="xs:string"/>     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     </p:declare-step>

          The values of the dtd-attribute-values and dtd-id-idref-warnings options must be booleans.

          If the schema document has an XML media type, then it must be interpreted as a RELAX NG Grammar. If the schema document has a text media type, then it must be interpreted as a [RELAX NG Compact Syntax] document for validation. It is a dynamic error (err:XC0153) if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.

          If the dtd-attribute-values option is true, then the attribute value defaulting conventions of [RELAX NG DTD Compatibility] are also applied.

          If the dtd-id-idref-warnings option is true, then the validator should treat a schema that is incompatible with the ID/IDREF/IDREFs feature of [RELAX NG DTD Compatibility] as if the document was invalid.

          It is a dynamic error (err:XC0155) if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.

          The output from this step is a copy of the input, possibly augmented by application of the [RELAX NG DTD Compatibility]. The output of this step may include PSVI annotations.

          Support for [RELAX NG DTD Compatibility] is implementation-defined.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties on the schema port are preserved. No document properties are preserved on the report port.

          5. Validate with Schematron

          The p:validate-with-schematron step applies [Schematron] processing to the source document.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          schema  xml 
          Output portPrimarySequenceContent types
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          parametersmap(xs:QName,item()*)?()
          phasexs:string'#DEFAULT'
          report-formatxs:string'svrl'
          Errors
          Error codeDescription
          err:C0054It is a dynamic error if the assert-valid option is true and any Schematron assertions fail.
          err:C0151It is a dynamic error if the document supplied on schema port is not a valid Schematron document.
          Implementation details
          ImplementationDescription
          DefinedHow the Schematron implementation is selected is implementation-defined.
          DefinedThe list of supported Schematron implementations and their associated values is implementation-defined.
          DefinedWhich parameters the c:compile map supports for a given Schematron implementation is implementation-defined.
          DefinedWhich parameters this conversion from native reporting format to XVRL supports is implementation-defined.
          Declaration

          <p:declare-steptype="p:validate-with-schematron">     <p:inputport="source"primary="true"content-types="xml html"/>     <p:inputport="schema"content-types="xml"/>     <p:outputport="result"primary="true"content-types="xml html"/>     <p:outputport="report"sequence="true"content-types="xml json"/>     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>          <p:optionname="phase"select="'#DEFAULT'"as="xs:string"/>        <p:optionname="assert-valid"select="true()"as="xs:boolean"/>     <p:optionname="report-format"select="'svrl'"as="xs:string"/></p:declare-step>

          It is a dynamic error (err:XC0151) if the document supplied on schema port is not a valid Schematron document.

          It is a dynamic error (err:XC0054) if the assert-valid option is true and any Schematron assertions fail.

          Note

          A Schematron validation with assert-valid="true" will fail if any validation message is produced by sch:assert or sch:report, even if the severity level of the failed assertion or the successful report is below a certain threshold, for example if there is only an info message. (The severity is conventionally conveyed by the @role attribute on sch:assert or sch:report.)

          The value of the phase option identifies the Schematron validation phase with which validation begins.

          The parameters option provides name/value pairs which correspond to Schematron external variables, to parameters that influence code generation, or to parameters that influence SVRL to XVRL conversion.

          There are multiple Schematron implementations. How the Schematron implementation is selected is implementation-defined. A processor might select an implementation based on the schema’s queryBinding attribute and/or provide configuration options. In addition, the special parameter map entry c:implementation (value: QName) may be used to select a Schematron implementation that the processor supports. The list of supported Schematron implementations and their associated values is implementation-defined. If a requested implementation is not available, the processor may throw an error or select another implementation.

          The parameters map may contain two special entries, c:compile and c:xvrl, both are maps. If a code-generating implementation such as [Schematron Skeleton] is used, the entries of the c:compile map, for example allow-foreign, will be passed to the code generator. Which parameters the c:compile map supports for a given Schematron implementation is implementation-defined.

          If the Schematron implementation produces SVRL by default, the SVRL to XVRL conversion can be influenced by the entries of the c:xvrl map. The same map, with potentially another set of allowed keys and values, can be used to influence XVRL generation from another reporting language. Which parameters this conversion from native reporting format to XVRL supports is implementation-defined.

          All other parameters of the parameters option will be passed to the generated code if applicable, or to a hypothetical native Schematron validator that does without code generation.

          The result output from this step is a copy of the input.

          The output of this step may include PSVI annotations.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties on the schema port are preserved. No document properties are preserved on the report port.

          6. Validate with XML Schema

          The p:validate-with-xml-schema step applies [W3C XML Schema: Part 1] validity assessment to the source input.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          schema ✔ xml 
          Output portPrimarySequenceContent types
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeValuesDefault value
          assert-validxs:boolean true()
          modexs:string('strict','lax') 'strict'
          parametersmap(xs:QName,item()*)? ()
          report-formatxs:string 'xvrl'
          try-namespacesxs:boolean false()
          use-location-hintsxs:boolean false()
          versionxs:string? ()
          Errors
          Error codeDescription
          err:C0011It is a dynamic error if the specified schema version is not available.
          err:C0055It is a dynamic error if the implementation does not support the specified mode.
          err:C0152It is a dynamic error if the document supplied on schema port is not a valid XML schema document.
          err:C0156It is a dynamic error if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided.
          Declaration

          <p:declare-steptype="p:validate-with-xml-schema">     <p:inputport="source"primary="true"content-types="xml html"/>     <p:inputport="schema"sequence="true"content-types="xml"/>     <p:outputport="result"primary="true"content-types="xml html"/>     <p:outputport="report"sequence="true"content-types="xml json"/>     <p:optionname="use-location-hints"select="false()"as="xs:boolean"/>     <p:optionname="try-namespaces"select="false()"as="xs:boolean"/>     <p:optionname="assert-valid"select="true()"as="xs:boolean"/>     <p:optionname="parameters"as="map(xs:QName,item()*)?"/>          <p:optionname="mode"select="'strict'"values="('strict','lax')"/><!-- string -->     <p:optionname="version"as="xs:string?"/>                         <p:optionname="report-format"select="'xvrl'"as="xs:string"/></p:declare-step>

          It is a dynamic error (err:XC0152) if the document supplied on schema port is not a valid XML schema document.

          The values of the use-location-hints, try-namespaces, and assert-valid options must be boolean.

          The value of the mode option must be an NMTOKEN whose value is either “strict” or “lax”.

          Validation is performed against the set of schemas represented by the documents on the schema port. These schemas must be used in preference to any schema locations provided by schema location hints encountered during schema validation, that is, schema locations supplied for xs:import or xsi:schema-location, or determined by schema-processor-defined namespace-based strategies, for the namespaces covered by the documents available on the schemas port.

          If xs:include elements occur within the supplied schema documents, they are treated like any other external documents (see [XProc 3.0]). It is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided.

          The use-location-hints and try-namespaces options allow the pipeline author to control how the schema processor should attempt to locate schema documents necessary but not provided on the schema port. Any schema documents provided on the schema port must be used in preference to schema documents located by other means.

          If the use-location-hints option is “true”, the processor should make use of schema location hints to locate schema documents. If the option is “false”, the processor should ignore any such hints.

          If the try-namespaces option is “true”, the processor should attempt to dereference the namespace URI to locate schema documents. If the option is “false”, the processor should not dereference namespace URIs.

          The mode option allow the pipeline author to control how schema validation begins. The “strict” mode means that the document element must be declared and schema-valid, otherwise it will be treated as invalid. The “lax” mode means that the absence of a declaration for the document element does not itself count as an unsuccessful outcome of validation.

          If the step specifies a version, then that version of XML Schema must be used to process the validation. It is a dynamic error (err:XC0011) if the specified schema 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 schema(s).

          It is a dynamic error (err:XC0156) if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid. If the assert-valid option is false, it is not an error for the document to be invalid. In this case, if the implementation does not support the PSVI, p:validate-with-xml-schema is essentially just an “identity” step, but if the implementation does support the PSVI, then the resulting document will have additional type information (at least for the subtrees that are valid).

          When XML Schema validation assessment is performed, the processor is invoked in the mode specified by the mode option. It is a dynamic error (err:XC0055) if the implementation does not support the specified mode.

          The result of the assessment is a document with the Post-Schema-Validation-Infoset (PSVI) ([W3C XML Schema: Part 1]) annotations, if the pipeline implementation supports such annotations. If not, the input document is reproduced with any defaulting of attributes and elements performed as specified by the XML Schema recommendation.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties on the schemas port are preserved.

          7. Validate with JSON schema

          The p:validate-with-json-schema step applies a JSON schema validation (as defined in [JSON schema] and other publications) to the source input.

          Summary

          Input portPrimarySequenceContent types
          source✔  json 
          schema  json 
          Output portPrimarySequenceContent types
          result✔  json 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          default-versionxs:string?()
          parametersmap(xs:QName,item()*)?()
          report-formatxs:string'xvrl'
          Errors
          Error codeDescription
          err:C0163It is a dynamic error if the selected version is not supported.
          err:C0164It is a dynamic error if the document supplied on schema port is not a valid JSON schema document in the selected version.
          err:C0165It is a dynamic error if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.
          Implementation details
          ImplementationDescription
          DefinedIf the schema does not specify a version and option default-version is empty, the version used is implementation-defined.
          Declaration

          <p:declare-steptype="p:validate-with-json-schema">     <p:inputport="source"primary="true"content-types="json"/>     <p:inputport="schema"sequence="false"content-types="json"/>     <p:outputport="result"primary="true"content-types="json"/>     <p:outputport="report"sequence="true"content-types="xml json"/>     <p:optionname="assert-valid"select="true()"as="xs:boolean"/>     <p:optionname="default-version"as="xs:string?"/>                 <p:optionname="parameters"as="map(xs:QName,item()*)?"/>          <p:optionname="report-format"select="'xvrl'"as="xs:string"/></p:declare-step>

          The option default-version can be used to control the schema's version in case it does not specify one itself. If the schema does not specify a version and option default-version is empty, the version used is implementation-defined.

          It is a dynamic error (err:XC0163) if the selected version is not supported.

          It is a dynamic error (err:XC0164) if the document supplied on schema port is not a valid JSON schema document in the selected version.

          It is a dynamic error (err:XC0165) if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties on the schemas are preserved. No document properties are preserved on the report port.

          Errata, April 2024

          Corrected an error in the sequence type for the default-version option to allow it to be optional.

          8. Validate with a DTD

          The p:validate-with-dtd step validates XML with a DTD.

          Summary

          Input portPrimarySequenceContent typesDefault binding
          source✔  xml html text 
          doctype ✔ text p:empty
          Output portPrimarySequenceContent typesDefault binding
          result✔  xml 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          report-formatxs:string'xvrl'
          serializationmap(xs:QName,item()*)?()
          Declaration

          <p:declare-steptype="p:validate-with-dtd">     <p:inputport="source"primary="true"content-types="xml html text"/>     <p:inputport="doctype"content-types="text"sequence="true">          <p:empty/>     </p:input>     <p:outputport="result"primary="true"content-types="xml"/>     <p:outputport="report"sequence="true"content-types="xml json"/>     <p:optionname="report-format"select="'xvrl'"as="xs:string"/>     <p:optionname="serialization"as="map(xs:QName,item()*)?"/>       <p:optionname="assert-valid"select="true()"as="xs:boolean"/></p:declare-step>

          DTD validation differs from the other XML validation technologies in that it is applied during parsing. It isn’t possible to validate an XML data model with a DTD. This step necessarily serializes the source document and then parses it back into a new data model.

          There are several possible approaches, with varying degrees of complexity. The general model is that the contents of the doctype port and the result of serializing the source are concatenated together.

          • In the simple case, the doctype is empty and source document is simply serialized. In order to have any chance of being DTD-valid, the serialization properties must include at least a doctype-system property.

          • If an internal subset is required, it is provided on the doctype port. In this case, the source document must be serialized without a doctype-system property; both the internal and external declarations must appear on the doctype port.

          • Finally, if a text document is provided on the source port, it is simply concatenated with the doctype port.

          The resulting text is parsed using a validating XML parser.

          Any warning or error messages produced by the parser will appear on the report port. If validation succeeds, the validated document will appear on the result port.

          3. Step library

          3.1. Validate with NVDL

          The p:validate-with-nvdl step applies [NVDL] validation to the source document.

          Summary

          Input portPrimarySequenceContent typesDefault binding
          source✔  xml html 
          nvdl  xml 
          schemas ✔ text xml p:empty
          Output portPrimarySequenceContent typesDefault binding
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          parametersmap(xs:QName,item()*)?()
          report-formatxs:string'xvrl'
          Errors
          Error codeDescription
          err:C0053It is a dynamic error if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.
          err:C0154It is a dynamic error if the document supplied on nvdl port is not a valid NVDL document.
          Declaration

          <p:declare-steptype="p:validate-with-nvdl">
               <p:inputport="source"primary="true"content-types="xml html"/>
               <p:inputport="nvdl"content-types="xml"/>
               <p:inputport="schemas"sequence="true"content-types="text xml">
                    <p:empty/>
               </p:input>
               <p:outputport="result"primary="true"content-types="xml html"/>
               <p:outputport="report"sequence="true"content-types="xml json"/>
               <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
               <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
               <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
          </p:declare-step>

          The source document is validated using the namespace dispatching rules contained in the nvdl document. It is a dynamic error (err:XC0154) if the document supplied on nvdl port is not a valid NVDL document.

          The dispatching rules may contain URI references that point to the actual schemas to be used. As long as these schemas are accessible, it is not necessary to pass anything on the schemas port. However, if one or more schemas are provided on the schemas port, then these schemas should be used in validation.

          It is a dynamic error (err:XC0053) if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.

          The output from this step is a copy of the input. The output of this step may include PSVI annotations.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

          3.2. Validate with RELAX NG

          The p:validate-with-relax-ng step applies [RELAX NG] validation to the source document.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          schema  text xml 
          Output portPrimarySequenceContent types
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          dtd-attribute-valuesxs:booleanfalse()
          dtd-id-idref-warningsxs:booleanfalse()
          parametersmap(xs:QName,item()*)?()
          report-formatxs:string'xvrl'
          Errors
          Error codeDescription
          err:C0153It is a dynamic error if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.
          err:C0155It is a dynamic error if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.
          Implementation details
          ImplementationDescription
          DefinedSupport for is implementation-defined.
          Declaration

          <p:declare-steptype="p:validate-with-relax-ng">
               <p:inputport="source"primary="true"content-types="xml html"/>
               <p:inputport="schema"content-types="text xml"/>
               <p:outputport="result"primary="true"content-types="xml html"/>
               <p:outputport="report"sequence="true"content-types="xml json"/>
               <p:optionname="dtd-attribute-values"select="false()"as="xs:boolean"/>
               <p:optionname="dtd-id-idref-warnings"select="false()"as="xs:boolean"/>
               <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
               <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
               <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
          </p:declare-step>

          The values of the dtd-attribute-values and dtd-id-idref-warnings options must be booleans.

          If the schema document has an XML media type, then it must be interpreted as a RELAX NG Grammar. If the schema document has a text media type, then it must be interpreted as a [RELAX NG Compact Syntax] document for validation. It is a dynamic error (err:XC0153) if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.

          If the dtd-attribute-values option is true, then the attribute value defaulting conventions of [RELAX NG DTD Compatibility] are also applied.

          If the dtd-id-idref-warnings option is true, then the validator should treat a schema that is incompatible with the ID/IDREF/IDREFs feature of [RELAX NG DTD Compatibility] as if the document was invalid.

          It is a dynamic error (err:XC0155) if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.

          The output from this step is a copy of the input, possibly augmented by application of the [RELAX NG DTD Compatibility]. The output of this step may include PSVI annotations.

          Support for [RELAX NG DTD Compatibility] is implementation-defined.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

          3.3. Validate with Schematron

          The p:validate-with-schematron step applies [Schematron] processing to the source document.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          schema  xml 
          Output portPrimarySequenceContent types
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          parametersmap(xs:QName,item()*)?()
          phasexs:string'#DEFAULT'
          report-formatxs:string'svrl'
          Errors
          Error codeDescription
          err:C0054It is a dynamic error if the assert-valid option is true and any Schematron assertions fail.
          err:C0151It is a dynamic error if the document supplied on schema port is not a valid Schematron document.
          Implementation details
          ImplementationDescription
          DefinedHow the Schematron implementation is selected is implementation-defined.
          DefinedThe list of supported Schematron implementations and their associated values is implementation-defined.
          DefinedWhich parameters the c:compile map supports for a given Schematron implementation is implementation-defined.
          DefinedWhich parameters this conversion from native reporting format to XVRL supports is implementation-defined.
          Declaration

          <p:declare-steptype="p:validate-with-schematron">
               <p:inputport="source"primary="true"content-types="xml html"/>
               <p:inputport="schema"content-types="xml"/>
               <p:outputport="result"primary="true"content-types="xml html"/>
               <p:outputport="report"sequence="true"content-types="xml json"/>
               <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
               <p:optionname="phase"select="'#DEFAULT'"as="xs:string"/>   
               <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
               <p:optionname="report-format"select="'svrl'"as="xs:string"/>
          </p:declare-step>

          It is a dynamic error (err:XC0151) if the document supplied on schema port is not a valid Schematron document.

          It is a dynamic error (err:XC0054) if the assert-valid option is true and any Schematron assertions fail.

          Note

          A Schematron validation with assert-valid="true" will fail if any validation message is produced by sch:assert or sch:report, even if the severity level of the failed assertion or the successful report is below a certain threshold, for example if there is only an info message. (The severity is conventionally conveyed by the @role attribute on sch:assert or sch:report.)

          The value of the phase option identifies the Schematron validation phase with which validation begins.

          The parameters option provides name/value pairs which correspond to Schematron external variables, to parameters that influence code generation, or to parameters that influence SVRL to XVRL conversion.

          There are multiple Schematron implementations. How the Schematron implementation is selected is implementation-defined. A processor might select an implementation based on the schema’s queryBinding attribute and/or provide configuration options. In addition, the special parameter map entry c:implementation (value: QName) may be used to select a Schematron implementation that the processor supports. The list of supported Schematron implementations and their associated values is implementation-defined. If a requested implementation is not available, the processor may throw an error or select another implementation.

          The parameters map may contain two special entries, c:compile and c:xvrl, both are maps. If a code-generating implementation such as [Schematron Skeleton] is used, the entries of the c:compile map, for example allow-foreign, will be passed to the code generator. Which parameters the c:compile map supports for a given Schematron implementation is implementation-defined.

          If the Schematron implementation produces SVRL by default, the SVRL to XVRL conversion can be influenced by the entries of the c:xvrl map. The same map, with potentially another set of allowed keys and values, can be used to influence XVRL generation from another reporting language. Which parameters this conversion from native reporting format to XVRL supports is implementation-defined.

          All other parameters of the parameters option will be passed to the generated code if applicable, or to a hypothetical native Schematron validator that does without code generation.

          The result output from this step is a copy of the input.

          The output of this step may include PSVI annotations.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

          3.4. Validate with XML Schema

          The p:validate-with-xml-schema step applies [W3C XML Schema: Part 1] validity assessment to the source input.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          schema ✔ xml 
          Output portPrimarySequenceContent types
          result✔  xml html 
          report ✔ xml json 
          Option nameTypeValuesDefault value
          assert-validxs:boolean true()
          modexs:string('strict','lax') 'strict'
          parametersmap(xs:QName,item()*)? ()
          report-formatxs:string 'xvrl'
          try-namespacesxs:boolean false()
          use-location-hintsxs:boolean false()
          versionxs:string? ()
          Errors
          Error codeDescription
          err:C0011It is a dynamic error if the specified schema version is not available.
          err:C0055It is a dynamic error if the implementation does not support the specified mode.
          err:C0152It is a dynamic error if the document supplied on schema port is not a valid XML schema document.
          err:C0156It is a dynamic error if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid.
          Implementation details
          ImplementationDescription
          DefinedIt is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided.
          Declaration

          <p:declare-steptype="p:validate-with-xml-schema">
               <p:inputport="source"primary="true"content-types="xml html"/>
               <p:inputport="schema"sequence="true"content-types="xml"/>
               <p:outputport="result"primary="true"content-types="xml html"/>
               <p:outputport="report"sequence="true"content-types="xml json"/>
               <p:optionname="use-location-hints"select="false()"as="xs:boolean"/>
               <p:optionname="try-namespaces"select="false()"as="xs:boolean"/>
               <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
               <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
               <p:optionname="mode"select="'strict'"values="('strict','lax')"/><!-- string -->
               <p:optionname="version"as="xs:string?"/>                    
               <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
          </p:declare-step>

          It is a dynamic error (err:XC0152) if the document supplied on schema port is not a valid XML schema document.

          The values of the use-location-hints, try-namespaces, and assert-valid options must be boolean.

          The value of the mode option must be an NMTOKEN whose value is either “strict” or “lax”.

          Validation is performed against the set of schemas represented by the documents on the schema port. These schemas must be used in preference to any schema locations provided by schema location hints encountered during schema validation, that is, schema locations supplied for xs:import or xsi:schema-location, or determined by schema-processor-defined namespace-based strategies, for the namespaces covered by the documents available on the schemas port.

          If xs:include elements occur within the supplied schema documents, they are treated like any other external documents (see [XProc 3.0]). It is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided.

          The use-location-hints and try-namespaces options allow the pipeline author to control how the schema processor should attempt to locate schema documents necessary but not provided on the schema port. Any schema documents provided on the schema port must be used in preference to schema documents located by other means.

          If the use-location-hints option is “true”, the processor should make use of schema location hints to locate schema documents. If the option is “false”, the processor should ignore any such hints.

          If the try-namespaces option is “true”, the processor should attempt to dereference the namespace URI to locate schema documents. If the option is “false”, the processor should not dereference namespace URIs.

          The mode option allow the pipeline author to control how schema validation begins. The “strict” mode means that the document element must be declared and schema-valid, otherwise it will be treated as invalid. The “lax” mode means that the absence of a declaration for the document element does not itself count as an unsuccessful outcome of validation.

          If the step specifies a version, then that version of XML Schema must be used to process the validation. It is a dynamic error (err:XC0011) if the specified schema 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 schema(s).

          It is a dynamic error (err:XC0156) if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid. If the assert-valid option is false, it is not an error for the document to be invalid. In this case, if the implementation does not support the PSVI, p:validate-with-xml-schema is essentially just an “identity” step, but if the implementation does support the PSVI, then the resulting document will have additional type information (at least for the subtrees that are valid).

          When XML Schema validation assessment is performed, the processor is invoked in the mode specified by the mode option. It is a dynamic error (err:XC0055) if the implementation does not support the specified mode.

          The result of the assessment is a document with the Post-Schema-Validation-Infoset (PSVI) ([W3C XML Schema: Part 1]) annotations, if the pipeline implementation supports such annotations. If not, the input document is reproduced with any defaulting of attributes and elements performed as specified by the XML Schema recommendation.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

          3.5. Validate with JSON schema

          The p:validate-with-json-schema step applies a JSON schema validation (as defined in [JSON schema] and other publications) to the source input.

          Summary

          Input portPrimarySequenceContent types
          source✔  json 
          schema  json 
          Output portPrimarySequenceContent types
          result✔  json 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          default-versionxs:string?()
          parametersmap(xs:QName,item()*)?()
          report-formatxs:string'xvrl'
          Errors
          Error codeDescription
          err:C0163It is a dynamic error if the selected version is not supported.
          err:C0164It is a dynamic error if the document supplied on schema port is not a valid JSON schema document in the selected version.
          err:C0165It is a dynamic error if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.
          Implementation details
          ImplementationDescription
          DefinedIf the schema does not specify a version and option default-version is empty, the version used is implementation-defined.
          Declaration

          <p:declare-steptype="p:validate-with-json-schema">
               <p:inputport="source"primary="true"content-types="json"/>
               <p:inputport="schema"sequence="false"content-types="json"/>
               <p:outputport="result"primary="true"content-types="json"/>
               <p:outputport="report"sequence="true"content-types="xml json"/>
               <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
               <p:optionname="default-version"as="xs:string?"/>            
               <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
               <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
          </p:declare-step>

          The option default-version can be used to control the schema's version in case it does not specify one itself. If the schema does not specify a version and option default-version is empty, the version used is implementation-defined.

          It is a dynamic error (err:XC0163) if the selected version is not supported.

          It is a dynamic error (err:XC0164) if the document supplied on schema port is not a valid JSON schema document in the selected version.

          It is a dynamic error (err:XC0165) if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.

          The output from this step is a copy of the input.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

          3.6. Validate with DTD

          The p:validate-with-dtd step validates XML with a DTD.

          Summary

          Input portPrimarySequenceContent types
          source✔  xml html 
          Output portPrimarySequenceContent types
          result✔  xml 
          report ✔ xml json 
          Option nameTypeDefault value
          assert-validxs:booleantrue()
          report-formatxs:string'xvrl'
          serializationmap(xs:QName,item()*)?()
          Errors
          Error codeDescription
          err:C0210It is a dynamic error if the assert-valid option on p:validate-with-dtd is true and the input document is not valid.
          Declaration

          <p:declare-steptype="p:validate-with-dtd">
               <p:inputport="source"primary="true"content-types="xml html"/>
               <p:outputport="result"primary="true"content-types="xml"/>
               <p:outputport="report"sequence="true"content-types="xml json"/>
               <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
               <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
               <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
          </p:declare-step>

          DTD validation differs from the other XML validation technologies in that it is applied during parsing. It isn’t possible to validate an XML data model with a DTD. This step necessarily serializes and reparses.

          The p:validate-with-dtd step serializes the document on the source port and parses the serialization with a validating XML parser. Any warning or error messages produced by the parser will appear on the report port.

          Note

          The serialization options must include at least the doctype-system property (without a system identifier, the document cannot be successfully parsed with a validating parser).

          It is a dynamic error (err:XC0210) if the assert-valid option on p:validate-with-dtd is true and the input document is not valid.

          The output from this step is a copy of the input. If validation was successful, the output may have been augmented by the DTD. (For example, default attributes may have been added.)

          Using an internal subset

          To validate a document with an internal subset, construct a text document that is a syntactically valid XML document with the internal subset, use p:cast-content-type to create an XML document, and then validate the resulting document with this step.

          Document properties

          All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

          94. Step Errors

          This stepThese steps can raise dynamic errors.

          [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

          If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

          The following errors can be raised by this step:

          err:XC0011

          It is a dynamic error if the specified schema version is not available.

          See: Validate with XML Schema

          err:XC0053

          It is a dynamic error if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.

          See: Validate with NVDL

          err:XC0054

          It is a dynamic error if the assert-valid option is true and any Schematron assertions fail.

          See: Validate with Schematron

          err:XC0055

          It is a dynamic error if the implementation does not support the specified mode.

          See: Validate with XML Schema

          err:XC0117

          It is a dynamic error if a report-format option was specified that the processor does not support.

          See: Common Options and Outputs

          err:XC0151

          It is a dynamic error if the document supplied on schema port is not a valid Schematron document.

          See: Validate with Schematron

          err:XC0152

          It is a dynamic error if the document supplied on schema port is not a valid XML schema document.

          See: Validate with XML Schema

          err:XC0153

          It is a dynamic error if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.

          See: Validate with RELAX NG

          err:XC0154

          It is a dynamic error if the document supplied on nvdl port is not a valid NVDL document.

          See: Validate with NVDL

          err:XC0155

          It is a dynamic error if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.

          See: Validate with RELAX NG

          err:XC0156

          It is a dynamic error if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid.

          See: Validate with XML Schema

          err:XC0163

          It is a dynamic error if the selected version is not supported.

          See: Validate with JSON schema

          err:XC0164

          It is a dynamic error if the document supplied on schema port is not a valid JSON schema document in the selected version.

          See: Validate with JSON schema

          err:XC0165

          It is a dynamic error if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.

          See: Validate with JSON schema

          err:XC0210

          It is a dynamic error if the assert-valid option on p:validate-with-dtd is true and the input document is not valid.

          See: Validate with DTD

          A. Conformance

          Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

          [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

          [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

          A.1. Implementation-defined features

          The following features are implementation-defined:

          1. The supported values for the report-format option are implementation-defined. A processor should at least support the value “xvrl” for the XML validation steps and “svrl” for p:validate-with-schematron. See Section 2, “Common Options and Outputs”.
          2. The parameters supported by the validation steps and their semantics are implementation-defined, and they can be different for each validation step. See Section 2, “Common Options and Outputs”.
          3. Support for is implementation-defined. See Section 43.2, “Validate with RELAX NG”.
          4. How the Schematron implementation is selected is implementation-defined. See Section 53.3, “Validate with Schematron”.
          5. The list of supported Schematron implementations and their associated values is implementation-defined. See Section 53.3, “Validate with Schematron”.
          6. Which parameters the c:compile map supports for a given Schematron implementation is implementation-defined. See Section 53.3, “Validate with Schematron”.
          7. Which parameters this conversion from native reporting format to XVRL supports is implementation-defined. See Section 53.3, “Validate with Schematron”.
          8. It is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided. See Section 63.4, “Validate with XML Schema”.
          9. If the schema does not specify a version and option default-version is empty, the version used is implementation-defined. See Section 73.5, “Validate with JSON schema”.

          A.2. Implementation-dependent features

          The following features are implementation-dependent:

            B. References

            [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

            [XProc 3.0 Steps] XProc 3.0 Steps: An Introduction. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

            [Schematron] ISO/IEC JTC 1/SC 34. ISO/IEC 19757-3:2016(E) Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron 2016.

            [NVDL] ISO/IEC JTC 1/SC 34. ISO/IEC 19757-4:2006(E) Document Schema Definition Languages (DSDL) — Part 4: Namespace-based Validation Dispatching Language (NVDL) 2006.

            [Schematron Skeleton] Schematron “Skeleton” Implementation 2017.

            [RELAX NG Compact Syntax] ISO/IEC JTC 1/SC 34. ISO/IEC 19757-2:2003/Amd 1:2006 Document Schema Definition Languages (DSDL) — Part 2: Grammar-based validation — RELAX NG AMENDMENT 1 Compact Syntax 2006.

            [RELAX NG DTD Compatibility] RELAX NG DTD Compatibility. OASIS Committee Specification. 3 December 2001.

            [W3C XML Schema: Part 1] XML Schema Part 1: Structures Second Edition. Henry S. Thompson, David Beech, Murray Maloney, et. al., editors. World Wide Web Consortium, 28 October 2004.

            [JSON schema] JSON Schema Validation: A Vocabulary for Structural Validation of JSON. A.Wright, H. Andrews and B. Hutton, editors. Internet Engineering Task Force. June, 2022.

            C. Glossary

            dynamic error

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

            implementation-defined

            An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

            implementation-dependent

            An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

            DE. Ancillary files

            This specification includes by reference a number of ancillary files.

            steps.xpl

            An XProc step library for the declared steps.

            \ No newline at end of file +

            XProc 3.0: validation steps

            Draft Community Group Report

            Editor's Draft at (build 4546)
            Latest editor’s draft:
            https://spec.xproc.org/master/head/validation/
            Editors:
            Norman Walsh
            Achim Berndzen
            Gerrit Imsieke
            Erik Siegel
            Participate:
            GitHub xproc/3.0-steps
            Report an issue
            Changes:
            Diff against current “status quo” draft
            Commits for this specification

            This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

            Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: validation steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

            Abstract

            This specification describes the p:validate-with-nvdl, p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, p:validate-with-json-schema, and p:validate-with-dtd step for XProc 3.0: An XML Pipeline Language.

            Status of this Document

            This document is an editor's draft that has no official standing.

            This specification was published by the XProc Next Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

            If you wish to make comments regarding this document, please send them to xproc-dev@w3.org. (subscribe, archives).

            This document is derived from XProc: An XML Pipeline Language published by the W3C.

            1. Introduction

            This specification describes the p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, p:validate-with-nvdl, and p:validate-with-json-schema steps. Each is independently optional. A machine-readable description of these steps may be found in steps.xpl.

            Familiarity with the general nature of [XProc 3.0] steps is assumed; for background details, see [XProc 3.0 Steps].

            As described in PSVIs in XProc in XProc 3.0: An XML Pipeline Language, steps may not produce PSVI output unless that behavior is explicitly described. In this specification, the steps that may produce PSVI output are p:validate-with-nvdl, p:validate-with-schematron and p:validate-with-xml-schema.

            2. Common Options and Outputs

            All steps in this specification provide a boolean option assert-valid. If any of the validated documents is found to be invalid according to the respective schema, and possibly other parameters that influence determination of validity, a dynamic error is raised.

            Note

            Historically, the validation steps (apart from p:validate-with-schematron) could only report errors by setting assert-valid to true and catching the errors. A c:errors document on the error port of the corresponding p:catch recovery pipeline had to be sent to an output, either verbatim or after postprocessing. Now, if assert-valid is false, an XVRL document will be available on the report port of the validation step. It uses the XVRL severity vocabulary to indicate whether the validation failed, and to which degree. This allows more nuance in reporting errors. Previously, assert-valid="true" on p:validate-with-schematron would always throw an error even if the reported findings were only intended as less severe, for example if the schema author used info or warning in sch:report/@role.

            If no such error is raised, each step generates at least one validation report document on its report port. Unless another format is requested, the mandatory report document for all steps except p:validate-with-schematronshould be an [XVRL] document. A report format may be requested by the report-format option. The supported values for the report-format option are implementation-defined. A processor should at least support the value “xvrl” for the XML validation steps and “svrl” for p:validate-with-schematron.

            It is a dynamic error (err:XC0117) if a report-format option was specified that the processor does not support.

            If a step performs multiple validations on a single document (for example, embedded Schematron validations in a Relax NG schema), all individual XVRL reports need to be consolidated into a single XVRL report by the step.

            Each of the validation steps has a parameters option. The parameters supported by the validation steps and their semantics are implementation-defined, and they can be different for each validation step. A special key in the c namespace, http://www.w3.org/ns/xproc-step, called c:compile, can hold a map itself that controls schema compilation. Schema compilation is, for example, the process of converting a Schematron schema into an XSLT stylesheet. The c:compile map will be used as parameters for the compilation process.

            Map entries in the xvrl namespace, http://www.xproc.org/ns/xvrl will be passed as parameters to the XVRL generation process. XProc implementations that implement any of the XML validation steps should support the basic parameters that are defined in the [XVRL] specification, xvrl:default-severity, xvrl:language, xvrl:map-to-severity, and xvrl:xpath-notation.

            3. Validate with NVDL

            The p:validate-with-nvdl step applies [NVDL] validation to the source document.

            Summary

            Input portPrimarySequenceContent typesDefault binding
            source✔  xml html 
            nvdl  xml 
            schemas ✔ text xml p:empty
            Output portPrimarySequenceContent typesDefault binding
            result✔  xml html 
            report ✔ xml json 
            Option nameTypeDefault value
            assert-validxs:booleantrue()
            parametersmap(xs:QName,item()*)?()
            report-formatxs:string'xvrl'
            Errors
            Error codeDescription
            err:C0053It is a dynamic error if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.
            err:C0154It is a dynamic error if the document supplied on nvdl port is not a valid NVDL document.
            Declaration

            <p:declare-steptype="p:validate-with-nvdl">
                 <p:inputport="source"primary="true"content-types="xml html"/>
                 <p:inputport="nvdl"content-types="xml"/>
                 <p:inputport="schemas"sequence="true"content-types="text xml">
                      <p:empty/>
                 </p:input>
                 <p:outputport="result"primary="true"content-types="xml html"/>
                 <p:outputport="report"sequence="true"content-types="xml json"/>
                 <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
                 <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
                 <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
            </p:declare-step>

            The source document is validated using the namespace dispatching rules contained in the nvdl document. It is a dynamic error (err:XC0154) if the document supplied on nvdl port is not a valid NVDL document.

            The dispatching rules may contain URI references that point to the actual schemas to be used. As long as these schemas are accessible, it is not necessary to pass anything on the schemas port. However, if one or more schemas are provided on the schemas port, then these schemas should be used in validation.

            It is a dynamic error (err:XC0053) if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.

            The output from this step is a copy of the input. The output of this step may include PSVI annotations.

            Note

            Should the step also provide the dtd-attribute-values and dtd-id-idref-warnings options for Relax NG validations? Is there a way to instruct Jing to use these options, maybe in NVDL extension attributes? Probably not in the foreseeable future.

            Document properties

            All document properties on the source port are preserved on the result port. No document properties on the schemas and nvdl ports are preserved. No document properties are preserved on the report port.

            4. Validate with RELAX NG

            The p:validate-with-relax-ng step applies [RELAX NG] validation to the source document.

            Summary

            Input portPrimarySequenceContent types
            source✔  xml html 
            schema  text xml 
            Output portPrimarySequenceContent types
            result✔  xml html 
            report ✔ xml json 
            Option nameTypeDefault value
            assert-validxs:booleantrue()
            dtd-attribute-valuesxs:booleanfalse()
            dtd-id-idref-warningsxs:booleanfalse()
            parametersmap(xs:QName,item()*)?()
            report-formatxs:string'xvrl'
            Errors
            Error codeDescription
            err:C0153It is a dynamic error if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.
            err:C0155It is a dynamic error if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.
            Implementation details
            ImplementationDescription
            DefinedSupport for is implementation-defined.
            Declaration

            <p:declare-steptype="p:validate-with-relax-ng">
                 <p:inputport="source"primary="true"content-types="xml html"/>
                 <p:inputport="schema"content-types="text xml"/>
                 <p:outputport="result"primary="true"content-types="xml html"/>
                 <p:outputport="report"sequence="true"content-types="xml json"/>
                 <p:optionname="dtd-attribute-values"select="false()"as="xs:boolean"/>
                 <p:optionname="dtd-id-idref-warnings"select="false()"as="xs:boolean"/>
                 <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
                 <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
                 <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
            </p:declare-step>

            The values of the dtd-attribute-values and dtd-id-idref-warnings options must be booleans.

            If the schema document has an XML media type, then it must be interpreted as a RELAX NG Grammar. If the schema document has a text media type, then it must be interpreted as a [RELAX NG Compact Syntax] document for validation. It is a dynamic error (err:XC0153) if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.

            If the dtd-attribute-values option is true, then the attribute value defaulting conventions of [RELAX NG DTD Compatibility] are also applied.

            If the dtd-id-idref-warnings option is true, then the validator should treat a schema that is incompatible with the ID/IDREF/IDREFs feature of [RELAX NG DTD Compatibility] as if the document was invalid.

            It is a dynamic error (err:XC0155) if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.

            The output from this step is a copy of the input, possibly augmented by application of the [RELAX NG DTD Compatibility]. The output of this step may include PSVI annotations.

            Support for [RELAX NG DTD Compatibility] is implementation-defined.

            Document properties

            All document properties on the source port are preserved on the result port. No document properties on the schema port are preserved. No document properties are preserved on the report port.

            5. Validate with Schematron

            The p:validate-with-schematron step applies [Schematron] processing to the source document.

            Summary

            Input portPrimarySequenceContent types
            source✔  xml html 
            schema  xml 
            Output portPrimarySequenceContent types
            result✔  xml html 
            report ✔ xml json 
            Option nameTypeDefault value
            assert-validxs:booleantrue()
            parametersmap(xs:QName,item()*)?()
            phasexs:string'#DEFAULT'
            report-formatxs:string'svrl'
            Errors
            Error codeDescription
            err:C0054It is a dynamic error if the assert-valid option is true and any Schematron assertions fail.
            err:C0151It is a dynamic error if the document supplied on schema port is not a valid Schematron document.
            Implementation details
            ImplementationDescription
            DefinedHow the Schematron implementation is selected is implementation-defined.
            DefinedThe list of supported Schematron implementations and their associated values is implementation-defined.
            DefinedWhich parameters the c:compile map supports for a given Schematron implementation is implementation-defined.
            DefinedWhich parameters this conversion from native reporting format to XVRL supports is implementation-defined.
            Declaration

            <p:declare-steptype="p:validate-with-schematron">
                 <p:inputport="source"primary="true"content-types="xml html"/>
                 <p:inputport="schema"content-types="xml"/>
                 <p:outputport="result"primary="true"content-types="xml html"/>
                 <p:outputport="report"sequence="true"content-types="xml json"/>
                 <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
                 <p:optionname="phase"select="'#DEFAULT'"as="xs:string"/>   
                 <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
                 <p:optionname="report-format"select="'svrl'"as="xs:string"/>
            </p:declare-step>

            It is a dynamic error (err:XC0151) if the document supplied on schema port is not a valid Schematron document.

            It is a dynamic error (err:XC0054) if the assert-valid option is true and any Schematron assertions fail.

            Note

            A Schematron validation with assert-valid="true" will fail if any validation message is produced by sch:assert or sch:report, even if the severity level of the failed assertion or the successful report is below a certain threshold, for example if there is only an info message. (The severity is conventionally conveyed by the @role attribute on sch:assert or sch:report.)

            The value of the phase option identifies the Schematron validation phase with which validation begins.

            The parameters option provides name/value pairs which correspond to Schematron external variables, to parameters that influence code generation, or to parameters that influence SVRL to XVRL conversion.

            There are multiple Schematron implementations. How the Schematron implementation is selected is implementation-defined. A processor might select an implementation based on the schema’s queryBinding attribute and/or provide configuration options. In addition, the special parameter map entry c:implementation (value: QName) may be used to select a Schematron implementation that the processor supports. The list of supported Schematron implementations and their associated values is implementation-defined. If a requested implementation is not available, the processor may throw an error or select another implementation.

            The parameters map may contain two special entries, c:compile and c:xvrl, both are maps. If a code-generating implementation such as [Schematron Skeleton] is used, the entries of the c:compile map, for example allow-foreign, will be passed to the code generator. Which parameters the c:compile map supports for a given Schematron implementation is implementation-defined.

            If the Schematron implementation produces SVRL by default, the SVRL to XVRL conversion can be influenced by the entries of the c:xvrl map. The same map, with potentially another set of allowed keys and values, can be used to influence XVRL generation from another reporting language. Which parameters this conversion from native reporting format to XVRL supports is implementation-defined.

            All other parameters of the parameters option will be passed to the generated code if applicable, or to a hypothetical native Schematron validator that does without code generation.

            The result output from this step is a copy of the input.

            The output of this step may include PSVI annotations.

            Document properties

            All document properties on the source port are preserved on the result port. No document properties on the schema port are preserved. No document properties are preserved on the report port.

            6. Validate with XML Schema

            The p:validate-with-xml-schema step applies [W3C XML Schema: Part 1] validity assessment to the source input.

            Summary

            Input portPrimarySequenceContent types
            source✔  xml html 
            schema ✔ xml 
            Output portPrimarySequenceContent types
            result✔  xml html 
            report ✔ xml json 
            Option nameTypeValuesDefault value
            assert-validxs:boolean true()
            modexs:string('strict','lax') 'strict'
            parametersmap(xs:QName,item()*)? ()
            report-formatxs:string 'xvrl'
            try-namespacesxs:boolean false()
            use-location-hintsxs:boolean false()
            versionxs:string? ()
            Errors
            Error codeDescription
            err:C0011It is a dynamic error if the specified schema version is not available.
            err:C0055It is a dynamic error if the implementation does not support the specified mode.
            err:C0152It is a dynamic error if the document supplied on schema port is not a valid XML schema document.
            err:C0156It is a dynamic error if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid.
            Implementation details
            ImplementationDescription
            DefinedIt is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided.
            Declaration

            <p:declare-steptype="p:validate-with-xml-schema">
                 <p:inputport="source"primary="true"content-types="xml html"/>
                 <p:inputport="schema"sequence="true"content-types="xml"/>
                 <p:outputport="result"primary="true"content-types="xml html"/>
                 <p:outputport="report"sequence="true"content-types="xml json"/>
                 <p:optionname="use-location-hints"select="false()"as="xs:boolean"/>
                 <p:optionname="try-namespaces"select="false()"as="xs:boolean"/>
                 <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
                 <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
                 <p:optionname="mode"select="'strict'"values="('strict','lax')"/><!-- string -->
                 <p:optionname="version"as="xs:string?"/>                    
                 <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
            </p:declare-step>

            It is a dynamic error (err:XC0152) if the document supplied on schema port is not a valid XML schema document.

            The values of the use-location-hints, try-namespaces, and assert-valid options must be boolean.

            The value of the mode option must be an NMTOKEN whose value is either “strict” or “lax”.

            Validation is performed against the set of schemas represented by the documents on the schema port. These schemas must be used in preference to any schema locations provided by schema location hints encountered during schema validation, that is, schema locations supplied for xs:import or xsi:schema-location, or determined by schema-processor-defined namespace-based strategies, for the namespaces covered by the documents available on the schemas port.

            If xs:include elements occur within the supplied schema documents, they are treated like any other external documents (see [XProc 3.0]). It is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided.

            The use-location-hints and try-namespaces options allow the pipeline author to control how the schema processor should attempt to locate schema documents necessary but not provided on the schema port. Any schema documents provided on the schema port must be used in preference to schema documents located by other means.

            If the use-location-hints option is “true”, the processor should make use of schema location hints to locate schema documents. If the option is “false”, the processor should ignore any such hints.

            If the try-namespaces option is “true”, the processor should attempt to dereference the namespace URI to locate schema documents. If the option is “false”, the processor should not dereference namespace URIs.

            The mode option allow the pipeline author to control how schema validation begins. The “strict” mode means that the document element must be declared and schema-valid, otherwise it will be treated as invalid. The “lax” mode means that the absence of a declaration for the document element does not itself count as an unsuccessful outcome of validation.

            If the step specifies a version, then that version of XML Schema must be used to process the validation. It is a dynamic error (err:XC0011) if the specified schema 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 schema(s).

            It is a dynamic error (err:XC0156) if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid. If the assert-valid option is false, it is not an error for the document to be invalid. In this case, if the implementation does not support the PSVI, p:validate-with-xml-schema is essentially just an “identity” step, but if the implementation does support the PSVI, then the resulting document will have additional type information (at least for the subtrees that are valid).

            When XML Schema validation assessment is performed, the processor is invoked in the mode specified by the mode option. It is a dynamic error (err:XC0055) if the implementation does not support the specified mode.

            The result of the assessment is a document with the Post-Schema-Validation-Infoset (PSVI) ([W3C XML Schema: Part 1]) annotations, if the pipeline implementation supports such annotations. If not, the input document is reproduced with any defaulting of attributes and elements performed as specified by the XML Schema recommendation.

            Document properties

            All document properties on the source port are preserved on the result port. No document properties on the schemas port are preserved.

            7. Validate with JSON schema

            The p:validate-with-json-schema step applies a JSON schema validation (as defined in [JSON schema] and other publications) to the source input.

            Summary

            Input portPrimarySequenceContent types
            source✔  json 
            schema  json 
            Output portPrimarySequenceContent types
            result✔  json 
            report ✔ xml json 
            Option nameTypeDefault value
            assert-validxs:booleantrue()
            default-versionxs:string?()
            parametersmap(xs:QName,item()*)?()
            report-formatxs:string'xvrl'
            Errors
            Error codeDescription
            err:C0163It is a dynamic error if the selected version is not supported.
            err:C0164It is a dynamic error if the document supplied on schema port is not a valid JSON schema document in the selected version.
            err:C0165It is a dynamic error if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.
            Implementation details
            ImplementationDescription
            DefinedIf the schema does not specify a version and option default-version is empty, the version used is implementation-defined.
            Declaration

            <p:declare-steptype="p:validate-with-json-schema">
                 <p:inputport="source"primary="true"content-types="json"/>
                 <p:inputport="schema"sequence="false"content-types="json"/>
                 <p:outputport="result"primary="true"content-types="json"/>
                 <p:outputport="report"sequence="true"content-types="xml json"/>
                 <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
                 <p:optionname="default-version"as="xs:string?"/>            
                 <p:optionname="parameters"as="map(xs:QName,item()*)?"/>     
                 <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
            </p:declare-step>

            The option default-version can be used to control the schema's version in case it does not specify one itself. If the schema does not specify a version and option default-version is empty, the version used is implementation-defined.

            It is a dynamic error (err:XC0163) if the selected version is not supported.

            It is a dynamic error (err:XC0164) if the document supplied on schema port is not a valid JSON schema document in the selected version.

            It is a dynamic error (err:XC0165) if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.

            Document properties

            All document properties on the source port are preserved on the result port. No document properties on the schemas are preserved. No document properties are preserved on the report port.

            Errata, April 2024

            Corrected an error in the sequence type for the default-version option to allow it to be optional.

            8. Validate with a DTD

            The p:validate-with-dtd step validates XML with a DTD.

            Summary

            Input portPrimarySequenceContent typesDefault binding
            source✔  xml html text 
            doctype ✔ text p:empty
            Output portPrimarySequenceContent typesDefault binding
            result✔  xml 
            report ✔ xml json 
            Option nameTypeDefault value
            assert-validxs:booleantrue()
            report-formatxs:string'xvrl'
            serializationmap(xs:QName,item()*)?()
            Declaration

            <p:declare-steptype="p:validate-with-dtd">
                 <p:inputport="source"primary="true"content-types="xml html text"/>
                 <p:inputport="doctype"content-types="text"sequence="true">
                      <p:empty/>
                 </p:input>
                 <p:outputport="result"primary="true"content-types="xml"/>
                 <p:outputport="report"sequence="true"content-types="xml json"/>
                 <p:optionname="report-format"select="'xvrl'"as="xs:string"/>
                 <p:optionname="serialization"as="map(xs:QName,item()*)?"/>  
                 <p:optionname="assert-valid"select="true()"as="xs:boolean"/>
            </p:declare-step>

            DTD validation differs from the other XML validation technologies in that it is applied during parsing. It isn’t possible to validate an XML data model with a DTD. This step necessarily serializes the source document and then parses it back into a new data model.

            There are several possible approaches, with varying degrees of complexity. The general model is that the contents of the doctype port and the result of serializing the source are concatenated together.

            • In the simple case, the doctype is empty and source document is simply serialized. In order to have any chance of being DTD-valid, the serialization properties must include at least a doctype-system property.

            • If an internal subset is required, it is provided on the doctype port. In this case, the source document must be serialized without a doctype-system property; both the internal and external declarations must appear on the doctype port.

            • Finally, if a text document is provided on the source port, it is simply concatenated with the doctype port.

            The resulting text is parsed using a validating XML parser.

            Any warning or error messages produced by the parser will appear on the report port. If validation succeeds, the validated document will appear on the result port.

            9. Step Errors

            This step can raise dynamic errors.

            [Definition: A dynamic error is one which occurs while a pipeline is being evaluated.] Examples of dynamic errors include references to URIs that cannot be resolved, steps which fail, and pipelines that exhaust the capacity of an implementation (such as memory or disk space). For a more complete discussion of dynamic errors, see Dynamic Errors in XProc 3.0: An XML Pipeline Language.

            If a step fails due to a dynamic error, failure propagates upwards until either a p:try is encountered or the entire pipeline fails. In other words, outside of a p:try, step failure causes the entire pipeline to fail.

            The following errors can be raised by this step:

            err:XC0011

            It is a dynamic error if the specified schema version is not available.

            See: Validate with XML Schema

            err:XC0053

            It is a dynamic error if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.

            See: Validate with NVDL

            err:XC0054

            It is a dynamic error if the assert-valid option is true and any Schematron assertions fail.

            See: Validate with Schematron

            err:XC0055

            It is a dynamic error if the implementation does not support the specified mode.

            See: Validate with XML Schema

            err:XC0117

            It is a dynamic error if a report-format option was specified that the processor does not support.

            See: Common Options and Outputs

            err:XC0151

            It is a dynamic error if the document supplied on schema port is not a valid Schematron document.

            See: Validate with Schematron

            err:XC0152

            It is a dynamic error if the document supplied on schema port is not a valid XML schema document.

            See: Validate with XML Schema

            err:XC0153

            It is a dynamic error if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.

            See: Validate with RELAX NG

            err:XC0154

            It is a dynamic error if the document supplied on nvdl port is not a valid NVDL document.

            See: Validate with NVDL

            err:XC0155

            It is a dynamic error if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.

            See: Validate with RELAX NG

            err:XC0156

            It is a dynamic error if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid.

            See: Validate with XML Schema

            err:XC0163

            It is a dynamic error if the selected version is not supported.

            See: Validate with JSON schema

            err:XC0164

            It is a dynamic error if the document supplied on schema port is not a valid JSON schema document in the selected version.

            See: Validate with JSON schema

            err:XC0165

            It is a dynamic error if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.

            See: Validate with JSON schema

            A. Conformance

            Conformant processors must implement all of the features described in this specification except those that are explicitly identified as optional.

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

            [Definition: An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.]

            [Definition: An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.]

            A.1. Implementation-defined features

            The following features are implementation-defined:

            1. The supported values for the report-format option are implementation-defined. A processor should at least support the value “xvrl” for the XML validation steps and “svrl” for p:validate-with-schematron. See Section 2, “Common Options and Outputs”.
            2. The parameters supported by the validation steps and their semantics are implementation-defined, and they can be different for each validation step. See Section 2, “Common Options and Outputs”.
            3. Support for is implementation-defined. See Section 4, “Validate with RELAX NG”.
            4. How the Schematron implementation is selected is implementation-defined. See Section 5, “Validate with Schematron”.
            5. The list of supported Schematron implementations and their associated values is implementation-defined. See Section 5, “Validate with Schematron”.
            6. Which parameters the c:compile map supports for a given Schematron implementation is implementation-defined. See Section 5, “Validate with Schematron”.
            7. Which parameters this conversion from native reporting format to XVRL supports is implementation-defined. See Section 5, “Validate with Schematron”.
            8. It is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided. See Section 6, “Validate with XML Schema”.
            9. If the schema does not specify a version and option default-version is empty, the version used is implementation-defined. See Section 7, “Validate with JSON schema”.

            A.2. Implementation-dependent features

            The following features are implementation-dependent:

              B. References

              [XProc 3.0] XProc 3.0: An XML Pipeline Language. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

              [XProc 3.0 Steps] XProc 3.0 Steps: An Introduction. Norman Walsh, Achim Berndzen, Gerrit Imsieke and Erik Siegel, editors.

              [Schematron] ISO/IEC JTC 1/SC 34. ISO/IEC 19757-3:2016(E) Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron 2016.

              [NVDL] ISO/IEC JTC 1/SC 34. ISO/IEC 19757-4:2006(E) Document Schema Definition Languages (DSDL) — Part 4: Namespace-based Validation Dispatching Language (NVDL) 2006.

              [Schematron Skeleton] Schematron “Skeleton” Implementation 2017.

              [RELAX NG Compact Syntax] ISO/IEC JTC 1/SC 34. ISO/IEC 19757-2:2003/Amd 1:2006 Document Schema Definition Languages (DSDL) — Part 2: Grammar-based validation — RELAX NG AMENDMENT 1 Compact Syntax 2006.

              [RELAX NG DTD Compatibility] RELAX NG DTD Compatibility. OASIS Committee Specification. 3 December 2001.

              [W3C XML Schema: Part 1] XML Schema Part 1: Structures Second Edition. Henry S. Thompson, David Beech, Murray Maloney, et. al., editors. World Wide Web Consortium, 28 October 2004.

              [JSON schema] JSON Schema Validation: A Vocabulary for Structural Validation of JSON. A.Wright, H. Andrews and B. Hutton, editors. Internet Engineering Task Force. June, 2022.

              C. Glossary

              dynamic error

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

              implementation-defined

              An implementation-defined feature is one where the implementation has discretion in how it is performed. Conformant implementations must document how implementation-defined features are performed.

              implementation-dependent

              An implementation-dependent feature is one where the implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed.

              D. Ancillary files

              This specification includes by reference a number of ancillary files.

              steps.xpl

              An XProc step library for the declared steps.

              \ No newline at end of file diff --git a/master/head/validation/index.html b/master/head/validation/index.html index bda293173..91cffe78a 100644 --- a/master/head/validation/index.html +++ b/master/head/validation/index.html @@ -1,4 +1,4 @@ -XProc 3.0: validation steps

              XProc 3.0: validation steps

              Draft Community Group Report

              Editor's Draft at (build 47)
              Latest editor’s draft:
              https://spec.xproc.org/master/head/validation/
              Editors:
              Norman Walsh
              Achim Berndzen
              Gerrit Imsieke
              Erik Siegel
              Participate:
              GitHub xproc/3.0-steps
              Report an issue
              Changes:
              Diff against current “status quo” draft
              Commits for this specification

              This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

              Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: validation steps specification, published by the XProc Next Community Group under the W3C +XProc 3.0: validation steps

              XProc 3.0: validation steps

              Draft Community Group Report

              Editor's Draft at (build 46)
              Latest editor’s draft:
              https://spec.xproc.org/master/head/validation/
              Editors:
              Norman Walsh
              Achim Berndzen
              Gerrit Imsieke
              Erik Siegel
              Participate:
              GitHub xproc/3.0-steps
              Report an issue
              Changes:
              Diff against current “status quo” draft
              Commits for this specification

              This document is also available in these non-normative formats: XML and HTML with automatic change markup courtesy of DeltaXML.

              Copyright © 2018, 2019, 2020 the Contributors to the XProc 3.0: validation steps specification, published by the XProc Next Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

              Abstract

              This specification describes the p:validate-with-nvdl, @@ -30,7 +30,7 @@

              This document is derived from XProc: An XML Pipeline Language published by the W3C.

              -
              +

              1. Introduction

              @@ -38,8 +38,7 @@

              This specification describes the p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, -p:validate-with-nvdl, p:validate-with-json-schema, -and p:validate-with-dtd +p:validate-with-nvdl, and p:validate-with-json-schema steps. Each is independently optional. A machine-readable description of these steps may be found in steps.xpl. @@ -101,10 +100,7 @@ xvrl:map-to-severity, and xvrl:xpath-notation.

              -

              3. Step library

              - - -

              3.1. Validate with NVDL

              +

              3. Validate with NVDL

              The p:validate-with-nvdl step applies [NVDL] validation to the @@ -128,25 +124,30 @@ p:validate-with-nvdl is true and the input document is not valid.

              -

              The output from this step is a copy of the input. The output of this - step may include PSVI annotations.

              +

              The output from this step is a copy of the input. The output of this step may include PSVI + annotations.

              -

              Document properties

              +

              Note

              +

              Should the step also provide the dtd-attribute-values and dtd-id-idref-warnings + options for Relax NG validations? Is there a way to instruct Jing + to use these options, maybe in NVDL extension attributes? Probably not in the foreseeable future.

              +
              + +

              Document properties

              -

              All document properties - on the source port are preserved on the result - port. No document properties are - preserved on the report port.

              +

              All document properties on the source port are preserved + on the result port. No document properties on the schemas and nvdl ports + are preserved. No document properties are preserved on the report port.

              -

              3.2. Validate with RELAX NG

              +

              4. Validate with RELAX NG

              The p:validate-with-relax-ng step applies [RELAX NG] validation to the source document.

              -

              Summary

              Input portPrimarySequenceContent types
              source✔  xml html 
              schema  text xml 
              Output portPrimarySequenceContent types
              result✔  xml html 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              dtd-attribute-valuesxs:booleanfalse()
              dtd-id-idref-warningsxs:booleanfalse()
              parametersmap(xs:QName,item()*)?()
              report-formatxs:string'xvrl'
              Errors
              Error codeDescription
              err:C0153It is a dynamic error +

              Summary

              Input portPrimarySequenceContent types
              source✔  xml html 
              schema  text xml 
              Output portPrimarySequenceContent types
              result✔  xml html 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              dtd-attribute-valuesxs:booleanfalse()
              dtd-id-idref-warningsxs:booleanfalse()
              parametersmap(xs:QName,item()*)?()
              report-formatxs:string'xvrl'
              Errors
              Error codeDescription
              err:C0153It is a dynamic error if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.
              err:C0155It is a dynamic error if the assert-valid option on p:validate-with-relax-ng @@ -154,7 +155,7 @@ and the input document is not valid.
              Implementation details
              ImplementationDescription
              DefinedSupport for is implementation-defined.
              Declaration

              <p:declare-step type="p:validate-with-relax-ng">
                   <p:input port="source" primary="true" content-types="xml html"/>
                   <p:input port="schema" content-types="text xml"/>
                   <p:output port="result" primary="true" content-types="xml html"/>
                   <p:output port="report" sequence="true" content-types="xml json"/>
                   <p:option name="dtd-attribute-values" select="false()" as="xs:boolean"/>
                   <p:option name="dtd-id-idref-warnings" select="false()" as="xs:boolean"/>
                   <p:option name="assert-valid" select="true()" as="xs:boolean"/>
                   <p:option name="report-format" select="'xvrl'" as="xs:string"/>
                   <p:option name="parameters" as="map(xs:QName,item()*)?"/>     
              </p:declare-step>

              -

              The values of the dtd-attribute-values and dtd-id-idref-warnings options +

              The values of the dtd-attribute-values and dtd-id-idref-warnings options must be booleans.

              If the schema document has an XML media type, then @@ -167,11 +168,11 @@ if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.

              -

              If the dtd-attribute-values option is +

              If the dtd-attribute-values option is true, then the attribute value defaulting conventions of [RELAX NG DTD Compatibility] are also applied.

              -

              If the dtd-id-idref-warnings option is +

              If the dtd-id-idref-warnings option is true, then the validator should treat a schema that is incompatible with the ID/IDREF/IDREFs feature of [RELAX NG DTD Compatibility] as if the document @@ -191,23 +192,23 @@

              Support for [RELAX NG DTD Compatibility] is implementation-defined.

              -

              Document properties

              +

              Document properties

              All document properties on the source port are preserved on the result port. -No document +No document properties on the schema port are preserved. No document properties are preserved on the report port.

              -

              3.3. Validate with Schematron

              +

              5. Validate with Schematron

              The p:validate-with-schematron step applies [Schematron] processing to the source document.

              -

              Summary

              Input portPrimarySequenceContent types
              source✔  xml html 
              schema  xml 
              Output portPrimarySequenceContent types
              result✔  xml html 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              parametersmap(xs:QName,item()*)?()
              phasexs:string'#DEFAULT'
              report-formatxs:string'svrl'
              Errors
              Error codeDescription
              err:C0054It is a dynamic error +

              Summary

              Input portPrimarySequenceContent types
              source✔  xml html 
              schema  xml 
              Output portPrimarySequenceContent types
              result✔  xml html 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              parametersmap(xs:QName,item()*)?()
              phasexs:string'#DEFAULT'
              report-formatxs:string'svrl'
              Errors
              Error codeDescription
              err:C0054It is a dynamic error if the assert-valid option is true and any Schematron assertions fail.
              err:C0151It is a dynamic error if the document supplied on schema port is not a valid Schematron @@ -219,7 +220,7 @@ implementation-defined.
              Declaration

              <p:declare-step type="p:validate-with-schematron">
                   <p:input port="source" primary="true" content-types="xml html"/>
                   <p:input port="schema" content-types="xml"/>
                   <p:output port="result" primary="true" content-types="xml html"/>
                   <p:output port="report" sequence="true" content-types="xml json"/>
                   <p:option name="parameters" as="map(xs:QName,item()*)?"/>     
                   <p:option name="phase" select="'#DEFAULT'" as="xs:string"/>   
                   <p:option name="assert-valid" select="true()" as="xs:boolean"/>
                   <p:option name="report-format" select="'svrl'" as="xs:string"/>
              </p:declare-step>

              It is a dynamic error (err:XC0151) - if the document supplied on schema port is not a valid Schematron + if the document supplied on schema port is not a valid Schematron document.

              It is a dynamic error (err:XC0054) @@ -269,23 +270,23 @@

              The output of this step may include PSVI annotations.

              -

              Document properties

              +

              Document properties

              All document properties on the source port are preserved on the result port. -No document +No document properties on the schema port are preserved. No document properties are preserved on the report port.

              -

              3.4. Validate with XML Schema

              +

              6. Validate with XML Schema

              The p:validate-with-xml-schema step applies [W3C XML Schema: Part 1] validity assessment to the source input.

              -

              Summary

              Input portPrimarySequenceContent types
              source✔  xml html 
              schema ✔ xml 
              Output portPrimarySequenceContent types
              result✔  xml html 
              report ✔ xml json 
              Option nameTypeValuesDefault value
              assert-validxs:boolean true()
              modexs:string('strict','lax') 'strict'
              parametersmap(xs:QName,item()*)? ()
              report-formatxs:string 'xvrl'
              try-namespacesxs:boolean false()
              use-location-hintsxs:boolean false()
              versionxs:string? ()
              Errors
              Error codeDescription
              err:C0011It is a +

              Summary

              Input portPrimarySequenceContent types
              source✔  xml html 
              schema ✔ xml 
              Output portPrimarySequenceContent types
              result✔  xml html 
              report ✔ xml json 
              Option nameTypeValuesDefault value
              assert-validxs:boolean true()
              modexs:string('strict','lax') 'strict'
              parametersmap(xs:QName,item()*)? ()
              report-formatxs:string 'xvrl'
              try-namespacesxs:boolean false()
              use-location-hintsxs:boolean false()
              versionxs:string? ()
              Errors
              Error codeDescription
              err:C0011It is a dynamic error if the specified schema version is not available.
              err:C0055It is a dynamic error if the implementation does not support the specified mode.
              err:C0152It is a dynamic error @@ -299,7 +300,7 @@ xs:include elements in the schema documents provided.
              Declaration

              <p:declare-step type="p:validate-with-xml-schema">
                   <p:input port="source" primary="true" content-types="xml html"/>
                   <p:input port="schema" sequence="true" content-types="xml"/>
                   <p:output port="result" primary="true" content-types="xml html"/>
                   <p:output port="report" sequence="true" content-types="xml json"/>
                   <p:option name="use-location-hints" select="false()" as="xs:boolean"/>
                   <p:option name="try-namespaces" select="false()" as="xs:boolean"/>
                   <p:option name="assert-valid" select="true()" as="xs:boolean"/>
                   <p:option name="parameters" as="map(xs:QName,item()*)?"/>     
                   <p:option name="mode" select="'strict'" values="('strict','lax')"/><!-- string -->
                   <p:option name="version" as="xs:string?"/>                    
                   <p:option name="report-format" select="'xvrl'" as="xs:string"/>
              </p:declare-step>

              It is a dynamic error (err:XC0152) -if the document supplied on schema port is not a valid XML schema +if the document supplied on schema port is not a valid XML schema document.

              @@ -314,7 +315,7 @@ “strict” or “lax”.

              Validation is performed against the set of schemas represented -by the documents on the schema port. These schemas must +by the documents on the schema port. These schemas must be used in preference to any schema locations provided by schema location hints encountered during schema validation, that is, schema locations supplied for xs:import or @@ -327,15 +328,15 @@ external documents (see [XProc 3.0]). It is implementation-defined if the documents supplied -on the schemas port are considered when resolving +on the schemas port are considered when resolving xs:include elements in the schema documents provided.

              The use-location-hints and try-namespaces options allow the pipeline author to control how the schema processor should attempt to locate schema -documents necessary but not provided on the schema -port. Any schema documents provided on the schema port +documents necessary but not provided on the schema +port. Any schema documents provided on the schema port must be used in preference to schema documents located by other means.

              @@ -393,22 +394,21 @@ with any defaulting of attributes and elements performed as specified by the XML Schema recommendation.

              -

              Document properties

              +

              Document properties

              All document properties on the source port are preserved on the result port. -No document -properties are preserved on the report port.

              +No document properties on the schemas port are preserved.

              -

              3.5. Validate with JSON schema

              +

              7. Validate with JSON schema

              The p:validate-with-json-schema step applies a JSON schema validation (as defined in [JSON schema] and other publications) to the source input.

              -

              Summary

              Input portPrimarySequenceContent types
              source✔  json 
              schema  json 
              Output portPrimarySequenceContent types
              result✔  json 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              default-versionxs:string?()
              parametersmap(xs:QName,item()*)?()
              report-formatxs:string'xvrl'
              Errors
              Error codeDescription
              err:C0163It is a dynamic error +

              Summary

              Input portPrimarySequenceContent types
              source✔  json 
              schema  json 
              Output portPrimarySequenceContent types
              result✔  json 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              default-versionxs:string?()
              parametersmap(xs:QName,item()*)?()
              report-formatxs:string'xvrl'
              Errors
              Error codeDescription
              err:C0163It is a dynamic error if the selected version is not supported.
              err:C0164It is a dynamic error if the document supplied on schema port is not a valid JSON schema document in the selected version.
              err:C0165It is a dynamic error @@ -427,81 +427,76 @@ if the selected version is not supported.

              It is a dynamic error (err:XC0164) - if the document supplied on schema port is not a valid JSON schema + if the document supplied on schema port is not a valid JSON schema document in the selected version.

              It is a dynamic error (err:XC0165) if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.

              - -

              The output from this step is a copy of the input.

              -

              Document properties

              +

              Document properties

              -

              All document properties on - the source port are preserved on the result port. - No document properties are preserved on the report port.

              +

              All document properties on the source port are preserved + on the result port. No document properties on the schemas are preserved. + No document properties are preserved on the report port.

              +

              Errata, April 2024

              + +

              Corrected an error in the sequence type for the default-version option +to allow it to be optional.

              +
              -

              3.6. Validate with DTD

              +

              8. Validate with a DTD

              The p:validate-with-dtd step validates XML with a DTD.

              -

              Summary

              Input portPrimarySequenceContent types
              source✔  xml html 
              Output portPrimarySequenceContent types
              result✔  xml 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              report-formatxs:string'xvrl'
              serializationmap(xs:QName,item()*)?()
              Errors
              Error codeDescription
              err:C0210It is a dynamic error -if the assert-valid option on p:validate-with-dtd -is true -and the input document is not valid.
              Declaration

              <p:declare-step type="p:validate-with-dtd">
                   <p:input port="source" primary="true" content-types="xml html"/>
                   <p:output port="result" primary="true" content-types="xml"/>
                   <p:output port="report" sequence="true" content-types="xml json"/>
                   <p:option name="report-format" select="'xvrl'" as="xs:string"/>
                   <p:option name="serialization" as="map(xs:QName,item()*)?"/>  
                   <p:option name="assert-valid" select="true()" as="xs:boolean"/>
              </p:declare-step>

              +

              Summary

              Input portPrimarySequenceContent typesDefault binding
              source✔  xml html text 
              doctype ✔ text p:empty
              Output portPrimarySequenceContent typesDefault binding
              result✔  xml 
              report ✔ xml json 
              Option nameTypeDefault value
              assert-validxs:booleantrue()
              report-formatxs:string'xvrl'
              serializationmap(xs:QName,item()*)?()
              Declaration

              <p:declare-step type="p:validate-with-dtd">
                   <p:input port="source" primary="true" content-types="xml html text"/>
                   <p:input port="doctype" content-types="text" sequence="true">
                        <p:empty/>
                   </p:input>
                   <p:output port="result" primary="true" content-types="xml"/>
                   <p:output port="report" sequence="true" content-types="xml json"/>
                   <p:option name="report-format" select="'xvrl'" as="xs:string"/>
                   <p:option name="serialization" as="map(xs:QName,item()*)?"/>  
                   <p:option name="assert-valid" select="true()" as="xs:boolean"/>
              </p:declare-step>

              DTD validation differs from the other XML validation technologies in that it is applied during parsing. It isn’t possible to validate an XML data model with -a DTD. This step necessarily serializes and reparses.

              - -

              The p:validate-with-dtd step serializes the document on the source -port and parses the serialization with a -validating XML parser. Any warning or error messages produced by the parser will -appear on the report port.

              +a DTD. This step necessarily serializes the source document and then parses it +back into a new data model. +

              -

              Note

              -

              The serialization options must include at least the -doctype-system property (without a system identifier, the -document cannot be successfully parsed with a validating parser).

              -
              +

              There are several possible approaches, with varying degrees of complexity. +The general model is that the contents of the doctype port and +the result of serializing the source are concatenated together. +

              -

              It is a dynamic error (err:XC0210) -if the assert-valid option on p:validate-with-dtd -is true -and the input document is not valid.

              +
              -

              The output from this step is a copy of the input. If validation was -successful, the output may have been augmented by the DTD. (For example, default -attributes may have been added.)

              -

              Using an internal subset

              +
              • +

                In the simple case, the doctype is empty and source +document is simply serialized. In order to have any chance of being DTD-valid, +the serialization properties must include at least a doctype-system +property.

                +
              • +

                If an internal subset is required, it is provided on the doctype port. +In this case, the source document must be serialized without +a doctype-system property; both the internal and external declarations must appear +on the doctype port.

                +
              • +

                Finally, if a text document is provided on the source port, +it is simply concatenated with the doctype port.

                +
              -

              To validate a document with an internal subset, construct a text document -that is a syntactically valid XML document with the internal -subset, use p:cast-content-type to create an XML document, -and then validate the resulting document with this step.

              -
              +

              The resulting text is parsed using a validating XML parser.

              -

              Document properties

              +

              Any warning or error messages produced by the parser will appear on the +report port. If validation succeeds, the validated document will appear on the +result port.

              -

              All document properties -on the source port are preserved on the result -port. No document properties are -preserved on the report port.

              -
              - -

              4. Step Errors

              +

              9. Step Errors

              -

              These steps can raise +

              This step can raise dynamic errors.

              @@ -548,10 +543,7 @@ document in the selected version.

              See: Validate with JSON schema

              err:XC0165

              It is a dynamic error if the assert-valid option on p:validate-with-json-schema is true - and the input document is not valid.

              See: Validate with JSON schema

              err:XC0210

              It is a dynamic error -if the assert-valid option on p:validate-with-dtd -is true -and the input document is not valid.

              See: Validate with DTD

              + and the input document is not valid.

              See: Validate with JSON schema

              @@ -591,17 +583,25 @@ p:validate-with-schematron. See Section 2, “Common Options and Outputs”.
            1. The parameters supported by the validation steps and their semantics are implementation-defined, and they can be different for each validation step. See Section 2, “Common Options and Outputs”.
            2. Support for is -implementation-defined. See Section 3.2, “Validate with RELAX NG”.
            3. How the Schematron implementation is selected is - implementation-defined. See Section 3.3, “Validate with Schematron”.
            4. The list of supported Schematron implementations and - their associated values is implementation-defined. See Section 3.3, “Validate with Schematron”.
            5. Which parameters the +implementation-defined. See Section 4, “Validate with RELAX NG”.
            6. How the Schematron implementation is selected is + implementation-defined. See Section 5, “Validate with Schematron”.
            7. The list of supported Schematron implementations and + their associated values is implementation-defined. See Section 5, “Validate with Schematron”.
            8. Which parameters the c:compile map supports for a given Schematron implementation is - implementation-defined. See Section 3.3, “Validate with Schematron”.
            9. Which parameters this conversion from native reporting format to XVRL supports is - implementation-defined. See Section 3.3, “Validate with Schematron”.
            10. It is + implementation-defined. See Section 5, “Validate with Schematron”.
            11. Which parameters this conversion from native reporting format to XVRL supports is + implementation-defined. See Section 5, “Validate with Schematron”.
            12. It is implementation-defined if the documents supplied on the schemas port are considered when resolving -xs:include elements in the schema documents provided. See Section 3.4, “Validate with XML Schema”.
            13. If +xs:include elements in the schema documents provided. See Section 6, “Validate with XML Schema”.
            14. If the schema does not specify a version and option default-version - is empty, the version used is implementation-defined. See Section 3.5, “Validate with JSON schema”.
              15. + is empty, the version used is implementation-defined. See Section 7, “Validate with JSON schema”. + + +

              A.2. Implementation-dependent features

              + + +

              The following features are implementation-dependent:

              + +
                @@ -684,23 +684,7 @@ Implementations are not required to document or explain how implementation-dependent features are performed.

                -

                D. Change log

                - - -

                This appendix catalogs recent non-editorial changes.

                - -
                - - -
                1. -

                  Corrected an error in the sequence type for the default-version option -on p:validate-with-json-schema to allow it to be optional.

                  -
                2. -

                  Added the p:validate-with-dtd step.

                  -
                -
                - -

                E. Ancillary files

                +

                D. Ancillary files

                This specification includes by reference a number of diff --git a/master/head/validation/specification.xml b/master/head/validation/specification.xml index 6b7eaa139..6e934725c 100644 --- a/master/head/validation/specification.xml +++ b/master/head/validation/specification.xml @@ -67,8 +67,7 @@ step for This specification describes the p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, -p:validate-with-nvdl, p:validate-with-json-schema, -and p:validate-with-dtd +p:validate-with-nvdl, and p:validate-with-json-schema steps. Each is independently optional. A machine-readable description of these steps may be found in steps.xpl. @@ -130,9 +129,6 @@ validation steps and their semantics are xvrl:map-to-severity, and xvrl:xpath-notation. -

                -Step library -
                Validate with NVDL @@ -165,15 +161,20 @@ validation steps and their semantics are p:validate-with-nvdl is true and the input document is not valid. - The output from this step is a copy of the input. The output of this - step may include PSVI annotations. + The output from this step is a copy of the input. The output of this step may include PSVI + annotations. + + Should the step also provide the and + options for Relax NG validations? Is there a way to instruct Jing + to use these options, maybe in NVDL extension attributes? Probably not in the foreseeable future. + + Document properties - All document properties - on the source port are preserved on the result - port. No document properties are - preserved on the report port. + All document properties on the source port are preserved + on the result port. No document properties on the schemas and nvdl ports + are preserved. No document properties are preserved on the report port.
                @@ -235,7 +236,7 @@ augmented by application of the Document properties All document properties on the source port are preserved on the result port. -No document +No document properties on the schema port are preserved. No document properties are preserved on the report port.
                @@ -313,7 +314,7 @@ input. Document properties All document properties on the source port are preserved on the result port. -No document +No document properties on the schema port are preserved. No document properties are preserved on the report port. @@ -438,8 +439,7 @@ by the XML Schema recommendation. Document properties All document properties on the source port are preserved on the result port. -No document -properties are preserved on the report port. +No document properties on the schemas port are preserved. @@ -476,24 +476,30 @@ properties are preserved on the report port. if the option on p:validate-with-json-schema is true and the input document is not valid. - - The output from this step is a copy of the input. Document properties - All document properties on - the source port are preserved on the result port. - No document properties are preserved on the report port. + All document properties on the source port are preserved + on the result port. No document properties on the schemas are preserved. + No document properties are preserved on the report port. + +Errata, April 2024 +Corrected an error in the sequence type for the default-version option +to allow it to be optional. +
                - Validate with DTD + Validate with a DTD The p:validate-with-dtd step validates XML with a DTD. - + + + + @@ -503,51 +509,46 @@ properties are preserved on the report port. DTD validation differs from the other XML validation technologies in that it is applied during parsing. It isn’t possible to validate an XML data model with -a DTD. This step necessarily serializes and reparses. - -The p:validate-with-dtd step serializes the document on the source -port and parses the serialization with a -validating XML parser. Any warning or error messages produced by the parser will -appear on the report port. - - -The serialization options must include at least the -doctype-system property (without a system identifier, the -document cannot be successfully parsed with a validating parser). - +a DTD. This step necessarily serializes the source document and then parses it +back into a new data model. + -It is a dynamic error -if the option on p:validate-with-dtd -is true -and the input document is not valid. +There are several possible approaches, with varying degrees of complexity. +The general model is that the contents of the doctype port and +the result of serializing the source are concatenated together. + -The output from this step is a copy of the input. If validation was -successful, the output may have been augmented by the DTD. (For example, default -attributes may have been added.) + + +In the simple case, the doctype is empty and source +document is simply serialized. In order to have any chance of being DTD-valid, +the serialization properties must include at least a doctype-system +property. + + +If an internal subset is required, it is provided on the doctype port. +In this case, the source document must be serialized without +a doctype-system property; both the internal and external declarations must appear +on the doctype port. + + +Finally, if a text document is provided on the source port, +it is simply concatenated with the doctype port. + + - -Using an internal subset +The resulting text is parsed using a validating XML parser. -To validate a document with an internal subset, construct a text document -that is a syntactically valid XML document with the internal -subset, use p:cast-content-type to create an XML document, -and then validate the resulting document with this step. - +Any warning or error messages produced by the parser will appear on the +report port. If validation succeeds, the validated document will appear on the +result port. - -Document properties -All document properties -on the source port are preserved on the result -port. No document properties are -preserved on the report port. -
                -
                Step Errors -These steps can raise +This step can raise dynamic errors. @@ -603,6 +604,14 @@ how implementation-defined features are
                + +
                +Implementation-dependent features + +The following features are implementation-dependent: + + +
                @@ -685,22 +694,6 @@ implementation has discretion in how it is performed. Implementations are not required to document or explain how implementation-dependent features are performed. - -Change log - -This appendix catalogs recent non-editorial changes. - - - -Corrected an error in the sequence type for the default-version option -on p:validate-with-json-schema to allow it to be optional. - - -Added the p:validate-with-dtd step. - - - - Ancillary files diff --git a/master/head/validation/steps.xpl b/master/head/validation/steps.xpl index 62b8adc71..8186e4f27 100644 --- a/master/head/validation/steps.xpl +++ b/master/head/validation/steps.xpl @@ -58,7 +58,10 @@ - + + + +