This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.)
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)
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?
(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.
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.)
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.)
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.
I expect that this is fine, but I will have to get concurrence from the OWL WG (which should be forthcoming shortly). peter