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-dateTimes)?
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 Friday, 10 May 2002 21:11:27 UTC