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 opening of 9.2 Parameters does not list it as allowed for xsl:package or xsl:transform. We seem to have two conflicting statements with regards to the tunnel attribute. In 9.2 Parameters, we say: A) As a child of xsl:stylesheet, to define a parameter to the transformation. In this case all attributes except tunnel are permitted. Stylesheet parameters are set by the calling application: see 2.3.2 Priming a Stylesheet. And at the bottom of that same chapter (just before 9.2.1): B) The optional tunnel attribute may be used to indicate that a parameter is a tunnel parameter. The default is no; the value yes may be specified only for template parameters. Tunnel parameters are described in 10.1.3 Tunnel Parameters And in 9.10 we say (2nd last para): C) The optional tunnel attribute may be used to indicate that a parameter is a tunnel parameter. The default is no. Tunnel parameters are described in 10.1.3 Tunnel Parameters. They are used only when passing parameters to templates: for an xsl:with-param element that is a child of xsl:evaluate or xsl:next-iteration the tunnel attribute must either be omitted or take the value no. So, in (A) we say it is _not permitted_, in (B) we say it is permitted but takes a value of no outside xsl:template, in (C) we say for xsl:with-param that it may take a value of no only for xsl:evaluate and xsl:next-iteration. I propose to align these statements and keep it simple, similar to the select attribute in xsl:function, just disallow it except inside xsl:template. Since xsl:param has so many different guises, this is what we came up with: xsl:param in tunnel static select required ---------------------- ------------ ------------ ------------ ------------- xsl:stylesheet etc disallowed allowed allowed allowed xsl:package disallowed allowed allowed allowed xsl:template allowed disallowed allowed allowed xsl:function disallowed disallowed disallowed disallowed xsl:iterate disallowed disallowed mandatory disallowed xsl:with-param in ---------------------- ------------ xsl:apply-templates allowed xsl:call-template allowed xsl:next-iteration disallowed* xsl:evaluate disallowed* * currently allowed only with the value no, I propose to disallow it similar to the rules of xsl:param, to avoid confusion Error summary: XTSE0010 If a name is missing, or under xsl:iterate, if select is missing XTSE0020 If any of the values are wrong XTSE0090 If an attribute that is disallowed in the table above is used
The inconsistency between "required" and "tunnel" exists already in the XSLT 2.0 specification. For xsl:param/@tunnel (end of 9.2) 2.0 says: The optional tunnel attribute may be used to indicate that a parameter is a tunnel parameter. The default is no; the value yes may be specified only for template parameters. For xsl:param/@required (earlier in the same section) 2.0 says: The optional required attribute may be used to indicate that a parameter is mandatory. This attribute may be specified for stylesheet parameters and for template parameters; it must not be specified for function parameters, which are always mandatory. I'm disinclined to introduce a backwards incompatibility here just in the interests of tidying this up. I'm more inclined to go the other way, by allowing the values tunnel="no", required="yes", or static="no" in all cases where the attribute is currently disallowed. Having a table to present the options seems an excellent idea.
You seem to be suggesting something like the following: xsl:param in tunnel static select required ---------------------- ------------ ------------ ------------ ------------- xsl:stylesheet etc no yes|no allowed yes|no xsl:package no yes|no allowed yes|no xsl:template yes|no no allowed yes|no xsl:function no no *** 1) yes xsl:iterate no no *** 2) yes To bring all in line and make it orthogonal, what should we do with the select-attribute? For xsl:function it is currently disallowed, for xsl:iterate it is mandatory. For xsl:iterate it may be reasonable to have a default value of ".". For xsl:function we could simply ignore it if present (and a processor can issue a warning). It could also be used on xsl:function to specify default values for overloads with missing arguments, but I believe that ship has already sailed ;).
The proposal in comment #1 was accepted.
The changes have been applied.