Re: An approach to xsd:dateTime

Bijan wrote:

> You have some freedom. AFAICT, we're not going to adhere too closely 
> to the xsd semantics here. But if we look at:
>
> http://www.w3.org/TR/xmlschema-2/#dateTime
>

Yes.  Let's look at the current XML Schema Datatypes document which is 
simpler than the working draft,
though it does have some issues.  It has some very poor wording in 
places (timezones are *not* durations)
and if you haven't read ISO 8601:2004, XSD's less careful wording can be 
misleading.

> """dateTime values may be viewed as objects with integer-valued year, 
> month, day, hour and minute properties, a decimal-valued second 
> property, and a boolean timezoned property."""
>
> Yeek! These are complex objects. What facets to involve is unclear. 
> It's *much* simpler if we can treat dateTime literals as alternative 
> identifiers for decimals. 
...

But above, they wrote "may be viewed as" and you left out all the text 
that followed in the definition
for dateTime which reads:

  Each such object also has one decimal-valued method or computed 
property, timeOnTimeline, whose
  value is always a decimal number; the values are dimensioned in 
seconds, the integer 0 is
  0001-01-01T00:00:00 and the value of timeOnTimeline for other dateTime 
values is computed using
  the Gregorian algorithm as modified for leap-seconds. The 
timeOnTimeline values form two related
  "timelines", one for timezoned values and one for non-timezoned 
values. Each timeline is a copy of
  the ˇvalue spaceˇ of decimal, with integers given units of seconds.

So I see this as a similar approach to what you suggest where they are 
using this object view to explain
the mapping between the literal values and the values on the timeline.  
Furthermore, the text following
the definition goes on to say:

  The ˇvalue spaceˇ <http://www.w3.org/TR/xmlschema-2/#dt-value-space> 
of *dateTime* is closely related to the dates and times described in ISO 
8601. For
  clarity, the text above specifies a particular origin point for the 
timeline. It should be noted, however,
  that schema processors need not expose the timeOnTimeline value to 
schema users, and there is no
  requirement that a timeline-based implementation use the particular 
origin described here in its
  internal representation. Other interpretations of the ˇvalue spaceˇ 
<http://www.w3.org/TR/xmlschema-2/#dt-value-space> which lead to the 
same results (i.e.,
  are isomorphic) are of course acceptable.

So they sanction implementations that use Unix epoch or some other 
arbitrary time as the origin
for the timeline, much as Boris alluded to in some of his emails.

...
> Consider:
>
> """The value of each numeric-valued property (other than 
> timeOnTimeline) is limited to the maximum value within the interval 
> determined by the next-higher property. For example, the day value can 
> never be 32, and cannot even be 29 for month 02 and year 2002 
> (February 2002)."""
>
> And:
>
> """The timeOnTimeline values form two related "timelines", one for 
> timezoned values and one for non-timezoned values. Each timeline is a 
> copy of the ˇvalue spaceˇ of decimal, with integers given units of 
> seconds."""
>
> Two timelines!

Again, I don't see why separate value spaces is such a big deal, but 
drop the second one if you really want.

> Right, so step one is to see if the minimal proposal meets some of 
> your needs (a significant chunk thereof). 

Do we have one proposal to evaluate?  Boris made a suggestion but there 
has been considerable discussion
since.  So let me suggest some parameters of a small Date-Time feature 
for OWL2:

- the lexical space for OWL Date-Time values will be the subset of the 
xsd:dateTime lexical space which
includes the timezone component.

- time zone offsets will be used to normalize values to the timezone 
associated with UTC and those values
will then be mapped to a single timeline with a value space based on the 
OWL2 equivalent of  xsd:decimal
where integer values represent integral numbers of seconds.

- the origin of this timeline will be stated in the OWL2 specification 
as corresponding to a particular date in
the Gregorian calendar and a particular UTC time of day.  The mapping of 
dateTime literals to values on this
timeline does not take into account leap second adjustments periodically 
made to UTC and thus will diverge
from UTC by small amount for values further from its origin.

Evan

Received on Friday, 25 July 2008 23:03:53 UTC