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

Jeni, perhaps you should just take our failure to include partial ordering
of durations as evidence that we share your concern about the complexity of
the specs and the need to avoid adding features that increase this
complexity.

If we all agreed which features are really useful and which are
complications that we can live without, then life would be a great deal
easier. We all have our own hit lists, but every feature currently in the
specs has a champion who will argue for its retention.

Michael Kay

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com] 
> Sent: 11 May 2002 01:43
> To: public-qt-comments@w3.org
> Subject: Re: F&O WD: Issue 150: Should we support comparisons 
> of date/tim e types that return indeterminate results?
> 
> 
> Mike wrote:
> > 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.
> 
> When you say "for the time being" are you talking about "for 
> the next couple of iterations on the WDs" or are you talking 
> about "for this version of XQuery/XPath 2.0"? If it's the 
> latter, I think that's a big mistake. If it's the former, put 
> this message on ice until you come to reviewing your decision.
> 
> Perhaps the problem is similar to that of strings. When you 
> ask whether one string is less than another string, the 
> answer is "it depends". What about defining collations for 
> dates, which might use specific dates against which to test 
> durations? Or, better, using three-valued logic, which you 
> already have some support for by way of error values?
> 
> The direct results of this decision on usability are:
> 
>   - the inability for people to manipulate durations that don't fit
>     neatly into those categories, such as:
>     - values that internally mix months and days (e.g. prison
>       sentences: "man sentenced to a year and a day")
>     - values of types that might be in months or days (e.g. durations
>       between checkups: "come to see me every six months"; "I think I
>       need to see you once a week")
>     
>   - the inability for people to use existing schemas that involve
>     xs:duration without casting to the more specific types within
>     their query or stylesheet
> 
>   - even more hugely long function names
> 
> At the very least, couldn't you allow people to add all kinds 
> of durations to dateTimes 
> (http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTim
es)?
Then users could get around the lack of xs:duration support by choosing a
date, adding the durations to it, and comparing them.

Or have you made the order of addition flexible so that you can optimise by
doing the calculations in whatever order you like? If so, you still have
problems:

  (2000-02-29 + P1Y) + P1M => 2001-03-28
  (2000-02-29 + P1M) + P1Y => 2001-03-29

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Sunday, 12 May 2002 17:24:18 UTC