This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For both xsl:sort and xsl:number we make two statements about the lang attribute: (a) we give the format in the syntax template as lang? = { nmtoken } (b) we say that the range of permitted values is the same as for xml:lang, with a reference to the XML specification These are inconsistent: the xml:lang attribute allows a zero-length string, whereas nmtoken does not. Also, the reference to xml:lang could be taken as implying that the language must be present in the various lists of registered languages, rather than merely conforming to the correct syntax. I would suggest that (i) we change the syntax template to lang? = { xs:language? } (ii) rather than referring to xml:lang, we say that the value must either be a zero-length string or a string in the value space of xs:language. This makes it clear that the constraint is purely syntactic. (iii) we specify that the zero length string has the same effect as omitting the lang attribute.
was marked resolved by mistake when I was closing another bug and system moved to this one without me noticing.
At the regular XSLT WG telcon on 20 May 2010 the group agreed to accept the proposal from Mike Kay as suggested in the Description of the bug. The bug will be closed when the errata is drafted and approved as part of the normal errata review process.
I am reopening this to include an issue raised by bug #788 raised a long while ago against the test suite, and never resolved. What should xsl:sort do if lang is present and specifies a language that is not supported by the implementation? Should it raise an error, or should it fall back (e.g. to English language, or to codepoint collation)? Note that for xsl:number we say "If a language is requested that is not supported, the processor uses the language that it would use if the lang attribute were omitted."
>What should xsl:sort do if lang is present and specifies a language that is not supported by the implementation? Recommend: (a) strip off trailing parts of the lang until you find something that's supported, (b) if that still doesn't work, give an error. But note that implementations are free to recognize any languages they choose to. Both halves of this issue will be resolved in erratum E54.
Note that the solution actually adopted in erratum E54 (not published, but incorporated into XSLT 3.0) was that an invalid value for @lang should be handled as if no value for @lang was requested, that is, use a default language rather than raise an error.