- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 02 Apr 2006 22:02:47 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3067 Summary: [XSLT 2.0] Error XTDE1450 Product: XPath / XQuery / XSLT Version: Candidate Recommendation Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: XSLT 2.0 AssignedTo: mike@saxonica.com ReportedBy: mike@saxonica.com QAContact: public-qt-comments@w3.org Section 3.9 (Forwards compatible processing) says: Within a section of a stylesheet where forwards-compatible behavior is enabled: if an element in the XSLT namespace appears as part of a sequence constructor, and XSLT 2.0 does not allow such elements to appear as part of a sequence constructor, then: 1. If the element has one or more xsl:fallback children... 2. If the element has no xsl:fallback children, then a static error is reported in the same way as if forwards-compatible behavior were not enabled. This would imply that error XTSE0010 is raised. However we have a specific error XTDE1450 that covers this case: [ERR XTDE1450] When a processor performs fallback for an instruction element, if the instruction element has one or more xsl:fallback children, then the content of each of the xsl:fallback children must be evaluated; it is a non-recoverable dynamic error if it has no xsl:fallback children. Note however that this is a dynamic error rather than a static error. This appears to be a relic of the pre-"use-when" situation. We've been moving towards raising static errors for such conditions. I propose (a) that we modify the rule cited for forwards compatibility to replace the phrase "as if forwards-compatible behavior were not enabled" with a reference to error 1450, and (b) that error 1450 becomes a static error, changing its code to XTSE1450.
Received on Sunday, 2 April 2006 22:03:36 UTC