Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[xslt30] Visibility of xsl:param #5

Open
michaelhkay opened this issue Oct 24, 2019 · 0 comments
Open

[xslt30] Visibility of xsl:param #5

michaelhkay opened this issue Oct 24, 2019 · 0 comments

Comments

@michaelhkay
Copy link
Contributor

michaelhkay commented Oct 24, 2019

The XSLT 3.0 spec makes confusingly inconsistent statements about the visibility of global parameters.

The grammar for xsl:param does not allow a visibility attribute.

In §3.5.3.1, under xsl:expose, we say "The visibility of a variable declared using an xsl:param element is always public."

§9.6 (Static parameters) says: "When the static attribute [of xsl:param] is present with the value yes, the visibility attribute must not have a value other than private." But in fact, no visibility attribute is allowed by the grammar. It is clear in this section that the intent is for static parameters to always be private: there is a note explaining why (specifically, so they cannot be overridden, which is necessary to allow separate compilation of packages); however, I don't see why visibility="final" can't be allowed, which would achieve the same aim.

I think one aspect of this that the spec fails to address is: when package P "uses" package Q, it is presumably using a version of Q whose static parameters have been bound to particular values. But there is no way for P to say what these values should be. There can be two compiled instances of Q with different values bound to the static parameters, and the effect of using these two instances is likely to be quite different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant