29088 2015-08-27 08:38:25 +0000 [xslt 3.0] visibility="abstract" on xsl:expose 2015-10-29 12:42:26 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC All CLOSED FIXED P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 122787 0 mike 2015-08-27 08:38:25 +0000 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. 122788 1 mike 2015-08-27 08:48:45 +0000 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. 122790 2 mike 2015-08-27 10:23:45 +0000 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. 123062 3 mike 2015-09-03 17:23:20 +0000 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". 123068 4 mike 2015-09-03 22:45:07 +0000 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.) 123078 5 mike 2015-09-04 11:42:54 +0000 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". 123195 6 mike 2015-09-14 15:13:21 +0000 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 123628 7 mike 2015-10-09 11:18:05 +0000 The change was reviewed and approved.