- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 Jan 2014 12:44:20 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24234 Bug ID: 24234 Summary: Unclear resolution of default attributes for named modes and error XTSE0545 Product: XPath / XQuery / XSLT Version: Last Call drafts Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: XSLT 3.0 Assignee: mike@saxonica.com Reporter: abel.braaksma@xs4all.nl QA Contact: public-qt-comments@w3.org For an unnamed mode, we have the following attribute resolution defined: "For the unnamed mode, the effective value of each attribute is taken from an xsl:mode declaration that has no name attribute, and that specifies an explicit value for the required attribute. If there is no such declaration, the default value of the attribute is used. [...]" For a named mode, we have the following attribute resolution defined: "For any named mode, the effective value of each attribute is taken from an xsl:mode declaration that has a matching name in its name attribute, and that specifies an explicit value for the required attribute. [...]" The difference between the two definitions is that for a named mode, it is not clear how default values for the attributes are applied. I assume it is meant to work the same way as for the default mode. I propose to add the sentence "If there is no such declaration, the default value of the attribute is used." to the named mode attribute resolution rule. This (slight) ambiguity also applies to XTSE0545, which is defined as follows: "[ERR XTSE0545] It is a static error if a named or unnamed mode contains two conflicting values for the same attribute in different xsl:mode declarations having the same import precedence, unless there is another definition of the same attribute with higher import precedence. [...]" This applies to, for instance, the following declarations: <!-- throws XTSE0545??? --> <xsl:mode streamable="yes" /> <xsl:mode on-no-match="deep-copy" /> It is my understanding, that if we apply the first attribute resolution rule above (the one for unnamed modes), that by extension, the previous snippet should throw XTSE0545, because the second declaration has an implicit default streamable="no", and both have the same import precedence. The part being unclear in the error definition is the word "contains". Does it, or does it not, apply _only_ to explicit mode attributes? My preference is clarity: implicit mode attributes also raise XTSE0545. This has the consequence that any non-default mode attribute defined under the same import precedence must be included in a redefinition for it to be valid. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 8 January 2014 12:44:22 UTC