Proposed XProc Specification Errata

Abstract

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.

Substantive errata

Editorial errata

E11, 01 February 2012

Globally: Move the conformance phrases into the conformance appendix.

E10, 21 July 2011

Section 4.6 p:try: 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.
Section 4.6.1 The Error Vocabulary: 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.

E09, 3 February 2011

Section 7.1.10.5 HTTP Request Example

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>

E08, 2 February 2011

Section 3.1 XProc Namespaces

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.

E07, 2 February 2011

Section 2 Pipeline Concepts

Clarify that the output of a compound step may be connected to any readable port, as specified in 5.11 p:pipe

Within a compound step, the declared outputs of the step can be connected to:

Any one of the compound step's readable ports.
The output port of some contained step.
A fixed, inline document or sequence of documents.
A document read from a URI.

E06, 2 February 2011

Section 2 Pipeline Concepts: Add definitions for pipeline processor and implementation.

The result of evaluating a pipeline (or subpipeline) is the result of evaluating the steps that it contains, in an order consistent with the connections between them. A pipeline must behave as if it evaluated each step each time it is encountered.

[Definition: The software responsible for evaluating XProc pipelines is referred to as an XProc Processor. In contexts where the kind of processor is unambiguous, it is sometimes referred to simple as “the processor”.]

[Definition: A specific product that performs the functions of an XProc processor is referred to as an implementation.]

Unless otherwise indicated, implementations must not assume that steps are functional (that is, that their outputs depend only on their inputs, options, and parameters) or side-effect free.

E05, 2 February 2011

Section 4.4.1 p:xpath-context: Make it clear that err:XD0026 applies in this case too.

…In an XPath 2.0 implementation, the context item is undefined. It is a dynamic error (err:XD0026) if the select expression makes reference to the context node, size, or position when the context item is undefined.

E04, 2 February 2011

Section 4.4 p:choose: Make it clear that err:XD0026 applies in this case too.

…In an XPath 2.0 implementation, the context item is undefined. It is a dynamic error (err:XD0026) if the select expression makes reference to the context node, size, or position when the context item is undefined.

E03, 2 February 2011

Section 5.13 p:document: Make it clear that support for xml:id is implementation-defined. Add a new paragraph after the paragraph that begins “The parser which the…”:

Support for xml:id in XProc processors is implementation-defined. Implementors are encouraged to support xml:id wherever practical.

E02, 22 June 2010

Section 7.1.10.3 Managing the Response: 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:

If the media type (as determined by the 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.

E01, 22 June 2010

Section 7.1.10.4 Converting Response Entity Bodies: Make it clear that the final note only applies when no charset is specified by changing the text of the note as follows:

Given the above description, any content identified as text/html without specifying a Unicode character encoding will be encoded as (escaped) text or base64-encoded in the c:body element, as HTML isn't always well-formed XML. A user can attempt to convert such content into XML using the p:unescape-markup step.