This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
minInclusive and other facets are said to only apply to "ordered" datatypes, and a datatype is said to be ordered if it has a non-trivial order. What makes an order "trivial"? Is it when no values A and B exist in the value space, where A < B? Or is it when, for all A and B, A <> B? Section 4.2.1 suggests that a order can become trivial via derivation. Must a schema processor detect, for instance, that a subtype of decimal derived with minExclusive=INF now has a trivial order because its only member is NaN? Why not just say a datatype is ordered if the order fundamental facet is 'total' or 'partial'?
(In reply to comment #0) > minInclusive and other facets are said to only apply to "ordered" datatypes, and a datatype is said to be > ordered if it has a non-trivial order. What makes an order "trivial"? Is it when no values A and B exist in the > value space, where A < B? Or is it when, for all A and B, A <> B? The former. I gather you feel we need some wordsmithing here. And we don't consider that a datatype "has" (in the sense of inherently associated with it) an order; it is ordered if schema associates an order with it. The "trivial" order got introduced to make sense out of the "order" of a union that includes datatypes for which we don't explicitly associate an order--though that's a moot point since unions don't get max/min/etc. facets. There was a time when we seemed to feel it necessary to explicitly say what the order was in unions, even though we don't use it. E.g., string is, for schema purposes, only trivially ordered.
> I gather you feel we need some wordsmithing here. Yes. I would prefer to get rid of all mention of a trivial order (and the "null" order, for that matter). The min/max facets are still well-defined whether the order is trivial or not. It's just that no value is value if there is a minExclusive facet on a trivially ordered datatype, for exmaple. No big deal. If you must keep the distiction of trivial vs. non-trivial orders, then add an explicit definition.
(In reply to comment #2) > Yes. I would prefer to get rid of all mention of a trivial order (and the "null" > order, for that matter). The min/max facets are still well-defined whether the > order is trivial or not. It's just that no value is value if there is a > minExclusive facet on a trivially ordered datatype, for exmaple. No big deal. That would be a change in the "unordered" datatypes; we currently simply prohibit those order-related facets on the "unordered" datatypes--your proposal would allow them (admittedly resulting in a singleton or empty value set for the derived datatype). I don't think it's likely that that will happen at this stage of 1.1. Will look into describing the situation better.
Sorry, I didn't mean to suggest allowing min/max facets on those never-ordered datatypes. Just change the description of how min/max facets apply to the possibly-ordered datatypes they are already allowed on. Essentially: remove the runtime check that the datatype is still ordered. > Will look into describing the situation better. Thanks.
Created attachment 488 [details] Shows a wording proposal of 19 September 2007 intended to resolve this issue. A wording proposal for this issue is attached as b2947.html (or will be if I get the mechanics right). The salient properties of the proposal are: 1 change the definition of 'ordered' to appeal to the table in the appendix, not to the specification of a non-trivial order. 2 de-emphasize the question of triviality vs. non-triviality; it is a possibly relevant mathematical point, not the basis of any difference between conforming and non-conforming schemas or processors, or between valid and invalid documents or values. 3 remove or recast the places where the spec currently says that an order relation is specified for all value spaces, to say that an order relation is specified for some value spaces and not for others. Owing to haste on my part, the proposal has NOT had the normal editorial review.
I'm setting the keyword 'needsReview' to signal that WG action is needed on the wording proposal attached with comment #5.
(In reply to comment #5) > A wording proposal for this issue is attached > 3 remove or recast the places where the spec currently > says that an order relation is specified for all value > spaces, to say that an order relation is specified for > some value spaces and not for others. Inasmuch as the proposal now only gives a specification of an order relation for the value spaces of those datatypes which accept an order-requiring constraining facet, we should remove the fancy determination of the ordered facet for unions, instead making it false for all unions. Also, we should not say in 2.1 in the definition of datatype that each datatype has "a small collection of functions, relations, and procedures associated with the datatype. Included are equality and order relations on the value space" since not all datatypes will have an associated order relation. When we decided to uniformly give each datatype an order, the trivial order if none other was specified, I searched to find all places where we said not all datatypes had an order. Now we need to search to find all the places where we say or use the fact that all datatypes do have an order, possibly trivial.
On 21 September, the WG accepted the wording proposal contained in the first attachment ("Shows a wording proposal of 19 September ...") and instructed the editors to prepare a follow-on proposal in which the entire spec is systematically checked and all passages are changed if they currently imply that all datatypes have some order specified. I'm leaving this issue open until the editors finish that follow-on proposal.
The status of this issue (as described in comment #8) should be needsDrafting, not needsReview. I'm changing it accordingly.
The review of the spec described in comment #7 and comment #8 has now been done (at least, each occurrence of the string 'order' has been reviewed, and thus all the occurrences of the words 'order', 'ordering', etc.). The review suggests that the only passage in the status quo text which needs to change, in order to reflect the fact that not all datatypes now have a defined ordering, is the definition of 'datatype' in section 2.1. This currently reads [Definition:] In this specification, a datatype has three properties: - A ·value space·, which is a set of values. - A ·lexical space·, which is a set of ·literals· used to denote the values. - A small collection of functions, relations, and procedures associated with the datatype. Included are equality and order relations on the ·value space·, and a ·lexical mapping·, which is a function on the ·lexical space· onto the ·value space·. The required change consists in changing the phrase "Included are equality and order relations on the value space" to "Included are equality and (for some datatypes) order relations on the value space". As far as I can tell, no other passage in the Datatypes spec currently assumes or entails the existence of an ordering relation on all value spaces. If the WG accepts this proposal, this issue can be closed.
A wording proposal for this issue (among others) was placed on the server on 4 February 2008 at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.omnibus.200801.html (member-only link).
Created attachment 515 [details] Second wording proposal The XML Schema Working Group today adopted a wording proposal which we believe completes the resolution of this issue. The part of that proposal related to this issue is shown in the attachment. Since we believe the issue is now resolved, I'm changing the status of this issue accordingly. Xan, as the originator, if you would inspect the changes shown in the wording proposal attached, and indicate either that you are happy with (or at least willing to accept) the WG's resolution of the issue, by changing the status of the issue to CLOSED, or that you are not satisfied, by changing the status to REOPENED and adding a comment explaining what's wrong and what it will take to resolve the issue to your satisfaction, we'll be grateful. If we don't hear from you in two weeks, we will assume that you are content.
Looks good to me. Marking closed. In passing, it appears that the following new sentence has at least one too many commas: For some datatypes, an order relation is prescribed, for use in checking upper and lower bounds of the ·value space·.