This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Whether the attributes "required" and "tunnel" are disallowed on xsl:function, and what do if present, I find a bit vague: * Tunnels are from my understanding not in anyway related to xsl:functions. But I don't find anything, not in "9.2 Parameters" or "10.3 Stylesheet Functions", that state xsl:function/xsl:param/@tunnel is disallowed or what error code to raise. * 9.2 Parameters states: "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." but it isn't stated what error code to raise. This can be contrasted with for instance XTSE0760.
Personal response. >I don't find anything, not in "9.2 Parameters" or "10.3 Stylesheet Functions", that state xsl:function/xsl:param/@tunnel is disallowed or what error code to raise. The last para of 9.2 states: "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." This implies that the value tunnel="no" is legal for a function parameter. If tunnel="yes" is specified, I would suggest raising XTSE0020: "an attribute ... contains a value that is not one of the permitted values for that attribute." >"The optional required attribute may be used to indicate that a parameter is mandatory. This attribute ... must not be specified for function parameters, which are always mandatory." but it isn't stated what error code to raise. I would suggest XTSE0010: "the content of [an] element does not correspond to the content that is allowed for the element." I don't dispute that it seems inconsistent to allow tunnel="no" while not allowing required="yes", nor that we are inconsistent about when we define specific error messages for a condition and when we fall back to general purpose error codes. But I don't think such inconsistencies can be classed as bugs in the spec.
Sounds sensible. This is too insignificant. I'm rejecting.