This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There are a number of places where the value space of an XSLT attribute is defined by reference to XPath constructs such as ItemType, SequenceType, IntegerLiteral, NCName, or EQName. We make it fairly clear that whitespace is generally allowed around such values, but we say nothing about comments. Can I write <xsl:function name="f:goForIt (:quickly:)"> It's pretty clear that comments are allowed in multi-token constructs - expressions and patterns - and that surely must include ItemType and SequenceType unless we say anything to the contrary - but for EQName it seems much less clear. Incidentally, for package-version I think the rules are ambiguous about whitespace (as well as comments). We say Here IntegerLiteralXP30 and NCName are as defined in the XPath 3.0 grammar productions of the same name (including rules on limits). Leading and trailing whitespace is ignored; no other whitespace is allowed. That doesn't make it clear whether leading and trailing whitespace is allowed around each IntegerLiteral/NCName, or only at the start and end of the PackageVersion as a whole (the latter is intended).
I propose that in 2.2 we add the rule: Here and throughout this specification, when productions from the XPath grammar are referenced (examples are Expr, SequenceType, ItemType, NameTest, IntegerLiteral) then: * comments (written "(: ... :)") and whitespace are allowed before, after, or within multi-token constructs such as Expression, SequenceType, and ItemType. * comments are not permitted before or after constructs that disallow internal whitespace or comments, such as EQName, NameTest or IntegerLiteral; whitespace is permitted before or after such constructs only when there is an explicit statement to that effect.
We discussed this today. There was support for a view that said we should be very liberal about accepting comments anywhere that it made sense, rather than requiring users to remember which attributes allowed comments and which did not. The downside is that where we define an attribute using XSD data types, we don't want to allow things that XSD doesn't allow (or allow us to define), because some people are likely to use the schema-for-XSLT to help with syntax-directed editing. I was given an action to propose a way forward. Reviewing the list of attribute types in 2.2, I think we should allow XPath-style comments anywhere that whitespace is allowed in attributes of types: expression pattern item-type sequence-type and of course within expressions in value templates We should not allow comments in attributes of other types (boolean, string, uri, uris, qname, eqname, eqnames, token, tokens, nmtoken, nmtokens, char, integer, decimal, ncname, prefix, id) because this would interfere with our ability to validate the attributes using XSD.
The change was accepted and has been applied. A few existing tests have been modified to include comments in item-type and sequence-type attributes.