This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://www.w3.org/TR/xslt20/#initiating states: "Parameters passed to the transformation by the client application are matched against stylesheet parameters (see 9.5 Global Variables and Parameters), not against the template parameters declared within the initial template. All template parameters within the initial template to be executed will take their default values." I cannot think of any good reasons for this restriction. If we can choose an entry point then why cannot we provide parameters for it? Using globals as defaults isn't really a solution, since that would restrict the set of templates with parameters to choose from to one, the one whose parameters are duplicated as global parameters. This restriction helps to enforce that stylesheets have a single purpose, while they could have many purposes based on related functionality. Like object-oriented languages, you can call a class constructor passing parameters (global parameters in XSLT) and then call a method passing other parameters (initial template parameters). Removing this small restriction will expand the amount of functionality a stylesheet author can offer to client applications.
I'm fairly sympathetic to the requirement, provided that we don't make it a requirement that every invocation API must offer this capability. It would complicate the design of some APIs too much. (In fact, some invocation interfaces such as the <?xml-stylesheet?> PI don't allow parameters to be set at all - let alone a named initial template.) So the change would essentially be a permissive one - we allow APIs to allow the parameters to the initial template to be set. For completeness this would presumably apply to parameters declared on an initial match template matching the initial context item as well.
Great!
I agree on the "premissive" aspect. If we allowed the user to call directly a named template, passing parameters directly, then there wouldn't be any reason to not allow him/her to call directly a function also. So a stylesheet, in addition to a full transform definition, could then be also a library of components (named templates and functions) callable directly by the user.
Yes, it does reopen that possibility. There was debate about allowing direct calling of stylesheet functions during 2.0 development. It would be a rather radical change to the culture, because a stylesheet/transform then no longer necessarily produces a result tree, it can also be used for example to select nodes from the source document (which makes it a query, in effect). But at the same time, it's in other ways a rather trivial change: since the functions are there, why not allow them to be called? (Note that for direct calling of named templates we do ensure that any results of the template are wrapped in a result document. We could do the same if we allowed direct function calling. But I don't think that's what users would expect to happen.)
> If we allowed the user to call directly a named template, passing > parameters directly, then there wouldn't be any reason to not allow > him/her to call directly a function also. So a stylesheet, in addition > to a full transform definition, could then be also a library of components > (named templates and functions) callable directly by the user. Just for the record, I never asked for a 'direct call' or 'stylesheet as a library instead of executable' feature. Simply, since we are allowed to set the stating point of the execution we should be allowed to set it's parameters. The requirements are too different to be treated as the same.
Noted during discussion that's it's reasonably easy to work around this problem, e.g. by having default values for the template parameters that pick up the values of like-named globals, or by importing it into a front-end stylesheet module that sets up the parameters as appropriate. Noted during discussion that the following is rather strange: "This section, however, describes the information that is supplied when a transformation is initiated. Except where otherwise indicated, the information is REQUIRED." - Who is this constraining - the API designer? We need to allow for interfaces like the xml-stylesheet PI that can't supply all this information. There is a sentiment that providing this capability will complicate the API design more than is justified by the extra functionality provided. The WG decided to make no change. But thanks for the comment.