29960 2016-10-27 09:21:34 +0000 [xslt3.0] On the need to report static errors 2016-10-31 23:27:02 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC All CLOSED FIXED P2 normal --- 1 mike mike abel.braaksma public-qt-comments oldest_to_newest 127968 0 mike 2016-10-27 09:21:34 +0000 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. 127969 1 abel.braaksma 2016-10-27 15:59:41 +0000 Good point on that last para. Is it worthwhile adding a Note that errors in XML are outside of the scope of static errors and will likely be reported, but since creating an XDM from a source is implementation-defined, processor's behavior for XML errors, or whether these are corrected or ignored, is also implementation-defined. (I'm not saying I'm considering running html-tidy to fix XSLT-XML or something, but externally parsed entities that aren't required and cannot be fetched could reasonably be ignored. Moreover, I think this already is implementation-defined.) 127970 2 abel.braaksma 2016-10-27 16:00:51 +0000 Putative? Alleged? ;) 127973 3 mike 2016-10-27 17:01:30 +0000 Proposal accepted including the suggestion in comment 1. 127990 4 mike 2016-10-31 23:27:02 +0000 The changes have been applied.