[Bug 29960] New: [xslt3.0] On the need to report static errors

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29960

            Bug ID: 29960
           Summary: [xslt3.0] On the need to report static errors
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 27 October 2016 09:21:45 UTC