This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It's an error to specify visibility="abstract" on a template, function, variable, or attribute set unless the body of the component is empty. There's no similar rule when a component is declared as abstract on xsl:expose. Should there be? Or should the body just be ignored? (It's not so much an issue with xsl:accept because you can only accept something as abstract if it is already abstract in the used package.) A slightly orthogonal point: for xsl:template we say If the visibility attribute is present with the value abstract then (a) the sequence constructor defining the template body must be empty: that is, the only permitted children are xsl:context-item and xsl:param, and (b) there must be no match attribute. I wonder if (b) is too strict: should it say: "(b) there must be a name attribute". Visibility is only relevant to named templates, but if we allow the template to have both a name and a match pattern, I don't see why we shouldn't allow the visibility attribute to define its visibility when used as a named template, rather than requiring the visibility to be specified in a separate xsl:expose declaration.
While we're about it, there are a couple of places where the spec talks about a component having <code>visibility="abstract"</code> which ought to be generalized to allow the visibility of the component to be abstract by virtue of xsl:expose rather than by an explicit visibility attribute. Examples found in the definition of error [ERR XTSE3075], and in the second para of 3.5.3.6.
Also note, section 3.5.3.1 on xsl:expose says "The visibility of a component declared within a package is the first of the following that applies" but these rules only apply to function, variable, template, attribute-set, and mode declarations - not to other components such as accumulators, keys, and params. Specifically, the default for xsl:param is not private as these rules would indicate.
In discussion we felt that it would be useful to add a rule that xsl:expose can assign visibility="abstract" to a component only if the component is already declared with visibility="abstract".
Proposed changes: 1. In 3.5.3.1 Visibility of Components add the rule: If the *explicit exposed visibility* of a component is abstract, then the component must also have a *declared visibility* of abstract and add a static error condition. 2. In 3.5.3.1 Visibility of Components change "The visibility of a component declared within a package is the first of the following that applies" to "The visibility of a named template, function, variable, attribute set, or mode declared within a package is the first of the following that applies" (The other issues mentioned in the bug are minor and editorial.)
The proposed rule (1) above isn't quite sufficient, because it doesn't address what happens with wildcards, e.g. <xsl:expose component="variable" names="*" visibility="abstract"/> I think the rule should be re-stated (after the 5-item list) as: It is not possible to expose a component as abstract unless its declaration specifies visibility="abstract". It is therefore a static error if the result of the above matching rules is to cause an xsl:expose declaration with visibility="abstract" to match a component whose declaration does not have the attribute visibility="abstract".
Although I don't have any formal indication that the proposal was accepted, I recall the discussion being favourably inclined, so I have applied to the changes to the spec, and leave the bug open so the WG can review them
The change was reviewed and approved.