This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Requiring that conforming XSLT processors must detect and signal static errors before execution imposes severe constraints on implementations that will disallow certain optimizations and execution models. For example, some XSLT implementations may minimize latency (the delay before generating the first output) by performing on-demand analysis or compilation of template rules as they are applied, or by dynamically evaluate/interpret a simplified stylesheet module without compiling it or first performing static analysis. Proposed solution: Turn static error checking into an optional feature. An XSLT processor with a Static Error Checking feature signals all static errors in a style sheet before processing any documents. A Basic XSLT processor without static error checking would detect and signal static errors at the latest as if they were dynamic errors, but might signal static errors earlier depending on the implementation. Style sheet designers would then be able to use a processor with static error checking during debugging, while e.g. web browsers and other optimized real-time processors could bypass static error checking for speed and to minimize latency. -- Terje
Unfortunately this comment comes very late in the day. We've been develoing the spec for five years, and there have been opportunities to review it every step along the way. At the moment we're trying to get the final bugs out before we finish. The comment will be considered by the Working Group, though not during the Last Call phase which is now closed. I'm recategorizing it as "LATER" which means it will go on the queue to be looked at in the next round. Michael Kay (personal response)
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.
Despite Jim Melton's administrative closure of this bug, the WG reviewed it on 15 March 2007 and felt that there was room for further clarification of the text, which the editor was asked to propose. Proposal: In 2.9, in the definition of "static error", change "An error that is detected by examining a stylesheet before execution starts" to "An error that can be detected by examining a stylesheet before execution starts". I feel that this simple change is sufficient to remove any implication that static analysis and error detection must complete before evaluation starts, while retaining the rule that if static errors are present, they must be reported. We already have the rule "If more than one error arises, an implementation is not required to signal any errors other than the first one that it detects. It is implementation-dependent which of the several errors is signaled. This applies both to static errors and to dynamic errors.", which implies that if both static and dynamic errors are present, the system is allowed to report a dynamic error in preference to a static error.
The WG met on 17 April 2007 at the F2F at Red Hat and reviewed and accepted M. Kay's proposal.
This completes erratum E5