This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
3.1.1 Static context Under statEnv.collations, it says that a collation consists of two functions: "the first function takes a set of strings and returns a sequence containing those strings in sorted order; and the second function takes two strings, returns true if they are considered equal, and false if not." This definition agrees with the definition of collation found in Xquery 2.1.1 "Static context" but not with the definition in F&O 7.5 "Functions based on substring matching" paragraph 4, which says "All collations support the capability of deciding whether two strings are considered equal, and if not, which of the strings should be regarded as preceding the other. For functions such as fn:compare(), this is all that is required. For other functions, such as fn:contains(), the collation needs to support an additional property: it must be able to decompose the string into a sequence of collation units...". It seems that there must be a third (optional) function associated with each collation, the function that maps to collation units.
This is the official response of the XML Query WG and the XSL WG. The definition of a collation in F&O (All collations support the capability of deciding whether two strings are considered equal, and if not, which of the strings should be regarded as preceding the other.) differs, as you have observed, from the definitions in Formal Semantics (a collation consists of two functions: "the first function takes a set of strings and returns a sequence containing those strings in sorted order; and the second function takes two strings, returns true if they are considered equal, and false if not.") and XQuery. Even though the definitions do not correspond directly, we do not believe this to be a problem. The definition in the Formal Semantics serves the requirements of Formal Semantics (and the analogous definition in XQuery/XPath serves those documents' requirements), while the definition in F&O serves that document's purpose. It is apparent to us that the two functions identified in the Formal Semantics definition can be used to derive the information that F&O says all collations support. The fact that F&O adds a further requirement (For other functions, such as fn:contains(), the collation needs to support an additional property: it must be able to decompose the string into a sequence of collation units...) does not, in our minds, imply that there needs to be an additional function to cause such decomposition to take place. Instead, we believe that the two functions identified by Formal Semantics are required to have that decomposition capability in order to perform their jobs. That is, although some collations (e.g., fn:compare()) can be performed without worrying too much about collation units, other collations (e.g., fn:contains()) cannot. But the former collection of functions do not suffer in any way if the collation happens to do such a decomposition. Our conclusion is that no changes to the documents are required because the definitions are consistent and adequate as written. We regret that our response to the previous comment (http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0910) did not directly address this particular concern. We hope that this response satisfies your concerns in this regard. The WGs also note that the dynamic evaluation sections of Formal Semantics is non-normative. We appreciate your feedback on the XML Query specifications. Please let us know if this response is satisfactory. If it is, please mark the bug as CLOSED. If it is not, please respond to this message, explaining your concerns.