This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6043 - Pls define a restriction of dateTime with required timezones
Summary: Pls define a restriction of dateTime with required timezones
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: Macintosh Mac System 9.x
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL: http://lists.w3.org/Archives/Public/w...
Whiteboard:
Keywords: resolved
Depends on:
Blocks: 6658
  Show dependency treegraph
 
Reported: 2008-09-09 02:04 UTC by C. M. Sperberg-McQueen
Modified: 2009-03-20 16:27 UTC (History)
3 users (show)

See Also:


Attachments

Description C. M. Sperberg-McQueen 2008-09-09 02:04:19 UTC
In email to the XML Schema comments list on 5 September 2008
(http://lists.w3.org/Archives/Public/www-xml-schema-comments/2008JulSep/0135.html),
Peter F. Patel-Schneider raised the following issue (among others):

  1/ Time instants

  1.1/ Derived type for time instants with a required timezone

  The W3C OWL WG is determining how to use XML Schema dateTime values
  from the last call working draft [2] in OWL ontologies. The main
  problem the WG faces concerns dealing with dateTime values that do
  not have a timezone. The LC draft 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.

  The WG requests that a derived XML Schema datatype for dateTime with
  a required timezone be added to the XML Schema datatypes spec.
Comment 1 C. M. Sperberg-McQueen 2008-09-09 02:34:57 UTC
If as you suggest a great many applications really should require explicit
time offset information in all dateTime values, then I see the rationale for
defining such a derived type in the XSD spec, analogous to the definition
there of the totally ordered subtypes of duration (added in 1.1 vis-a-vis
1.0).

Two considerations worry me ever so slightly (I am speaking now only for
myself, not for the XML Schema WG).  Simple considerations of symmetry 
suggest that a restriction which requires time zone offset information
ought, on principle, to be twinned with a restriction which forbids time 
zone offset information (for use, perhaps, in applications which cannot
always use offset information -- e.g. because like the W3C telcon bridges
the application uses times, including future times, tied to civil time zones, 
which have variable offaet from UTC.  

A similar consideration suggests that if we define such restrictions for
dateTime, we ought perhaps also to do so for each of the date/time-related
types which can currently bear a time zone offset.  That is, pretty much
all of them.  All told, that would be sixteen new derived datatypes, if both
of these lines of thought were followed.  As an editor of the spec, I feel
my heart quailing at the prospect. 

Can we identify a rationale for specifying just one (or just a few) of these
sixteen types, and not all sixteen?

I should note also that if the XML Schema WG fails to add the datatype you
want, the OWL WG can of course define the datatype yourselves.  I believe,
however, that your reason for suggesting we do it is that you think it 
better done in the XSD spec, and not that you don't realize you can define 
it yourselves.  (If I'm wrong on this, please set me straight.)
Comment 2 Michael Kay 2008-09-09 07:58:13 UTC
My reaction was similar - I don't like the idea of 16 new datatypes. Chronology already accounts for far more than its fair share of the Part 2 specification.

Perhaps though there is a case for a facet to make the timezone offset required or disallowed. OK, it can be done using patterns, but that doesn't really capture the semantics very well, and is impossible for applications to recognize and treat specially.

The existence of types that recognizably require or disallow timezone information is certainly something an XPath optimizer could take advantage of: at present code has to be generated for the worst case, where operations contain a mixture of values with an without timezone offsets, when in practice the mixed case is very rare. But the existence of a facet would be enough to provide this information, it doesn't need built-in derived types.

(personal response, of course)
Comment 3 Peter F. Patel-Schneider 2008-09-24 20:09:07 UTC
I don't think that I can come up with rationales for the various 16 types.  The OWL WG request is only to provide a well-known name for the particular datatype that will be part of the the OWL spec.  If the XML Schema WG decides not to add this datatype, I expect that the OWL WG will define its own datatype, which probably wouldn't quite be the same as the datatype defined from xsd:dateTime by means of a pattern.

Perhaps an easier request would be to instead have a facet that explicitly requires/forbids timezone.

Anyway, is there an expected timeline for a decision on this?
Comment 4 Dave Peterson 2008-09-29 15:11:58 UTC
(In reply to comment #3)

> Anyway, is there an expected timeline for a decision on this?

To get the resolution into bugzilla, I'll note from the minutes of the WG call of 2008-09-19,
http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Sep/0025.html ,
a proposal to
"instruct the editors to define (a) a new facet for specifying that the timezone is allowed, required, or forbidden, and (b) one new datatype (not two) derived from dateTime, with a required timezone." was adopted.
Comment 5 Peter F. Patel-Schneider 2008-10-01 20:06:49 UTC
At our teleconference today and in some email messages on its mailing list, the OWL WG discussed dateTime.  There was concern expressed that the OWL view of dateTime is somewhat different from the XML Schema view in that what will count in OWL is *equality*, not *identity*.

To show how this might be different from XML Schema, consider stating that a meeting must have a single startTime, which can be done follows (ignoring declaration aspects of OWL ontologies):
SubClassOf(ex:meeting ExactCardinality(1 ex:startTime) )

This is consistent with the following facts:
ClassAssertion(ex:meeting1 ex:meeting)
PropertyAssertion(ex:startTime ex:meeting1 "2008-10-01T21:00:00-05:00"^^xsd:dateTime)
PropertyAssertion(ex:startTime ex:meeting1 "2008-10-01T20:00:00-06:00"^^xsd:dateTime)
because the two time instants are equal even though they are not identical.

The OWL WG hopes that this use of equality is in accordance with the XML Schema Datatypes specification.  (Personally I believe that not only is this in accordance with the XML Schema specification, but it is the way things are supposed to be, but the WG was worried.)
Comment 6 C. M. Sperberg-McQueen 2008-12-18 23:33:03 UTC
A wording proposal intended to resolve this issue is now on the W3C
server (member-only link) at:

  http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b6043.html

This is a revision of an earlier proposal discussed by the XML Schema WG
in October.  

To respond (belatedly) to comment #5: yes, I think what you describe
is the way the identity and equality of dateTime values are intended
to be used.  (Or at least: one of the ways.)
Comment 7 C. M. Sperberg-McQueen 2008-12-22 15:53:50 UTC
The wording proposal mention in comment 6 was adopted by the XML Schema WG
at its telcon of 19 December 2008, with two amendments:  (1) the new datatype
is named "dateTimeStamp" instead of "timezonedDateTime", and (2) the new
facet is named "explicitTimezone" instead of "explicitOffset".  An editorial
change to the usage note about time zones and zone offsets has also been
made.  The changes are reflected in the current status-quo proposal at 

  http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.html
  (member-only link)

Accordingly, I'm marking this issue resolved.

Dr. Patel-Schneider, we would be grateful if you could examine either the 
change proposal or the current status-quo text on behalf of the OWL WG 
and either (a) confirm that they resolve the issue to the WG's satisfaction, 
by changing the status of the issue to CLOSED, or (b) indicate they they 
do not, by changing the status to REOPENED and telling us what is wrong.
Thank you.
Comment 8 Peter F. Patel-Schneider 2009-01-07 14:17:48 UTC
I expect that this is fine, but I will have to get concurrence from the OWL WG (which should be forthcoming shortly).

peter