This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification is unclear what happens when a stylesheet contains two variable declarations with the same name, one static and one non-static, having different import precedence, and different values. There doesn't seem to be any error condition covering this. References in static expressions will use the static declaration. References in dynamic expressions will use the declaration that has highest import precedence. So the tricky case is when the dynamic declaration has higher import precedence. In this situation the dynamic value of the variable will differ from its static value. Is this actually a problem? For example, is it a problem if either or both of the variables is actually a parameter, or if they are declared with different types? I'm coming to the conclusion that it is permitted and have written test case static-027 to illustrate the effect.
I agree that the spec is unclear. But we have a few rules that (may) say what should happen here. 1) A static variable "is a" global variable, quote: "[Definition: A top-level variable-binding element having the attribute static="yes" declares a static variable: that is, a global variable whose value is known during static analysis of the stylesheet.]" 2) A global variable cannot appear duplicated on the same import precedence level: XTSE0630. 3) Appearance on different import precedence is fine You wrote: > So the tricky case is when the dynamic declaration has higher import > precedence. In this situation the dynamic value of the variable will > differ from its static value. I think this is correct. When the dynamic declaration has higher import precedence, it takes over. And: > For example, is it a problem if either or both of the variables is actually > a parameter, or if they are declared with different types? I think this is permitted, as long as they are not declared at the same import precedence. But we should also obey the other rules, which I think means (maybe I state the obvious here, but it is good to refresh my memory): * Same-named static vs dynamic variables cannot co-exist at the same import precedence * Same-named static variables can co-exist as long as their value and type are the same, regardless of import precedence, however, they may not have the same import precedence * Same-named static and dynamic variables can co-exist at different import precedence levels * It is therefore also possible to reference the same-named dynamic variable in a non-static expression prior to the appearance of the static variable in document order What I get from this: * Ergo 1: a same-named dynamic variable can *only ever* shadow a static variable if and only if it has higher precedence, it is ignored with lower precedence, or throw XTSE0630 for same precedence * Ergo 2: a same-named static variable will shadow a dynamic variable if and only if it has higher import precedence, it is ignored only in dynamic expressions when it has lower precedence, and same-precedence yields XTSE0630 You wrote: > I'm coming to the conclusion that it is permitted and have written test > case static-027 to illustrate the effect. I agree, I think this is permitted. I saw the test in the mail, I think it'd be good if we have the opposite situation as well: a static variable shadowing a dynamic global variable.