W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

Re: I've implemented the changes to xsd:dateTimeStamp

From: Evan Wallace <ewallace@cme.nist.gov>
Date: Wed, 01 Apr 2009 11:53:55 -0400
Message-ID: <49D38E13.9060607@cme.nist.gov>
To: Boris Motik <boris.motik@comlab.ox.ac.uk>
CC: "'W3C OWL Working Group'" <public-owl-wg@w3.org>

Boris Motik wrote:
> What you need to implement is basically a check
> whether a particular date-time value (with a particular time zone offset) is in
> a particular range. If the date-time value is not comparable to, say, the lower
> boundary of the range, then clearly the date-time value is not in the range.
I'm fine with this interpretation, as long as we explicitly state it in 
the spec. Otherwise,
it will not be clear.

> Another way of thinking about is as follows: given a lower and an upper boundary
> lb and up, you need to determine the set of date-time instants between them.
> This set is defined like this:
> { di | lb < di and di < ub }
> Thus, for di to be between lb and up, it must be comparable both to lb and up.

We also should say somewhere that a consequence of this is that 
dateTimeStamp ranges
with less than 28 hours difference between lb and ub will have no 
without-timezoneOffset in that range. This will be counter-intuitive to 
some, but it is
a direct consequence of the blurred resolution of ordering that occurs 
when values of these
two types are mixed (as per the xsd spec) and our handling of those 
blurred areas.

Finally, I would like to see the details of what will be permitted in 
the specification of
data ranges derived from xsd:dateTime. Will the facet values be 
restricted to xsd:dateTimeStamp?
I guess we already have constraints that will prevent folks from 
deriving from a local dateTime
(aka an xsd:dateTime where timezoneOffset must be absent). Otherwise, we 
would want
to make certain that the values for lb and ub facets were of like type 
and we would need to
explain that incomparability would occur in this case from 
xsd:dateTimeStamp values.

Received on Wednesday, 1 April 2009 15:54:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:58 UTC