- From: Evan Wallace <ewallace@cme.nist.gov>
- Date: Wed, 01 Apr 2009 11:53:55 -0400
- 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
dateTime-values-
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.
-Evan
Received on Wednesday, 1 April 2009 15:54:43 UTC