[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
Dare wrote: > xs:duration is broken and should never have made it into the W3C XML > Schema REC in the first place. Simple question; Is an xs:duration > representing 3 months equivalent to an xs:duration representing 90 > days? > > On the other hand, xf:yearMonthDuration and xf:dayTimeDuration are > fully ordered and can be sorted in the manner you described. I forgot to bring up the fact that xs:dateTime etc. aren't fully ordered either, so following the same logic as above we should have: xf:dateTimeWithTimezone xf:dateTimeWithoutTimezone xf:dateWithTimezone xf:dateWithoutTimezone ... What the F&O WD does at the moment is treat xs:dateTimes without timezones as being the same as xs:dateTimes with a UTC timezone, in other words treating: 10:34:00 as if it were: 10:34:00Z My understanding is that date/times without timezones are supposed to be treated as if they specify a "local time", which is particularly useful when you want to talk about things that happen at the same local time each day, even when the timezone changes between summer and winter. For example, if, in July, I had a friend who lived in New York and she said "there's a bus at 10:34:00" it would mean the same as her saying "there's a bus at 10:34:00-04:00", whereas if I say, in November, "there's a bus at 10:34:00" it would mean the same as me saying "there's a bus at 10:34:00Z". Of course when you schedule something down to the particular day, then you can *know* what timezone is relevant. So I can tell my friend "my plane touches down at 2002-11-29T09:45:00-05:00 (2002-11-29T14:45:00Z)" (I'll assume we're both geeks, so she understands ISO 8601-formatted date/times). But if she sent off a query to her nice XQuery-driven web service asking which buses I can catch from the airport after 2002-11-29T09:45:00-05:00, a bus at 10:34:00 (local time -- no timezone) won't come up because 10:34:00Z is before 14:45:00Z. I don't particularly care that this gives *wrong* results (though of course I do think that it would be better if it gave the right one), but I do think that it's inconsistent, confusing and unhelpful to have one set of partially ordered data types be totally ordered through an arbitrary and sometimes inaccurate conversion (by assuming that local time means UTC) but another partially ordered data type be split into subtypes (which don't even cover the entire range of possible values). I think that it would be better to have a consistent approach to partially ordered data types. One of: - creating subtypes that are ordered - using three-valued logic - performing an arbitrary conversion to give total ordering (An arbitrary conversion in the case of xs:dateTime could be to convert into a dayTimeDuration by assuming that P1Y equals P365DT4H and P1M equals P30DT10H15M, or something rather more accurate in seconds.) Personally I prefer either the second or third option since (a) it means there are fewer data types cluttering the spec and (b) it would mean that *all* durations could be handled, not just those that are totally ordered. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|