[Bug 29981] required="no" on additional tunnel parameters of overriding template


Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
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" />

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" />

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

You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 6 November 2016 07:53:20 UTC