This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(Opportunistic desideratum) (1) We need a canonical form for the language datatype. Both upper and lower case variants are permitted by our type, but the relevant RFC says they should be treated the same. If we don't provide for case mapping, we should at least have a health warning. Further consideration shows other problems that need solution: (2) Which RFC should be referred to? (3) Should all the provisions of the RFC be enforced? None? Some? (4) What should happen when the RFC is replaced by a newer one on the same topic? Should XML Schema processors be automatically rendered non-conforming if they don't support it? Should they be automatically non-conforming if they do support the new RFC? Should implementors have a choice? Users?
The WG discussed this topic in our face to face meeting yesterday afternoon and this morning, with the following results: we agreed - to make a regex equivalent to that in RFC 3066 the normative definition of the lexical space (and thus of the value space, since they are 1:1) for language - NOT to include RFC 3066's rules about ISO / IANA registration as part of schema validity for this type - to make our reference to 3066 informative, not normative - to make our reference to 3066 and its successors (not a rigid reference to 3066 alone) - to note explicitly that the other rules of 3066 (other than the regex) do not constrain schema-validity, but NOT actively to encourage schema processors to check them The editors will revise the proposal and get it back to the WG.
A proposal revising the presentation of language in XML Schema 1.1 was adopted by the Working Group at its meeting of 26 August. A note warning that no case folding occurs (so the canonical form is the same as the input lexical form) was added, as well as a note warning that only some of the constraints imposed by RFC 3066 are enforced as part of datatype validity.
Although no formal request for closure was made, since the reporter also noted the resolution of this bug over two years ago, I'm marking it closed.