Re: An approach to xsd:dateTime

Everyone seems to agree that dealing with literals with missing  
timezones is a problem because we don't know how to map them onto the  
timeline. Everyone also seems to agree that there is no one  
"recovery" strategy that is appropriate in all cases -- default time  
zones and intervals both have serious problems in some contexts.  
Therefore, we can't *specify* the recovery strategy because then we  
will be *forcing* compliant tools to do the wrong thing in some  
situations. The only remaining choice is whether we make it mandatory  
or optional to take *some* recovery action. It would seem strange to  
me to *demand* that tools perform some recovery action without  
specifying what it is. By a process of elimination, this does seem to  
lead us back to the formulation mentioned by Peter below, i.e., tools  
*may* try to recover. We can argue as to whether they *should* issue  
a warning, but this is normally the case when some recovery action is  
taken.

Ian


On 28 Jul 2008, at 19:56, Peter F. Patel-Schneider wrote:

>
> From: "Jie Bao" <baojie@cs.rpi.edu>
> Subject: Re: An approach to xsd:dateTime
> Date: Mon, 28 Jul 2008 14:45:09 -0400
>
>>
>> On Mon, Jul 28, 2008 at 2:17 PM, Bijan Parsia  
>> <bparsia@cs.man.ac.uk> wrote:
>>> On 28 Jul 2008, at 19:02, Jie Bao wrote:
>>>>
>>>> To explain a bit more for my objection to the proposal at the F2F3:
>>>>
>>>> "PROPOSAL: datetime literals with missing timezones are not in the
>>>> syntax; tools MAY insert a timezone, but SHOULD produce a  
>>>> warning if
>>>> they do so"
>>>>
>>>> The part I object is that missing timezone should be disallowed  
>>>> from
>>>> the syntax. In many cases, a time zone is a default context, and as
>>>> default contexts typically behave, it may be omitted from a
>>>> description from this context. Tools may or may not be able to
>>>> rediscover a missing zone.
>>>
>>> Yes. That's part of the point. We can't guess reasoanble ones.
>>>
>>>> The burden should not be on users to always
>>>> provide such information.
>>>
>>> Who else?
>>
>> Tools may help in two ways: if such information can be rediscovered,
>> then add it. If there is no way to find it precisely, then give it a
>> *reasonable* interpretation.
>
> This seems to me to be precisely the proposal that was voted on just
> before lunch.  Tools MAY recover the information, if there is any  
> doubt
> they provide a warning, but MAY also put in a reasonable answer, in
> which case they SHOULD provide a warning.
>
> peter
>

Received on Tuesday, 29 July 2008 10:26:44 UTC