This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, it is not an error to write the unnamed mode declaration as follows: <xsl:mode visibility="public" /> However, the unnamed mode is always private to the containing package, so this declaration is in conflict with the semantics of the visibility attribute. I think it makes sense to disallow any other visibility than visibility="private" for the unnamed mode declaration, or conversely or in conjunction, we can define a static error when the visibility is not private.
I note also in 6.6.1 [Definition: All the xsl:mode declarations in a stylesheet that share the same name are grouped into a named mode definition; those that have no name are grouped into a single unnamed mode definition.] This should say "all the declarations in a package".
Note also, we say: A mode is not eligible to be used as the initial mode if its visibility is private. which seems a bit severe (and is not backwards compatible), since private is the default).
The WG discussed this during the ftf meeting in Prague. We accepted the proposal in the original bug report (without making a choice among the alternatives raised) and that in comment 1. We considered two ways of addressing the issue in comment 2: 1 we could say that everything is implicitly public in the top-level package. 2 we could say that when an xsl:stylesheet element is not wrapped in an xsl:package element, the implicit transformation which turns it into a package effectively wraps it in an xsl:package element with an xsl:expose names="*" for all relevant component types (templates, functions, modes). Of these, the first troubled some members of the WG because the difference between top-level and library packages is not lexically apparent; the second seemed to work fine (and to be compatible with stylesheets which have marked individual components as private). We agreed to adopt the second proposal.
1. Added the rule: If the mode is unnamed, that is, if the <code>name</code> attribute is absent, then the <code>visibility</code> attribute if present <rfc2119>must</rfc2119> have the value <code>private</code>. 2. In the definition of "mode definition", changed "all the xsl:mode declarations in a stylesheet" to "all the xsl:mode declarations in a package". 3. In the introductory section of 3.6, the transformation to create an implicit package is affected also by the resolution of bug #24438, which drops support for xsl:stylesheet/xsl:use-package. The text towards the end of the section becomes: A package that does not itself expose any components or use any library packages may be written using a simplified syntax: the xsl:package element is omitted, and the xsl:stylesheet or xsl:transform element is now the outermost element of the stylesheet module. For compatibility reasons, all the named templates and modes declared in the package are made public. More formally, the principal stylesheet module of the top-level package may be expressed as an xsl:stylesheet or xsl:transform element, which is equivalent to the package represented by the output of the following transformation, preserving the base URI of the source: <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 version="{@version}"> <t:expose component="mode" names="*" visibility="public"/> <t:expose component="template" names="*" visibility="public"/> <xsl:copy-of select="."/> </t:package> </xsl:template> </xsl:transform>