- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 19 Oct 2005 19:42:38 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2388 Summary: Required static error checking unduly constraints implementations Product: XPath / XQuery / XSLT Version: Working drafts Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: XSLT 2.0 AssignedTo: mike@saxonica.com ReportedBy: terje@in-progress.com QAContact: public-qt-comments@w3.org 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
Received on Wednesday, 19 October 2005 19:42:45 UTC