This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This bug was first sent to the XSL WG mailing list [1], a copy of the message follows: Different from other declarations, an attribute set declaration with the same name doesn't override the previous attribute set, but augments it.We went through the specification on the (I think) relevant sections, but wecouldn't find a definitive rule how to deal with conflicting situations, like when visibility is not equal. Example: Inside a package: <xsl:attribute-set name="foo" visibility="private"> <xsl:attribute name="a" /> </xsl:attribute-set> <xsl:attribute-set name="foo" visibility="public"> <xsl:attribute name="b" /> </xsl:attribute-set> <xsl:attribute-set name="foo" visibility="final"> <xsl:attribute name="c" /> </xsl:attribute-set> I think we need rules for the following scenario's: 1) Which attribute-set(s) is/are overriden when you override attribute-set"foo"? 2) Which attribute-set(s) is/are referenced when xsl:override is used within an overriding attribute-set of "foo"? 3) What attributes are included when nothing is overriden for "foo"? 4) What would cause an error to be raised for trying to override a finalattribute-set "foo"? My preference would go to the following: disallow different visibility on an attribute-set with the same name and the same import precedence. That way, we don't have to deal with potentially complex rules and, possibly worse, hard-to-understand behavior of stylesheets that accidentally forget the visibility attribute (it defaults to private). [1] https://lists.w3.org/Archives/Member/w3c-xsl-wg/2013Jul/0046.html
I would propose to tackle this as follows. First, refine the terminology, as we currently do with xsl:key, xsl:decimal-format, and xsl:output. We say for example [Definition: A key is defined as a set of xsl:key declarations in the same package that share the same name.] and we should similarly say that an attribute set is a defined as a set of xsl:attribute-set declarations in the same package that share the same name. Then (again by analogy with xsl:key and collation) require that all the declarations making up an attribute set have the same value for the visibility attribute. Then make it clear that the attribute set "component" is an attribute set, not an xsl:attribute-set declaration, and that constructs like xsl:accept and xsl:override apply to the attribute set as a whole.
That looks like a viable solution, as it effectively makes it impossible to have different visibilities for one accumulated attribute set.
Detailed proposal 1. Change the definition of "attribute set" in 10.2 from [Definition: The xsl:attribute-set element defines a named attribute set: that is, a collection of attribute definitions that can be used repeatedly on different constructed elements.] to (text modelled closely on xsl:key): Attribute sets provide named collections of attributes that can be used repeatedly on different elements. The xsl:attribute-set declaration is used to declare attribute sets. The name attribute specifies the name of the attribute set. The value of the name attribute is an EQName, which is expanded as described in 5.1 Qualified Names. [Definition: An attribute set is defined as a set of xsl:attribute-set declarations in the same package that share the same name.] 2. Add the rule (in 10.2): All the xsl:attribute-set declarations making up the definition of an attribute set (that is all declarations within the same package sharing the same name) MUST have the same visibility: that is, they must either have no visibility attribute, or have identical visibility attributes. 3. In 3.6.2, where we list the kinds of component, make these links, in particular link "attribute set" to its definitions. In the para currently labelled P3.82 that starts "Every component has a declaration in some stylesheet module", add a qualification to say that in the case of attribute sets, there is potentially a set of declarations rather than a single declaration. In the third bullet point below (P3.87), delete "attribute set" from the list of things that can be overridden. Instead add a fourth bullet point: "In the case of xsl:attribute-set declarations, several declarations sharing the same name combine to form a single component." In the definition of "declaring package", change "declaration" to "declaration (or, in the case of attribute sets, multiple declarations)"; and similarly in the first bullet explaining the properties of a component (P3.92). 4. In 3.6.2.2, first para, mention that for xsl:attribute-set all the declarations making up an attribute set must have the same value for the visibility attribute. 5. in 3.6.2.5 (overriding components), add: It is a consequence of rules defined elsewhere that two declarations within the same xsl:override element cannot be homonymous. Note that when an attribute set is overridden, the overriding declaration must consist of a single xsl:attribute-set element; attribute sets defined in different packages are never merged, unless this is done explicitly using the use-attribute-sets attribute. 6. In 19.3.5 Classifying attribute sets, change the list items to "1. Any xsl:attribute instruction contained in any of the xsl:attribute-set declarations making up the attribute set" "2. Any attribute set referenced by a use-attribute-sets attribute in any of the xsl:attribute-set declarations making up the attribute set"
The proposal was accepted and the changes have been applied.