This document records all known errors in the XProc: An XML Pipeline Language; for updates see the latest version.
The errata are numbered, classified as Substantive or Editorial, and listed in reverse chronological order of their date of publication in each category. Changes to the text of the spec are indicated thus: deleted text, new text, modified text . Substantive corrections are proposed by the XML Processing Model Working Group, which has consensus that they are appropriate; they are not to be considered normative until approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation.
Please email error reports to public-xml-processing-model-comments@w3.org.
To address bug 21006, make the following changes.
Change the first paragraph after the syntax box as follows:
A p:choose has no inputs. It contains an arbitrary number of alternative subpipelinesbranches (identified with p:when and p:otherwise elements), exactly one of which will be evaluated.
Change the fourth paragraph after the syntax box as follows:
After a subpipelinebranch is selected, it is evaluated as if only it its children had been present.
To address bug 21003, make the following changes.
Change the penultimate paragraph of 4.4 as follows:
The p:choose can specify the context node against which the XPath expressions that occur on each branch are evaluated. The context node is specified as a connection in the p:xpath-context. If no explicit connectionp:xpath-context is provided, the default readable port is used. In an XPath 1.0 implementation, if the context node is connected to p:empty, or is unconnected and the default readable port is undefined, an empty document node is used instead as the context. In an XPath 2.0 implementation, the context item is undefined.
And delete the last paragraph of 4.4.1:
In an XPath 1.0 implementation, if the context node is connected to p:empty, or is unconnected and the default readable port is undefined, an empty document node is used instead as the context. In an XPath 2.0 implementation, the context item is undefined.
To address bug 21002, change the fourth paragraph (the first paragraph after the first syntax box) as follows:
An option may be declared as required. If an option is required, it is an error to invoke that step without specifying a value for that option. For steps invoked within a pipeline, it is a static error (err:XS0018) to invoke the step specify an invocation without providing a value for thata required option. For pipelines invoked directly by an external environment (informally, top-level pipelines), this error cannot be detected statically. It is a dymamic error (err:XD????) to invoke a pipeline without specifying a value for a required option.
We leave it to the discretion of the editor to define the new dynamic error number.
To address bug 20995, add the following errata text somewhere in 2.6:
XProc 1.0 fails to adequately address the XPath requirement that the document-uri property of a document must be a stable identifier. Informally, if two nodes have the same document-uri, they must be the same document. The Working Group concludes that attempting to address this in the 1.0 specification is infeasible. It plans to address this issue explicitly in 2.0.
In the meantime, implementors are encouraged to satisfy the XPath constraint as much as is practical. The XProc 1.0 specification fails to mention the document-uri property, so there's no explicit text that forbids an implementor from satisfying it.
To address bug 21007, make the following changes to the paragraph below the first syntax box:
The value of the type can be from any namespace provided that the expanded-QName of the value has a non-null namespace URI. It is a static error (err:XS0025) if the expanded-QName value of the type attribute is in no namespace or in the XProc namespace that is not the XProc namespace.. Except as described in Section 2.13, “Versioning Considerations”, the XProc namespace must not be used in the type of steps. Neither users nor implementers may define additional steps in the XProc namespace.
To address action A-230-05, make the following changes to the note under “variable bindings”:
An option that has neither a specified value nor a default value will not appear as an in-scope XPath variable. Consequently, an attempt to refer to that variable an XPath variable whose name is the name of such an option will raise an error.
To address action A-227-01, make the following changes to the penultimate paragraph of the section:
The scope of option and variable names is determined by where they are declared. When an option is declared with p:option (or a variable with p:variable), unless otherwise specified, its scope consists of the sibling elements that follow its declaration and the descendants of those siblings. It is a static error (err:XS0004) if an option or variable declaration duplicates the name of any other option or variable in the same environment. That is, no option or variable may lexically shadow another option or variable with the same name among its preceding siblings.
To address bug 21004, make the following changes to the four paragraphs which follow the syntax box:
If a select expression is given, itThe select expression is evaluated as an XPath expression using the appropriate context as described in Section 2.6, “XPaths in XProc”, for the enclosing container, with the addition of bindings for all preceding-sibling p:variable and p:option elements. Regardless of the implicit type of the expression, when XPath 1.0 is being used, the string value of the expression becomes the value of the variable; when XPath 2.0 is being used, the type is treated as an xs:untypedAtomic.
Since all in-scope bindings are present in the Processor XPath Context as variable bindings, select expressions may refer to the value of in-scope bindings by variable reference. If a variable reference uses a QName that is not the name of an in-scope binding, an XPath evaluation error will occur.
If a select expression is given, theThe readable ports available for document connections are the readable ports in the environment inherited by the first step in the surrounding container's contained steps. However, in order to avoid ordering paradoxes, it is a static error (err:XS0019) for a variable's document connection to refer to the output port of any step in the surrounding container's contained steps.
If a select expression is given butIf no document connection is provided, the implicit connection is to the default readable port in the environment inherited by the first step in the surrounding container's contained steps. If there is no default readable port, the connection is treated as if p:empty was specified.
Move the conformance phrases into the conformance appendix.
In the context of a p:catch
, the error
port is an input port
not an output port; remove the word output.
What appears on the error output port is an error document. The error document may contain messages generated by steps that were part of the initial subpipeline. Not all messages that appear are indicative of errors; for example, it is common for all xsl:message output from the XSLT component to appear on the error output port. It is possible that the component which fails may not produce any messages at all. It is also possible that the failure of one component may cause others to fail so that there may be multiple failure messages in the document.
Also here:
The p:try/p:catch mechanism gives pipeline authors the opportunity to process the errors that caused the p:try to fail. In order to facilitate some modicum of interoperability among processors, errors that are reported on the error output port of a p:catch should conform to the format described here.
Make request/response consistent with respect to the “detailed” setting.
<c:request xmlns:c="http://www.w3.org/ns/xproc-step"
method="POST" href="http://www.example.com/form-action"
detailed="true">
<c:body content-type="application/x-www-form-urlencoded">
name=W3C&spec=XProc
</c:body>
</c:request>
Add text to discourage implementors from creating errors in the xproc-error
namespace.
http://www.w3.org/ns/xproc-error
The namespace used for errors. The conventional prefix
“err:
” is used for this namespace.
Implementors are discouraged from inventing new error codes in the XProc error namespace; they are reserved for future versions of this specification or other working group products.
Clarify that the output of a compound step may be connected to any readable port, as specified in 2.2 Inputs and Outputs
Add definitions for pipeline processor and implementation.
Make it clear that err:XD0026
applies in this case too.
Make it clear that err:XD0026
applies in this case too.
Make it clear that support for xml:id
is implementation-defined.
Add a new paragraph after the paragraph that begins “The parser which the…”:
xml:id
in XProc processors is implementation-defined. Implementors
are encouraged to support xml:id
wherever practical.Make it clear that “decoded if necessary” in bullet 1 of the last bulleted list applies to the content encoding by changing the text of the bullet as follows:
override-content-type
attribute or the Content-Type
response header) is an XML media type,
the entity is decoded if necessary
(if a Content-Encoding
response header is present and
specifies
an encoding other than identity
),
then parsed as an XML document and
produced on the result output port as the entire output of the step.Make it clear that the final note only applies when no charset is specified by changing the text of the note as follows: