Re: draft of LC comment to XML Schema WG

Fine for me.


On 6 Aug 2008, at 18:40, Peter F. Patel-Schneider wrote:

> Here is my revised LC comment.  I've also put it on a Wiki page
> peter
> The W3C OWL WG is determining how to use XML Schema dateTime values  
> from
> the last call working draft in OWL
> ontologies.  The main problem we face concerns dealing with dateTime
> values that do not have a timezone.  The LC document puts these  
> values on a
> single separate totally-ordered timeline that is only partially  
> ordered
> with respect to the absolute timeline.
> For the purposes of reasoning in OWL, it is much easier to deal with
> dateTime values where the timezone is present.  Such values can be
> converted to single time points (using timeOnTimeline) and a complete
> order determined from the time points.  We would thus like to have a
> derived XML Schema datatype for dateTime with a required timezone.
> There are already OWL ontologies that contain dateTime values where  
> the
> timezone is absent.  Such dateTime values may come from different
> documents, and that really have a different notion of what their local
> (unspecified) time is.  The LC document, however, makes these  
> values all
> equal, as they are identical.
> Our proposed suggestion to handling such ontologies is to put off the
> task of determining "missing" timezones to tools, with roughly the
> wording that dateTime literals that are missing timezones are
> syntactically illegal, but that tools MAY accept such dateTime  
> values by
> determining what the "local" timezone is for the value and SHOULD
> produce a warning if they do so.
> This treatment of dateTime values appears to violate the equality of
> dateTime values from the LC document, as different dateTime values  
> that
> compare equal according to the LC document are turned into dateTime
> values that do not compare equal.  The WG would appreciate guidance on
> how to do this processing in a compliant manner.
> There are other potential solutions to reasoning with such dateTime
> values (such as treating them as true intervals).  However, these
> solutions also appear to violate equality of dateTime values.
> We also do not find a justification for having the range of  
> timezone be
> -840 to +840.  The range of timezones currently in use ranges from
> UTC-12 to UTC+14 (

Received on Thursday, 7 August 2008 13:16:54 UTC