[Bug 3224] Inequality

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3224





------- Comment #9 from davep@iit.edu  2007-04-20 18:18 -------
(In reply to comment #8)
> >no errors result from comparisons--only true or false results.
> 
> This might be true in a rather strict sense, but it seems a misleading
> statement. If you have a restriction of xs:integer, and define the maxInclusive
> value as "2007-04-20", you get an error. You can argue that this isn't an error
> that "results from a comparison" - rather, that the system refused to do a
> comparison; but in the ordinary sense of the word the error has occurred
> because 23 and 2007-04-20 cannot be compared (that is, they are incomparable).

Not that they cannot be compared.  In fact, they can be compared, and the
answers are that 23 <> 2007-04-20 is true, and 23 = 2007-04-20, 23 <
2007-04-20, and 23 > 2007-04-20 are all three false.  Of the derived
comparisons, 23 != 2007-04-20 is true, and 23 <= 2007-04-20 and 23 >=
2007-04-20 aree false.

But when you try to create a {min/max}{In/Ex}clusive facet for a
derived-from-integer datatype, it is illegal to use a non-integer value as its
{value}.

> In fact, you seem to be using "incomparable" to describe a quite different
> relationship: a relationship where two values *can* be compared,

If I understand what you mean by "*can* be compared", any two values "can be
compared".  Often the comparison returns false.  We are, I believe, quite clear
that "incomparable" means simply "neither equal, nor less-than, nor
greater-than".  If any of those relations returns true for a given pair, then
the incomparable relation returns false; if all three return false, then
incomparable returns true.  How can we make this clearer?

>                                                                  and the
> outcome of the comparison is a value akin to "unknown".

Surely not "unknown".  As illustrated above, for any two arguments to the
relation, the value (true or false) returned by (i.e., the "outcome of") the
comparison is certainly ascertainable, at least if the two arguments are
members of (any) datatype value spaces.  I fail to see how you could describe
the return value as "unknown" if you know what the two argument values are.

> Furthermore, people are unlikely to read the phrase "as far as this
> specification is concerned" as excluding comparisons done within an assertion,
> where the XPath comparison semantics apply - and these can certainly result in
> errors.

Now that is, at the very least, an interesting point.  I'm not the expert on
Schema's use of XPath.  Someone else will have to tell me whether or not an
XPath comparison that results in an error, as opposed to the comparison being
false, can be legitimately used in Schema.  I don't pretend to know.  If that
can arise, then we need a Note acknowledging it.  Can you open a new bug
stating that problem and providing an example?

Received on Friday, 20 April 2007 18:18:54 UTC