Proposed XProc Specification Errata

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.

After a subpipelinebranch is selected, it is evaluated as if only it its children had been present.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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

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.

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.