OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] limits of the generic

[ Lists Home | Date Index | Thread Index ]

--- Jeni Tennison <jeni@jenitennison.com> wrote:
> Hi Dare,
> 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.

The XML Query working group is in the process of
requesting the addition of two new duration types and
[hopefully] the deprecation of the xs:duration type. A
note about adding the XML Query working group's
request to add the new xs:duration subtypes to W3C XML
Schema is in the F & O at

>   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.

You can add xs:dayTimeDuration or an
xs:yearMonthDuration to an xs:dateTime. 

However I am have been curious about something; is
there any programming environment that currently
supports being able to add 4 years, 3 months, 2 days,
7 hours, 15 minutes and 12 seconds to September 28th,
2002 at 1:36:07PM ? 

Adding xs:durations to an xs:dateTime do lead to
undefined results. 

>   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.

It is also reasonable for users to expect operations
on decimal numbers to always return accurate results.
However, there is a big difference between reasonable
expectation and efficiently implementable. 

I'd rather lean towards a limited and well-defined set
of operations than enabling some scenarios but
allowing undefined situations to creep in. I guess
that's why I prefer Java & C# to C++. 

> >> 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

You would be wrong given your three valued logic

   P12M = P365D  =>   ()
   P12M > P365D  =>   ()
   P12M < P365D  =>   ()

So how would sorting work generically? 

> 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. 

What is the original order? 

> 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.

Besides the fact that this is a hacky workaround, like
I asked before I'm not sure there are [m]any
programming environments that even enable one to do
what you're asking. 

Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS