This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 13.1.3 requires that all implementers must recognize collation URIs as described in the Unicode Collation Algorithm, however there is no requirement to actually support any tailorings. I think we may want to consider requiring some level of support that all implementers will provide. [ This items created from I18N-ACTION-376 ] This is an I18N WG comment.
This bug applies equally well to the XPath and XQuery Functions and Operators 3.1 specification.
Personal response. Thanks for the comment. Would I be right in thinking that the comment is essentially about conformance levels? We did think about this, but we didn't feel we could ask implementors to support ALL languages (especially as the set of languages is constantly changing), and we didn't feel there was any sensible way of defining a set of core languages that all products must support. In addition, we recognize that some vendors might want to produce products, or product variants, that are targeted at particular geographic markets, and we did not feel that such products should be deemed non-conformant. We also run into issues here of "conditional conformance": XSLT processor ZYX is conformant provided you install an internationalization library that does A, B and C, or provided that you perform other configuration steps. Which doesn't actually provide any real interoperability benefits over saying that the feature is optional. In practical terms, bundling a rich inernationalization library with an XSLT processor can seriously bloat its size, at a time when running on mobile devices is increasingly important. So I think we should allow the market to develop solutions tailored to varying user requirements. We could consider making support for some of the non-language-related parameters mandatory (e.g. collation strength), but which ones? Almost any decision here is an assertion that some groups of users/requirements are more important than others.
The XSL WG reaffirmed its previous view that we do not want to require all products to support all locales; and short of that, we don't see any prospect for defining a minimum subset of locales. This applies equally to collation parameters such as backwards=yes (treating the last accent as the most significant). We think that the two rules we have defined will achieve the desired level of interoperability: * fallback=no means that if the implementation supports what you ask for, you get fully interoperable results, and if it doesn't, you get an error * fallback-yes means that your code will work with every implementation, but may produce slightly different results. We believe that if we tried to raise the conformance bar higher than this, then there would be environments (e.g. embedded devices) where producing a conformant processor would not be economically viable, and the effect would be either that the spec is not implemented at all in those environments, or that the implementations choose to be non-conformant. We are therefore respectfully declining this suggestion. (Note, the XSL WG and XQuery WG agreed that XSL WG would lead on responding to this set of bug reports, so this decision does not need further endorsement by XQuery WG).