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 2.2.3 of Datatypes reads in part: The value spaces of primitive datatypes are abstractions, which may have values in common. In the order relation defined herein, these value spaces are made artificially ·incomparable·. For example, the numbers two and three are values in both the precisionDecimal datatype and the float datatype. In the order relation defined herein, two in the decimal datatype and three in the float datatype are incomparable values. Other applications making use of these datatypes may choose to consider values such as these comparable. There may be other passages which also assert or entail the proposition that for purposes of schema-validity assessment no comparisons of values from different primitive types are ever necessary, or that such comparisons always return false, etc. While true of XSDL 1.0 and of many parts of XSDL 1.1, such claims are no longer true of all parts of XSDL 1.1. In XPath expressions used to formulate assertions or conditional type assignment, values of different primitive types are not necessarily incomparable: the XPath type coercion rules make some of them comparable. And since XPath evaluation is now (within limits) part of schema-validity assessment, the distinction drawn in the text between 'incomparable for schema purposes' and 'possibly comparable in other contexts, not our problem' needs to be reformulated. Since the WG has agreed in principle on the state of affairs we want, I'm setting the status keyword here to needsDrafting, not needsAgreement.
(In reply to comment #0) > Section 2.2.3 of Datatypes reads in part: > > The value spaces of primitive datatypes are abstractions, > which may have values in common. In the order relation > defined herein, these value spaces are made artificially > ·incomparable·. For example, the numbers two and three > are values in both the precisionDecimal datatype and the > float datatype. In the order relation defined herein, > two in the decimal datatype and three in the float datatype > are incomparable values. Other applications making use of > these datatypes may choose to consider values such as these > comparable. > > There may be other passages which also assert or entail the proposition > that for purposes of schema-validity assessment no comparisons of values > from different primitive types are ever necessary, or that such comparisons > always return false, etc. Well, that passage itself doesn't seem to make such a statement about the "purposes of schema-validity assessment". I think the line you are thinking of is "The order relation is used in conjunction with equality when making ·facet-based restrictions· involving order. This is the only use of order for schema processing." Similar lines about equality and identity occur in each of their subsections. I suggest that each such line carry an exception, such as replacing the second sentence ("This is the only use...") by "This is the only use of *this* order for schema processing. However, some schema processing involves XPath expressions; when evaluating these expressions, the rules of XPath apply." I'm not aware of any other places that would need fixing, other than these three.
Suggest a slight change: "However, some schema >structures< processing involves XPath expressions; when evaluating these expressions, the rules of XPath apply." Reason: while the original proposal is both correct and in the style of similar warnings, I think this is an easy way to assure people that they need not scan the rest of the Datatypes specification looking for edge cases that use XPath. Given that our datatypes are used in contexts other than structures, I think it's of at least small incremental value to point out that the XPath dependency is only in structures.
This appears to be essentially an editorial question, not a substantive one, so I am marking it editorial.
(In reply to comment #2) > "However, some schema >structures< processing involves XPath expressions; when > evaluating these expressions, the rules of XPath apply." > > Reason: while the original proposal is both correct and in the style of > similar warnings, I think this is an easy way to assure people that they need > not scan the rest of the Datatypes specification looking for edge cases that > use XPath. Given that our datatypes are used in contexts other than > structures, I think it's of at least small incremental value to point out that > the XPath dependency is only in structures. I don't see that this helps, though I understand your concern. The problem is that the only "processing" that is "schema processing" *is* "schema structures processing". As applied to datatypes, the only schema (structures) processing is that which can be used to define user-defined datatypes, or to describe built-in datatypes. I suspect that what you are looking for is reassurance that datatype description using simple type definition components won't involve XPath. (One can, of course, conjure up datatypes without using schema processing--a process about which we have nothing to say.) In any case, I'll try to make some sort of comment that will give the reassurance you're looking for.
(In reply to comment #4) > As applied to datatypes, the only schema (structures) processing > is that which can be used to define user-defined datatypes, or to describe > built-in datatypes. I suspect that what you are looking for is reassurance > that datatype description using simple type definition components won't involve > XPath. > In any case, I'll try to make some sort of comment that will give the > reassurance you're looking for. OOPS! Simple type definitions *can* have assertions, which use XPath. So the "reassurance" can only be to point out this "edge case" so that it can be found without searching. Or maybe we should not make any such comment.... Mayhap the editors can discuss this ASAP.
On 12 Dec 2008, the WG accepted a proposal, with a directed modification that was not to be returened to the WG for further consideration; the result has been incorporated into the master datatypes.xml file, but a new SQ HTML version has not been generated.
The change has now been integrated into the status-quo document.