This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The third item in the first bulleted list of section 2.2 of the XSLT 2.0 Recommendation states, "In all cases where this specification states that the value of an attribute must be one of a limited set of values, leading and trailing whitespace in the attribute value is ignored." It's not entirely clear what the phrase "limited set" was intended to mean. Does it mean "finite set" or does it mean something like "a proper subset of the possible values an attribute might have?" I am guessing that it was intended to mean the latter, and a clarification might be in order. With either definition though attributes whose values are specified to be a char are problematic. If the value specified in an input document is a single whitespace character, the rule I've quoted above requires leading and trailing whitespace to be ignored, which would result in a zero-length string. I would suggest something like the following rewording: "In all cases where this specification states that the value of an attribute MUST be anything other than <em>string</em> or <em>char</em>, leading and trailing whitespace in the attribute value is ignored."
Sorry. I forgot the XSLT prefix on the summary.
I agree this phrase is a little fuzzy. At one time I think it was intended to mean an enumerated set of values. It might be that we can define it by reference to the datatypes of the values, or to the pseudo-datatypes used in element proformas.
The WG reviewed the comment and agreed it was desirable to firm up the wording. I have reviewed all the element proformas, and I agree with the commenter that the only cases where we should keep leading and trailing whitespace are those where the stated type is string or char. Henry's proposed wording for this looks fine. There's one possible case where the old rule would (perhaps) trim whitespace and the new rule doesn't: the flags attribute of xsl:analyze-string. For simplicity I propose that we don't treat this specially. This means whitespace will not be allowed in this attribute, which is consistent with the rules for the $flags argument of functions such as matches().
On 22/3/2007 I took an action to propose text for an erratum. Proposed erratum: In the third item in the first bulleted list of section 2.2, change "In all cases where the syntax summary states that the value of an attribute must be one of a limited set of values, leading and trailing whitespace in the attribute value is ignored." to "Except where the set of allowed values of an attribute is specified using the italicized name <i>string</i> or <i>char</i>, leading and trailing whitespace in the attribute value is ignored."
The WG met on 17 April 2007 at the F2F at Red Hat and reviewed and accepted M. Kay's proposal. This completes erratum @2.