RE: F&O WD: Issue 150: Should we support comparisons of date/tim e types that return indeterminate results?

Thanks for the comment.

Dealing with partial ordering causes many problems, and therefore surprises.
For example it means that the user (and the optimizer) can no longer rely on
invariants such as A<B => not(A>=B). It causes particular problems for
implementors (such as Microsoft) who want to map XQuery to an underlying SQL
database. We've been hoping to find a way of avoiding this level of
complexity. In the case of durations, one solution I proposed was to achieve
a total ordering by equating a month to 365.242199 div 12 days; this would
mean 12 months > 365 days and 12 months < 366 days, which would at least be
comprehensible even if not always what the user wanted. Unfortunately it
gets complicated when you look at the interactions with addition of
durations to dates, where you want some invariants like DATE1 + DURATION1 <
DATE1 + DURATION2 iff DURATION1 < DURATION2. So we decided to park the
problem on the back burner by disallowing the awkward cases for the time
being. Better to disallow them now than to allow them with semantics that we
will regret later.

Michael Kay

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com] 
> Sent: 09 May 2002 13:37
> To: public-qt-comments@w3.org
> Subject: F&O WD: Issue 150: Should we support comparisons of 
> date/time types that return indeterminate results?
> 
> 
> Hi,
> 
> You ask for comments on Issue 150: Should we support 
> comparisons of date/time types that return indeterminate results?
> 
> I strongly believe that you should support comparisons 
> between date/time types that return indeterminate results, 
> and between duration types that return indeterminate results. 
> I think that this is a question of finding a balance between 
> logical robustness and usability, and that usability should 
> be more important. People should be able to test whether a 
> year is longer than a second, or whether 35 days is longer 
> than a month.
> 
> Given that there's support for dealing properly with error 
> values in logical expressions, why not have indeterminate 
> results return an error? Users can then choose to treat that 
> error as true or false, or deal with it specially, as their 
> application requires.
> 
> I think that this is particularly important not for 
> individual comparisons but for the effect that it has on 
> sorting. From what I can tell, it's currently not possible to 
> sort elements on attributes that are declared with the type 
> xs:duration, without taking extra steps to convert them into 
> one of the two xs:duration subtypes. I don't think that users 
> should be made to jump through this hoop -- it should "just work".
> 
> Cheers,
> 
> Jeni
> ---
> Jeni Tennison
> http://www.jenitennison.com/
> 
>

Received on Friday, 10 May 2002 09:35:37 UTC