28525 2015-04-21 11:35:47 +0000 [XSLT30] (editorial) Allowed/disallowed attributes of xsl:param 2015-05-01 11:20:15 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 minor --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 119721 0 abel.braaksma 2015-04-21 11:35:47 +0000 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 120004 1 mike 2015-04-30 08:19:10 +0000 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. 120014 2 abel.braaksma 2015-04-30 14:33:55 +0000 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 ;). 120028 3 mike 2015-05-01 10:41:17 +0000 The proposal in comment #1 was accepted. 120029 4 mike 2015-05-01 11:20:15 +0000 The changes have been applied.