Exposed visibility of xsl:param
s9apitests/TestPackage/testPackageRenamingExported is failing with an error saying it cannot accept xsl:param elements with private visibility as hidden.
The spec says (a) that xsl:param elements are always public, and (b) that their visibility cannot be changed by
What this test is trying to do is to compile a single package three times with different settings of a static parameter, and then import all three exported packages into a single top-level package (using package aliases to achieve this). It might be that we won't be able to get this to work, but we need to investigate why it's failing the way that it is. The spec says that xsl:param is public, but we're reporting it as private.
#1 Updated by Michael Kay over 2 years ago
There's an inconsistency in the spec here.
§126.96.36.199 () says: (a) In the case of an
xsl:param element there is no explicit visibility attribute; rather the declaration has the implicit attribute
visibility="public". (b) The visibility of a variable declared using an xsl:param element is always public. No xsl:expose element ever matches an xsl:param component.
§9.6 (Static parameters) says: When the
static attribute [of xsl:param] is present with the value
visibility attribute must not have a value other than
xsl:param does not allow a
As far as I can see this hasn't been picked up in any existing bug report on the spec.
#2 Updated by Michael Kay over 2 years ago
Saxon is giving static
xsl:param components a visibility of PRIVATE, and non-static
xsl:param components a visibility of PUBLIC, which seems a reasonable interpretation of the spec.
I don't think we're doing anything to stop
xsl:accept changing this.
#3 Updated by Michael Kay over 2 years ago
As regards the JUnit tests, if I change pack-120-top.xsl to remove the xsl:accept declarations, I now get "duplicate variable opname" - but if the variable is private in both used packages, this should not happen. In other words, we get different results depending on whether the used packages are exported (saved as SEF files) or not.
Please register to edit this issue