This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I am struggling to work out which errors to use for the format and cdata-section-elements for the xsl:result-document element. There are no specific error codes for the cdata-section-elements attribute, so I believe that (potentially) XTSE0020, XTDE0030, XTSE0280 and XTDE0290 could apply. XTSE0020 and XTDE0030 are defined as follows: [ERR XTSE0020] It is a static error if an attribute (other than an attribute written using curly brackets in a position where an attribute value template is permitted) contains a value that is not one of the permitted values for that attribute. [ERR XTDE0030] It is a non-recoverable dynamic error if the effective value of an attribute written using curly brackets, in a position where an attribute value template is permitted, is a value that is not one of the permitted values for that attribute. If the processor is able to detect the error statically (for example, when any XPath expressions within the curly brackets can be evaluated statically), then the processor may optionally signal this as a static error. These make it clear that for an invalid QName, if no {}s are used then the error is XTSE0020, otherwise XTDE0030 Consider the errors XTSE0280 and XTDE0290: [ERR XTSE0280] In the case of a prefixed QName used as the value of an attribute in the stylesheet, or appearing within an XPath expression in the stylesheet, it is a static error if the defining element has no namespace node whose name matches the prefix of the QName. [ERR XTDE0290] Where the result of evaluating an XPath expression (or an attribute value template) is required to be a lexical QName, then unless otherwise specified it is a non-recoverable dynamic error if the defining element has no namespace node whose name matches the prefix of the lexical QName. This error may be signaled as a static error if the value of the expression can be determined statically. In this case if cdata-section-elements contains no {}s and a QName whose value has an invalid prefix then does this count as an XTSE0280 (as with the distinction between XTSE0020/XTDE0030) or should it always raise XTDE0290? XTDE1460 is defined as follows [ERR XTDE1460] It is a non-recoverable dynamic error if the effective value of the format attribute is not a valid lexical QName, or if it does not match the expanded-QName of an output definition in the stylesheet. If the processor is able to detect the error statically (for example, when the format attribute contains no curly brackets), then the processor may optionally signal this as a static error. Clearly this supersedes both XTSE0020 and XTDE0030 for the format element; but it is unclear whether XTSE0280 and XTDE0290 still apply. My understanding is that they do and which error is raised depends on whether there are {}s in the attribute value, but this could be interpreted differently.
The XSLTS test "errorcode1460b" tests the case of the format attribute having an unbound prefix, and expects XTDE1460, but as I stated above my reading of the specification leads me to believe that this error code should be XTSE0280.
Of course, where I said XTSE0280 above, I meant XTDE0290.
Personal response: I think it's worth pointing out that the error codes in XSLT 2.0 are not intended to be a conformance issue. See section 2.9: <quote>These error codes are used to label error conditions in this specification, and are summarized in E Summary of Error Conditions). They are provided primarily for ease of reference. Implementations may use these codes when signaling errors, but they are not required to do so. </quote> Following this reasoning, test cases publish an expected error code, but an implementation is not required to deliver the exact same error code in order to pass the test. The introduction of try/catch in XSLT 2.1 means we may have to be a bit more prescriptive about error codes in future, especially those for dynamic errors, and this feedback is therefore useful. However, I don't think that a failure to be 100% prescriptive about which error code to raise in every situation should be regarded as a bug in the 2.0 specification; we never intended to achieve that level of predictability.
Proposal is to make no change for 2.0 (improving the details of which error codes are raised when is a task that will never finish). For 3.0, change the definition [ERR XTSE0280] In the case of a prefixed QName used as the value of an attribute in the stylesheet, or appearing within an XPath expression in the stylesheet, to [ERR XTSE0280] In the case of a prefixed QName used as the value (or as part of the value) of an attribute in the stylesheet, or appearing within an XPath expression in the stylesheet,
I agree with this fix and will mark the bug closed. It does not seem to address the particular confusions I was having, but upon closer rereading I believe that the current text is non-ambiguous (does this make the bug INVALID, even though a fix was applied?) I will raise a separate bug against the test errorcode1460b.