Re: An approach to xsd:dateTime

On 25 Jul 2008, at 13:41, Deborah L. McGuinness wrote:

> Bijan Parsia wrote:
>> On 25 Jul 2008, at 12:45, Deborah L. McGuinness wrote:
>>
>>> My applications make heavy use of xsd datetime.
>>> my issue in applications is that i have unpredictable data details.
>>> sometimes i have year, month, day,  (sometimes with and sometimes  
>>> without timezone)
>>> and sometimes i also have hour and minutes (and sometimes even  
>>> seconds) sometimes with and sometimes without timezone.
>>>
>>> so i would NOT support a requirement that all data either does or  
>>> does have a time zone ;
>>> i would support an approach that allows me to have optional  
>>> timezones.
>>
>>
>> Then it seems to me that we need a fairly detailed proposal or  
>> requirements or examples from you. The datetime stuff *quickly*  
>> gets ratholey, esp. from an implementation point of view. If we  
>> are going to include *something* not essentially trivial, we need  
>> active champions.
>>
>> And the real question, I'd wager, is what can we realistically get  
>> interop on. You're probably not much worse off if timezones are a  
>> non-standard extension than if *all* of datetime is a non-standard  
>> extension.
> i agree with both of the points here and have a comment
> a - how do we decide what we can realistically get interoperability  
> on?  is there any current work on xml datatypes with respect to  
> datetime?

We ask implementors. If you have a clear semantics and some  
algorithms for what you want that makes the discussion much more  
grounded. If you have an implementation that helps even more.

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

"""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. 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!

This is a lot of overkill. If one is doing some sophisticated work  
with incomplete date records, it might be (for all I know) better to  
model them in OWL. (Certainly easier on the implementations and  
*might* be better for modeling in some cases.)

> b - yes - having just timezone be a nonstandard extension to  
> datetime is a simpler thing to sell.

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

(Consider the difficulty of reasoning with an absent timezone if  
that's to affect the *identity* of the object. All of a sudden, a  
simple abox assertion is translated into a complex range restriction.  
It would be better, I think, to make absent time zones mean UTC. That  
would be unambiguous, easy to work with, and useful if not in every  
case. Treating missing bits as rounding or truncing could work, but  
then we need a set of rules for that.)

Cheers,
Bijan.

Received on Friday, 25 July 2008 13:02:40 UTC