Actually, the rule is already there in 9.5:

If a stylesheet parameter specifies required="yes" and does not specify static="yes", then its visibility must be public, final, or abstract. The default visibility of such a parameter is public.

This is in conflict with the paragraph under 3.6.3.2 Visibility of Declarations (was this the para your original description referred to?):

<quote>
The xsl:function, xsl:template, xsl:attribute-set, xsl:variable, xsl:param, and xsl:mode declarations each have an optional visibility attribute that determines the potential visibility of the component corresponding to this declaration in its declaring package. The value is one of private, public, abstract, final (never hidden), with the default being private. In the case of xsl:attribute-set, all the declarations for an attribute set must have the same value for the visibility attribute. In the case of xsl:key, the visibility cannot be explicitly specified: it is always private.
</quote>

Also note, that in this paragraph we do not mention an xsl:accumulator, which is allowed a visibility attribute, and we do not mention xsl:decimal-format, which is a declaration and has, similar to xsl:key, always private visibility. In fact, this is specified under 3.6.5, alongside with other always-private declarations, perhaps mentioning xsl:key here is redundant?

Back to xsl:param: under 9.5, I don't see any part disallowing "private" as a value for the visibility attribute, except if the param has the required attribute set. This goes wrong for:

<xsl:param name="foo" as="xs:string" />

Which is implicitly required, now has default private visibility, and can never be specified by a using package.

Trying to figure out the visibility rules for the different types of params and variables left me puzzled:

- the default for any declaration is private
- a required param must be non-private, defaults to private and/or public
  (i.e., as Michael describes above)
- a static param must be final or private
- an implicitly required param should be non-private
- unclear about scope of final static params (see Note in 9.6)
- an explicitly required static param defaults to private, but must be non-private (by deduction)

Other than for precompilation, I do not see how params (not variables) should ever be private. Maybe we should be bold and even remove the visibility attribute, and give an implicit default of public, and private for statics?

And not just visibility defaults of params:

- an xsl:initial-template kinda implies public, doesn't it?
- and any xsl:package/@default-mode, because that is the mode initially called by the processor, should point to a public mode (or not?).

Further on, I found this, which seems to be contrary to the quoted paragraph above. Oughtn't an implicit mode be very, very private by default instead?

<quote>
Similarly, if there is a mode that is named in an xsl:template or xsl:apply-templates element, or in the [xsl:]default-mode attribute of a containing element, and the stylesheet does not contain a declaration of that mode, then a declaration is implied comprising an xsl:mode element with a name attribute equal to that mode name, plus the attribute visibility="public".
</quote>

The WG resolved today to drop the @visibility attribute from xsl:param. The effective visibility will always be private if the param is static, or public otherwise. If there is a wish to expose static params to another package, it is possible to bind a variable to the value of the parameter and export that variable.

Of the other points in comment 2 the WG decided as follows:

>Also note, that in this paragraph we do not mention an xsl:accumulator, which is allowed a visibility attribute, and we do not mention xsl:decimal-format...

These (editorial) omissions were noted and should be fixed.

>- an xsl:initial-template kinda implies public, doesn't it?

In the interests of orthogonality we felt users should declare visibility="public" explicitly. The spec needs to point this out.

>- and any xsl:package/@default-mode, because that is the mode initially called by the processor, should point to a public mode (or not?).

There are use cases for a default mode to be private, so no change.

>Further on, I found this, which seems to be contrary to the quoted paragraph above. Oughtn't an implicit mode be very, very private by default instead?

Yes, this is an error.

The changes have been applied to the spec.