This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28525 - [XSLT30] (editorial) Allowed/disallowed attributes of xsl:param
Summary: [XSLT30] (editorial) Allowed/disallowed attributes of xsl:param
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-21 11:35 UTC by Abel Braaksma
Modified: 2015-05-01 11:20 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2015-04-21 11:35:47 UTC
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
Comment 1 Michael Kay 2015-04-30 08:19:10 UTC
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.
Comment 2 Abel Braaksma 2015-04-30 14:33:55 UTC
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 ;).
Comment 3 Michael Kay 2015-05-01 10:41:17 UTC
The proposal in comment #1 was accepted.
Comment 4 Michael Kay 2015-05-01 11:20:15 UTC
The changes have been applied.