[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: limits of the generic

• To: "Jeni Tennison" <jeni@j...>,<xml-dev@l...>
• Subject: RE: limits of the generic
• From: "Dare Obasanjo" <dareo@m...>
• Date: Sun, 29 Sep 2002 03:35:37 -0700
• Cc: "Jonathan Robie" <jonathan.robie@d...>
• Thread-index: AcJnocoolH9A/q2pTgWS09utzN1X0gAAYUJz
• Thread-topic: limits of the generic

I suggest forwarding your concerns to the XML Query working group as a comment. 
 
I disagree with some of your opinions but given that it is about 3:30 AM, I'm slightly less than coherrent and will reserve my comments for regular hours. 

	-----Original Message----- 
	From: Jeni Tennison [mailto:jeni@j...] 
	Sent: Sun 9/29/2002 3:20 AM 
	To: xml-dev@l... 
	Cc: Dare Obasanjo; Jonathan Robie 
	Subject: 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/
	
	

• Prev by Date: Re: limits of the generic
• Next by Date: Re: limits of the generic
• Previous by thread: Re: limits of the generic
• Next by thread: Re: limits of the generic
• Index(es):
  • Date
  • Thread