As a guiding principle in defining equality and ordering (4.2.12), I propose
that in comparing any two values of the same type, exactly one of "equal to",
"is ordered before", or "is ordered after" hold.
(If we reject this principle, and instead allow one value to be neither equal
to, nor before, nor after a second like-typed value, we need to revisit the use
of these terms in query LessThanOrEqualTo and GreaterThanOrEqualTo operators.)
I also suggest we define these concepts in terms of the various "compareTo"
methods of J2SE, wherever possible, since that's the behavior JCR users would
generally expect. Doing so also frees us from worrying about special cases
(e.g. Double.NaN) or any inconsistencies between the "equals" methods and the
"before/after" methods (e.g. Calendar).
- Don't rely on Value.getString(), since we only define that for
UTF-8 streams (184.108.40.206). Instead compare the octets in turn
(with language for different length values) using Byte.compareTo.
- STRING, URI, REFERENCE, WEAKREFERENCE: Use String.compareTo
- BOOLEAN: Boolean.compareTo
- DATE: Calendar.compareTo
- DOUBLE: Double.compareTo
- LONG: Long.compareTo
- BIGDECIMAL: BigDecimal.compareTo
- NAME and PATH: I'd just use v1.getString().compareTo(v2.getString()) and call
it a day. However, I recall that, when we discussed this, others wanted more
namespace-savvy behavior. If this is still the case, I suggest we make sure
that exactly one of "equals", "before", or "after" holds for any two values
(this is not currently the case). For PATHs, we also need to specify the
treatment of indices, what happens if the two PATHs have different numbers of
segments, how . and .. are treated, and what happens in comparing a relative
path to an absolute path. (Or we could just use