[Bug 29763] [XSLT30] overriding xsl:param with xsl:variabe or vice versa should be disallowed

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29763

--- Comment #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> I'll chew a bit more on this.
I did the chewing :). 

We agreed that an xsl:variable can be overridden by an xsl:param and vv,
provided the correct visibility and homonimity are present.

This seems to be supported by the specification by absence of a rule that the
overriding declaration of xsl:param or xsl:variable must have a matching
overriding declaration (instead, we speak of "global variables" in the general
sense). This could be made explicit, but I don't think there's an error here.

Max Toro's comment in Bug 29574 refers to an (apparent) ambiguity in the spec:
under 3.5.3.2. we explain that if you use a package with xsl:use-package, and
there is *no* matching declaration inside xsl:override or xsl:accept, the
default visibility of a public component becomes *private*.

In the case of xsl:param this is not possible, as it is implicitly public and
it has no visibility attribute. To fix this, I propose to add a row in the
table under 3.5.3.2 that there's an exception for xsl:param: the default
visibility does *not* change from public to private, instead, it remains
public.

This makes sense, because a global parameter is never private.

Under 3.5.3.3 we added this exception already ("except in the case of
xsl:param, which is implicitly public.").

Instead of adding a Note as suggested by Max Toro, I think a normative entry in
the table (under 3.5.3.2) for the xsl:param exception makes more sense.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 24 August 2016 09:30:27 UTC