[
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
http://www.w3.org/TR/xquery-operators-20020816/#duration-subtypes
> 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
because
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!
http://sbc.yahoo.com
|
