This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This also affects XSLT 2.0 The working draft specifies this: ERR XTSE0680 In the case of xsl:call-template, it is a static error to pass a non-tunnel parameter named x to a template that does not have a template parameter named x, unless the xsl:call-template instruction is processed with XSLT 1.0 behavior. The upshot of this is that it is an error to pass a non-tunnel parameter to a template which doesn't declare this non-tunnel parameter UNLESS it happens to declare a tunnel parameter with the same name (in which case the parameter passed is silently ignored. This interpretation of the spec is confirmed by the test tunnelparam20_015_01. Was it really the intention of the working group that the error should be ignored in this case or is it an oversight? I cannot see how this behaviour is at all beneficial, and can only lead to confusion. I suggest that the wording should be changed to: ERR XTSE0680 In the case of xsl:call-template, it is a static error to pass a non-tunnel parameter named x to a template that does not have a non-tunnel template parameter named x, unless the xsl:call-template instruction is processed with XSLT 1.0 behavior.
My own feeling is that your proposed rewording is what was intended, and is the only reading that makes sense. However, the presence of test case tunnelparam20_015_01 means that changing the wording is not necessarily the right thing to do. At the meeting today, the WG asked for implementor (or user) feedback as to how existing products handle this situation.
I have run this test case in the Intel XSLT 2.0 processor. It produces the expected result in the test suite.
IBM's processor reports this error: "IXJXE0781E: [ERR 0700][ERR XTSE0680] It is a static error to pass a parameter that is not a tunnel parameter 'par1' to a template that does not have a template parameter that has the same expanded QName." A bit of history: while our processor was under development, it did produce the output that this test case expected - perhaps not surprising, given that the author of the test case also did the initial implementation of tunnel parameters in our processor. At some point later in development, we reread the definition of error XTSE0680 and decided the test case did not reflect the intention of the specification, and changed our implementation to report the error.
For reference, our implementation (XQSharp) currently passes this test case, but we would love to change this behaviour whilst we are still in beta (hence the bug report!)
Saxon is currently returning the "expected" (published) results for this test case, but I think nevertheless that this is not the intention of the spec. It's a one-line patch to change it (*); if I do so, Saxon "fails" the tests tunnelparam015, 016, 017, 020, and 028. Whoever wrote these test cases was pretty thorough! Michael Kay [(*) for my own reference, XSLCallTemplate line 191]
Accepted the clarification to the spec; the tests need to be updated accordingly.
The minutes of the Prague (March 2011) F2F record: We discussed; MK suggested accepting the change in wording as a useful clarification and changing the test cases to match. RESOLVED: accept wording, tests to be changed. ACTION: HZ to handle revision of test cases. ACTION: MK to handle revision of error code description. I have now applied the change to the XSLT 3.0 draft; but the bug remains open as it is an XSLT 2.0 issue.
Revert apparent vandalism (status change).