- 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