This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
That error had the following description: [ERR XTDE0610] If an optional parameter has no select attribute and has an empty sequence constructor, and if there is an as attribute, then the default value of the parameter is an empty sequence. If the empty sequence is not a valid instance of the required type defined in the as attribute, then the parameter is treated as a required parameter, which means that it is a dynamic error if the caller supplies no value for the parameter. It disappeared between the public WD from 12-12-2013 and 10-02-2014. It seems to have been the result of rearranging the 9.2 section as part of the resolution of bug 25158, but I couldn't find this as a decision in either the minutes or in that bug entry. I think the error still makes sense, if not only for the fact that the error was present in XSLT 2.0 as well. If we decide to (or have decided to) remove it, we should probably explain what error has come in its place. Please note that there are also still several tests around expecting this error as an outcome, like error-610a and error-610b.
I think the error got merged with XTDE0700. That is, we now use the same error code for failure to supply parameters that are "explicitly mandatory" and those that are "implicitly mandatory". I forget the exact rationale for the change, I think it was because of a desire to simplify in the face of an increasing number of combinations of options. For the implementation, it means that it is possible to mark a parameter as mandatory, without retaining any information in the run-time about whether it was explicitly or implicitly mandatory. I suggest we convert the tests to expect XTDE0700.
Note also, bug #24539 and bug #24864 introduced changes in the error handling in this general area, though neither explicitly proposed dropping XTDE0610. Indeed, what bug #25158 suggested was: ** in general it is a dynamic error if a parameter is explicitly or implicitly required and no value is supplied by the caller ([XTDE0700] or [XTDE0610] depending on whether it is explicitly or implicitly required) but I obviously decided at some stage that the distinction between these two codes had no value.
I think this makes sense, the distinction in explicitly and implicitly mandatory parameters in errors seemed a bit redundant. It does mean, of course, that some tests need to be split into a 2.0 and 3.0 version, reported in bug 28429.
While going over fixing our implementation, we found that perhaps still some editorial work is left. XTDE0050: this is about stylesheet parameters that have required="yes". I think this should probably have s/stylesheet/package/, and in addition, I would argue it could be merged into XTDE0700 as well, for the same rationale as in comment 1. XTDE0700: this error talks about templates, but seems to apply both to package, stylesheet and template parameters (iterate and function have their own error). Note, we now have: - XTDE0700 for implicitly mandatory package params - XTDE0700 for implicitly mandatory template params - XTDE0700 for implicitly mandatory static params - XTDE0050 for explicitly mandatory package params - XTDE0700 for explicitly mandatory template params - XTDE0050 for explicitly mandatory static params If we want to distinguish by error code between package and template parameters, I would suggest we use XTDE0050 for package params (both static and non-static, implicitly and explicitly mandatory) and XTDE0700 for template params (implicitly and explicitly mandatory).
Comment #4 talks about "package params" but this is not a term used in the spec. The spec calls then "stylesheet parameters" and they may be either static or non-static. As far as I can see, error XTDE0050 always relates to stylesheet parameters, and error XTDE0700 always relates to template parameters. Comment #4 lists XTDE0050 for explicitly mandatory package params but I can't find anything in the spec that suggests this. What I see in 9.5 is: It is an error if no value is supplied for a mandatory stylesheet parameter [see ERR XTDE0050]. and it would probably useful to say that this includes both "explicitly mandatory" and "implicitly mandatory", with better cross-referencing between section 9.5 and sction 9.2.2.
I agree that we currently do not have a way to distinguish between stylesheet-level (meaning: stylesheet-module-level) and package-level parameters. In fact, a stylesheet parameter is defined as: [Definition: A top-level xsl:param element declares a stylesheet parameter. A stylesheet parameter is a global variable with the additional property that its value can be supplied by the caller when a transformation is initiated.] As described in 9.2 Parameters, a stylesheet parameter may be declared as being mandatory, or may have a default value specified for use when no value is supplied by the caller. The mechanism by which the caller supplies a value for a stylesheet parameter is implementation-defined. An XSLT processor must provide such a mechanism. In another bug, it is already being rectified that "top-level" should also apply to children of xsl:package. There is currently no way in the specification to distinguish between same-named package-level and stylesheet-level parameters by the invoker of the stylesheet, but such a mechanism would be implementation defined anyway. My suggestion in comment#4 was to change the wording "stylesheet parameter" to "package parameter", because we now have implicit and explicit packages, and not stylesheets per se anymore, but that was my bad, I noticed now: [Definition: A stylesheet consists of one or more packages: specifically, one top-level package and zero or more library packages.] [Definition: A package consists of one or more stylesheet modules, each one forming all or part of an XML document.] Which effectively invalidates my argument to replace the term "stylesheet parameter" with "package parameter", as here a stylesheet is defined of one or more packages, and not the other way around. ----------------- Looking again at the definitions of the errors here: 1a) [ERR XTDE0050] It is a dynamic error if a stylesheet declares a visible stylesheet parameter with required="yes" and no value for this parameter is supplied when the stylesheet is primed.[...]. 1b) It is an error if no value is supplied for a mandatory stylesheet parameter [see ERR XTDE0050]. 2a) It is a dynamic error [see ERR XTDE0700] if the template rule selected for processing any item in the initial match selection defines a template parameter that specifies required="yes" and no value is supplied for that parameter. 2b) It is a dynamic error [see ERR XTDE0700] if the initial named template, or any of the template rules invoked to process items in the initial match selection, defines a template parameter that specifies required="yes" and no value is supplied for that parameter. 2c) [ERR XTDE0700] It is a dynamic error if a template that has an explicitly mandatory or implicitly mandatory parameter is invoked without supplying a value for that parameter. 2d) In other cases it is a dynamic error if the template that is invoked declares a template parameter with required="yes" and no value for this parameter is supplied by the calling instruction. [see ERR XTDE0700] 2e) 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. While this looks like a plethora of definitions for XTDE0700 (2a - 2e), I believe they indeed cover what Michael Kay is writing in comment#5: all cases where it can be a dynamic error and an (implicitly) required template parameter is missing, raised XTDE0700. MKay wrote: > and it would probably useful to say that this includes both "explicitly > mandatory" and "implicitly mandatory", with better cross-referencing > between section 9.5 and sction 9.2.2. The descriptions between 1a and 1b seem to augment each other, but I'd agree here, it'd be better to bring them in line. ------------- Concluding: my 2p: the only thing that warrants some editorial fixing is the XTDE0050 error, the XTDE0700 error(s) cover all their respective cases and the package vs stylesheet parameter distinction is of no consequence. As an aside: we might consider including the term "static or non-static" explicitly in the definition of stylesheet parameters.
We agreed to agree: all we need to do is a slight clarification to the description of XTDE0050 to make clear it includes "implicitly mandatory" stylesheet parameters
The change has been applied.