[
Lists Home |
Date Index |
Thread Index
]
Hi Dare,
>> But I think that you're getting at the fact that it's undefined. I
>> can think of several ways of dealing with that which don't rule out
>> perfectly legitimate uses of durations that mix years or months and
>> days or times:
>
> I question your usage of the term "perfectly legitimate". The mixing
> of years, months and days in a single duration type leads to
> indeterminate order relationships at several points which means that
> the type is partially ordered. More information about this is
> available in the W3C XML Schema Datatypes recommendation[0]
I mean "perfectly legitimate" in the following ways:
1. Representing durations that comprise years/months and days/times
is legal according to the W3C XML Schema Data Types
Recommendation. I cannot find any erratum nor even comment on the
Recommendation that indicates that this is going to change.
Please do point me to it if you know of one.
2. The majority of comparisons and other manipulations of durations
do not need to undefined results. I don't see why these
comparisons and manipulations should be banned when they are
completely decidable. An example is the addition of a duration to
a dateTime.
3. It is reasonable for users to wish to perform comparisons and
manipulations that involve durations that mix years/months and
days/times. It is unreasonable to prevent users from doing so in
order to make implementation easier or because a group cannot
agree on a fixed (even if hacky/baroque) way of performing the
calculation.
>> We could simply say that if it's undefined it's false (though I
>> believe that this leads to optimisation problems because it means
>> that it's no longer true that a values must be one of equal,
>> greater than or less than another value):
>>
>> P3M = P90D => false
>> P3M > P90D => false
>> P3M < P90D => false
>
> Did you write this with a straight face? A type that allows (A < B,
> A = B, A > B) to all return the same value is confusing to end users
> and rather unuseful. Also it is a significant, hard-to-find bug
> waiting to happen in someone's application.
I believe that it's good practice while brainstorming to come up with
ridiculous suggestions. Sometimes they turn out to be not as
ridiculous as you first think, sometimes they don't.
>> We could introduce three-value logic:
>>
>> P3M = P90D => ()
>> P3M > P90D => ()
>> P3M < P90D => ()
>
> So how would you sort the following durations P13M, P3M, P91D,
> P367D, P365D, P90D, P89D, and P12M given your 3-valued logic?
Personally, I'd say:
P13M, P367D, P365D, P12M, P3M, P91D, P90D, P89D
Using the logic that if d1 > d2 is true then d1 is sorted before d2.
If neither d1 > d2 nor d2 > d1 is true, then sort in the original
order. But there are several correct answers here.
>> We could ban direct comparisons of durations, forcing users to add
>> them to dates in order to compare them:
>>
>> 2002-09-28 + P3M = 2002-09-28 + P90D => false
>> 2002-09-28 + P3M > 2002-09-28 + P90D => true
>> 2002-09-28 + P3M < 2002-09-28 + P90D => false
>
> Why is a A + 3M greater than A + 90D? The 3 months range consisting
> of January (31d), February (28d), and March (31d) is exactly 90 days
> long. I guess noone is expected to use this type for anything
> requiring accuracy or correct results then?
I think that you've misunderstood me. I was suggesting that users
supply their own date for the comparison. It's then up to the user to
decide whether 2002-09-28 is a good base date, or whether 1970-01-01
would be better, or if they want to go with 2000-01-01 instead.
Currently users are not even able to use this tactic in order to
compare durations because they cannot add durations to dates.
>> Or we could use the current date/time automatically in a comparison
>> like the above. Or we could pick a date in the past and use that
>> consistently for all duration comparisons.
>
> *cough* Hack *cough*
As I said above, I don't particularly care if it's a hack or not
(though obviously I'd prefer it if it wasn't). What's important to me
is that the user isn't prevented from doing things that the user wants
to do. If we have to be arbitrary about it, so be it. If we have to
say it's implementation-defined, so be it. But forcing users to alter
their schemas so that they can use XPath 2.0 is not acceptable, in my
opinion.
>> Any of these would be better than making it an error for people to
>> ask perfectly legitimate, and answerable, questions and introducing
>> two new, more restrictive, data types that users have to use
>> instead of xs:duration in order for their schemas to work with
>> XPath 2.0. For example, I think that "What is 2002-09-28 plus a
>> year and a day?" is also a simple question with a well-defined
>> answer; I don't think it should be an error to try to ask it.
>
> It isn't a well defined question. Is the year a regular year or a
> leap year?
I think that it's perfectly decidable whether 2002 is a leap year (and
years in durations are neither leap years nor not leap years, they are
simply years). If you look at:
http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes
you'll find an algorithm for adding durations (all kinds of durations)
to dateTimes which you can use. It's not particularly hard to
implement.
> On the other hand "what is 2002-09-28 plus 366 days?" is a simple
> question with a well defined answer which is possible in XPath 2.0
Unless your 'P366D' happens to be typed as an xs:duration, of course.
In which case, depending on the level of static type checking your
implementation does, you might not be able to run the
transformation/query at all (as I understand the somewhat complex type
conversion rules).
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
