Interesting. I am not sure the current rules for tunnel parameters are 100% complete. The only case I could find related to existing/non-existing tunnel parameters is this:

"If a tunnel parameter is declared in an xsl:param element with the attribute tunnel="yes", then a dynamic error occurs [see ERR XTDE0700] if the set of tunnel parameters passed to the template does not include a parameter with a matching expanded QName."

And this seems at odds with our other statement:

"All other options of xsl:with-param and xsl:param are available with tunnel parameters just as with non-tunnel parameters. For example, parameters may be declared as mandatory or optional,...."

Since the first statement requires a parameter to be passed (same as required="yes") and the second statement allows you to specify required="yes" and required="no".

Suppose you have the following:

<xsl:template match="foo">
   <xsl:param tunnel="yes" select="12" name="count" />
</xsl:template>

This tunnel parameter has a default. But if the template is entered and there is no such tunnel parameter, we need to raise XTDE0700. If this is intentional, then having a default value is redundant. But I think this is not intentional.

But, if we change this:

<xsl:template match="foo">
   <!-- explicitly required -->
   <xsl:param tunnel="yes" name="foo" required="yes" />
   <!-- implicitly required -->
   <xsl:param tunnel="yes" name="bar" as="xs:integer" />
</xsl:template>

This suggests that *if* the template is hit, it is required, but it already was required per XTDE0700. So, conversely, this is redundant given the current reading of this error.

I may be misinterpreting this part of the spec, but I would assume that some tightening up may be needed.

Without this cleared up, it will be hard to give an informed decision on your point.

Abel: yes, the paragraph "If a tunnel parameter is declared in an xsl:param element with the attribute tunnel="yes", then a dynamic error occurs [see ERR XTDE0700] if the set of tunnel parameters passed to the template does not include a parameter with a matching expanded QName." is clearly incomplete: if you follow the link to XTDE0700 it is clear that the error only applies if the parameter is explicitly or implicitly required.

Max: yes, I agree, the constraints here could be relaxed. I think it's very unlikely that a processor would attempt to make any static inferences or optimizations based on the tunnel parameters declared in a named template, and therefore we could in principle remove all constraints about the compatibility of tunnel parameter declarations in an overriding template (whatever the value of the 'required' attribute).

In fact we've unintentionally eliminated what was probably the original use case for tunnel parameters, which is to override one template A by setting a tunnel parameter, and override another template B by using that tunnel parameter, without having to override all the other templates on the call stack from A to B.

> if you follow the link to XTDE0700 it is clear that the error only applies 
> if the parameter is explicitly or implicitly required.
Mea culpa, I thought I was quoting the error itself...

I have modified the paragraph cited by Abel in comment #1 to make it clear that the error applies only where a parameter is explicitly or implicitly mandatory.

The original observation from Max pointing out that the "compatibility" rules for template overriding should be relaxed remains for WG attention. My recommendation is that in 3.5.3.3, in the section dealing with named templates, we should change the rule:

Two named templates with the same name are compatible if and only if they satisfy all the following rules:...

(2) For every parameter on the overridden template, there is a parameter on the overriding template that has the same name, an identical required type, and the same effective values for the tunnel and required attributes.

to read:

(2) For every non-tunnel parameter on the overridden template, there is a non-tunnel parameter on the overriding template that has the same name, an identical required type, and the same effective values for the required attribute.

plus a Note:

Note: tunnel parameters can vary between the overriding template and the overridden template; in particular (a) the overriding template can omit the declaration of a tunnel parameter whose value is not needed, and (b) the overriding template can add tunnel parameters that were not present in the original if these are needed to parameterize the behavior of the overriding template.

The proposal was accepted with an amendment: if a tunnel parameter is present on both the overriding and overridden template, then it must have the same type in both.

The changes have been applied.