[
Lists Home |
Date Index |
Thread Index
]
My apologies, I misread and misunderstood the algorithm in the W3C XML Schema Datatypes recommendation. Schema authors having to rewrite their schemas to take advantage of XQuery is a concern and it would nice to here from any who are using the xs:duration type in their schemas and combining years, months, days and hours in the same value.
-----Original Message-----
From: Jeni Tennison [mailto:jeni@jenitennison.com]
Sent: Sat 9/28/2002 3:53 PM
To: Dare Obasanjo
Cc: Dare Obasanjo; uche.ogbuji@fourthought.com; Jonathan Robie; xml-dev@lists.xml.org
Subject: Re: [xml-dev] limits of the generic
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
Yes, I'm aware of that, but I'm not aware of any movement on the W3C
XML Schema side. It would be good to hear from members of the XML
Schema WG as to whether they intend to make any changes here.
>> 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 ?
The extension function date:add() from EXSLT does this. In an
implementation that supports it (4XSLT, libxslt, and any processor
that supports extension functions in JavaScript or XSLT, if you use
the proper stylesheets), you can do:
<xsl:value-of select="date:add('2002-09-28T13:36:07',
'P4Y3M2DT7H15M12S')" />
> Adding xs:durations to an xs:dateTime do lead to undefined results.
It would help for you to demonstrate this assertion, using the
algorithm defined in the W3C XML Schema Datatypes Rec. [1] If there's
a gap in that algorithm, it would certainly be worth knowing about.
>> 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 recognise that there is a balance between implementability and
usability, but I've implemented the algorithm referenced above, in
XSLT, and it's really not that hard to do.
>> >> 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?
When you sort a sequence, the original sequence has an order. I
assumed you were asking how I'd sort the sequence:
( P13M, P3M, P91D, P367D, P365D, P90D, P89D, P12M )
In XPath 2.0, the only kinds of collections of values are sequences,
so I don't think that you can have meant anything else, at least not
within XPath 2.0. The same fallback to the original sequence is what's
used when sorting any other values, when you have two values that are
*equal*. I'm not sure what's wrong with using it here as well?
I may have got the ordering wrong, so I'll just go through the logic
again. Here's a little table that shows the result of whether the
row duration is greater than the column duration:
P13M P3M P91D P367D P365D P90D P89D P12M
P13M - T T T T T T T
P3M F - () F F () () F
P91D F () - F F T T F
P367D F T T - T T T T
P90D F () F F - T F
P89D F () F F F F - F
P12M F T T F () T T -
From this, we can see that P13M is greater than any of the other
durations, so that comes first:
( P13M, ... )
Next is P367D, since that's definitely more than any of the remaining
durations:
( P13M, P367D, ...)
Next there's P365D and P12M, which are greater than the other
durations, but undefined against each other. In the original sequence,
the one you specified, P365D was before P12M, so that's the order that
they take in this sequence:
( P13M, P367D, P365D, P12M, ... )
After that are P3M, P91D, P90D and P89D (in that order in the original
sequence). P3M is undefined against any of those, and it comes before
all of them in the original sequence, so it should come first of that
set. P91D is greater than P90D or P89D, so it should come before them,
and similarly P90D is greater than P89D, so it should go first of that
pair, so you end up with:
( P13M, P367D, P365D, P12M, P3M, P91D, P90D, P89D )
If you'd like to suggest another sequence where you think that this
algorithm wouldn't work, I'd be happy to give it a shot.
>> 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.
It's just numeric calculations, and not even very complicated numeric
calculations at that. Honestly, if I can do it with the basic
mathematical support in XPath+XSLT 1.0 then you can do it in anything.
Cheers,
Jeni
[1] http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes
---
Jeni Tennison
http://www.jenitennison.com/
|
