This test case contains circular definitions of two static parameters:

    <xsl:param name="circular" static="yes" select="$other" />
    <xsl:param name="other" static="yes" select="$circular" />

and claims that this is not an error when an external value is supplied for the parameter $circular.

I think this analysis is wrong.

(1) §9.6 says "The static context for evaluation of a static expression only contains those static variables visible within the containing package whose declarations occur prior to the element containing the static expression in stylesheet tree order."

So I think that select="$other" is a static error because it contains a reference to a variable that is not present in the static context.

(2) Even discounting that, an implementation is allowed to evaluate the initialising expression for a parameter whether or not the default value is actually needed.

I'm not sure that is correct and/or whether we say either way in the spec.

Under 9.7 I see the following about static parameters' dynamic context:

§9.7: A value for every variable present in the in-scope variables. For static parameters where an external value is supplied: the externally-supplied value of the parameter. In all other cases: the value of the variable as defined in 9.3 Values of Variables and Parameters.

To me, this at least suggests that the parameter's value is set *prior* to dynamic evaluation. Since the circularity check itself is a dynamic error, occurring in the dynamic phase, I think this means that it should be evaluated *after* the value is overridden with an externally supplied value.

I agree that dynamic errors may be raised statically if we can, but isn't that only true in cases where we can guarantee that the same result is always true? In this case, it depends on the actual value of the parameter, so static evaluation of the static expression prior to dynamic evaluation of the static expression seems to be incorrect.

If not, should we perhaps clarify this in the spec somehow?

I don't think the dynamic context is relevant. It says: "§9.7: A value for every variable present in the in-scope variables." But we've already established in §9.6 that a static variable whose declaration isn't present in the in-scope variables unless the declaration precedes the expression in question.

Yes, but the second part of the paragraph clarifies the meaning of "value":

> For static parameters where an external value is supplied: the externally-supplied value of the parameter

In this case, there is an externally supplied value for the parameter. Or am I missing something?

Reclassifying this as a spec-bug to have it appear on the agenda for the XSLWG.

§9.7 is about the dynamic context. The dynamic context is irrelevant when there's a static error present. I think §9.6 makes it clear that when a static expression contains a forwards reference to a variable, that reference is out of scope, and is therefore a static error. The fact that the expression is never evaluated doesn't alter the requirement to report static errors.

Aha, I see now where you are going: the circularity never comes into effect, because the static error (variable not in scope) comes first. And because setting a parameter's value and evaluating it is a dynamic-phase action, you'll never get that far.

That is to say: there's still the issue that we do not require evaluation of an expression when it is never used. But that's not true for static errors, so in this case it ends up being wrong, because overriding the parameter comes too late in the game.

How does that relate to:

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

which could also be a static error, but in this case we *do* allow the parameter to be set, I believe we call this an "implicitly required parameter"? Which begs the question: why allow/support this, but not the other?

>How does that relate to:

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

>which could also be a static error, but in this case we *do* allow the
>parameter to be set, I believe we call this an "implicitly required parameter"?
>Which begs the question: why allow/support this, but not the other?

I think the answer to that is (a) we don't do static typing so we can't expect processors to know statically that () is not an instance of xs:string, and (b) there's a lot of history that we would change if we could...

After discussion in the XSLWG, we decided to reclassify it as a test-bug, to be fixed by me, based on the discussion below.

I have fixed the test as agreed.