- 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