ACTION 2016-10-20-002: ABr to open a Bugzilla entry suggesting
detailed spec changes needed to meet the requirement to allow
processor modes which do not raise all possible static errors
(following on from our discussion of the thread starting at
https://lists.w3.org/Archives/Public/public-xsl-wg/2016Oct/0002.html (member only)

Since I'm interested in getting this done I'll hijack the action.

The proposal is that we should permit a mode of operation in which a transformation can execute without reporting static errors in code that's not executed.

To put this in perspective, we've done some trial DocBook runs that show about 12000 template rules being compiled, with fewer than 10% of these being executed - basically because most instance documents use a small subset of the vocabulary. Compiling the stylesheet takes an order of magnitude longer than actually doing the transformation on a typical input file; and many workflows will compile the stylesheet every time it is executed.

We therefore think users will benefit from a mode of operation in which static analysis of the body of a template rule takes place only on first execution.

But we recognize of course that during development, stylesheet developers want to have all static errors reported (perhaps up to some threshold).

The proposal is therefore to rewrite the paragraph in 2.13 Error Handling:

Errors classified in this specification as static errors must be signaled by all implementations: that is, the processor must indicate that the error is present. A static error must be signaled even if it occurs in a part of the stylesheet that is never evaluated. Static errors are never recoverable. After signaling a static error, a processor may continue for the purpose of signaling additional errors, but it must eventually terminate abnormally without producing a principal result .

as follows:

A processor MUST provide a mode of operation that takes a (putative) stylesheet package as input and enables the user to determine whether or not that package contains any static errors.

Note: The manner in which static errors are reported, and the behavior when there are multiple static errors, are left as design choices for the implementer. It is RECOMMENDED that the error codes defined in this specification should be made available in any diagnostics.

A processor MAY also provide a mode of operation in which static errors in parts of the stylesheet that are not evaluated can go unreported.

Note: For example, when operating in this mode, a processor might report static errors in a template rule only if the input document contains nodes that match that template rule. Such a mode of operation can provide performance benefits when large and well-tested stylesheets are used to process source documents that might only use a small part of the XML vocabulary that the stylesheet is designed to handle.

In the penultimate paragraph of section 2.13, change

Implementations must use the codes defined in these specifications when signaling errors, to ensure that xsl:catch behaves in an interoperable way across implementations.

to

Implementations must use the codes defined in these specifications when signaling dynamic errors, to ensure that xsl:catch behaves in an interoperable way across implementations.