This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We say: [ERR XTDE0040] It is a dynamic error if the invocation of the stylesheet specifies a template name that does not match the expanded QName of a named template defined in the stylesheet, whose visibility is public or final. But we have several examples in the spec of templates named xsl:initial-template, that are clearly intended to represent an entry point for stylesheet invocation, with no visibility attribute: as far as I can see, a template named xsl:initial-template with no visibility attribute is private, and is therefore not a permitted entry point. We also have numerous tests that assume invocation at a named template is possible without declaring it public. In addition, invocation of a stylesheet at a named template was permitted in XSLT 2.0, and such stylesheets do not have a visibility attribute. This rule would therefore appear to prevent an XSLT 3.0 processor executing a working 2.0 stylesheet. The problem does not apply to modes; XTDE0045 has an escape clause that preserves compatibility (A mode is an eligible mode if (5) The effective value of the declared-modes attribute of the explicit or implicit xsl:package element of P is no, and M appears as a mode-name in the mode attribute of a template rule declared within P.) NOTE: Saxon enforces the rule requiring an initial function to be declared public, but does not enforce this for an initial template (which is why it passes the tests).
A possible fix is to say that if the top-level package is rooted at an xsl:stylesheet or xsl:transform element (as distinct from xsl:package), then all named template rules in the top-level package, if they have no explicit visibility attribute, assume visibility="final".
I'm not sure there's a problem here. See section 3.5 on packages. There we explain how an _implicit package_ is transformed into a package: <xsl:transform version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:t="http://www.w3.org/1999/XSL/TransformAlias"> <xsl:namespace-alias stylesheet-prefix="t" result-prefix="xsl"/> <xsl:template match="xsl:stylesheet|xsl:transform"> <t:package declared-modes="no"> <xsl:copy-of select="@*"/> <t:expose component="mode" names="*" visibility="public"/> <t:expose component="template" names="*" visibility="public"/> <xsl:copy-of select="node()"/> </t:package> </xsl:template> </xsl:transform> This transformation shows clearly that all names templates and named modes become public. Functions do not (but that's ok, since functions where not an invocation point). I think your processor behaves correctly by accepting named templates without a visibility attribute. Note that the body of the text of 2.3.4 does not mention that it must be public (the error in that section does, though). And we say: "The effect is analogous to the effect of executing an xsl:call-template instruction." This is at odds with the error, as call-templates can call private templates within its scope. Still, I think it make sense that private templates should not be available for invocation (why otherwise make it private in the top-level package?). Note also that in 10.1 Named Templates we say: "The template name xsl:initial-template is specially recognized in that it provides a default entry point for stylesheet execution" If we could change it, I think xsl:initial-template, as with int main() in C++ or public static main in Java (https://stackoverflow.com/q/20776413/111575) should ignore its visibility: * If we allow it final, and the package is used as library, you'd have a problem to override it with your own entry point * If we allow it to be private, we will have the current discussion, though you could argue that if it's also used as library package, it will then automatically be hidden * If we allow it to be abstract, you will only ever receive an error * If we allow it to be public, it will determine the entry point even if it is in a library package, which may surprise users (but I don't think we can escape this). Hence, it should only ever be public, just like in Java, or we interpret the above lines in the spec literal and ignore that XTDE0040 forgot to mention an exception for xsl:initial-template. BTW: all examples in the spec using xsl:initial-template have a top-level element of xsl:stylesheet and are therefore implicitly public.
Thanks for the pointer to 3.5. You're right, that solves the problem. I have drafted erratum E8 which adds an explanatory Note in case anyone else stumbles over the same problem.
I thought you mentioned that you wanted to point the Note to section 3.5. That is missing in the proposed E8 erratum.
The minutes record that the erratum was accepted, but I have amended it to add the cross-reference to section 3.5 as suggested in comment #4.
The proposed erratum E8 has been reviewed and later amended (latest change 13 Feb 2019), HTML version: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E8 I would like to suggest in light of this change to amend the current Note to also reflect the same rule for initial named modes.