Re: a new dateTime/timezone design, with datatypes

On Thu, 15 Apr 2004, Dan Connolly wrote:

>
>On Thu, 2004-04-15 at 11:43, Charles McCathieNevile wrote:
>> On Wed, 14 Apr 2004, Dan Connolly wrote:
>>
>> >
>> >Summary: my discomfort with our timezone design motivated
>> >me to implement a new one. Who likes it? Who dislikes it?
>>
>> I like it a lot.
>
>I actually found a problem with it when working out my
>AMS itinerary: cwm doesn't substitute into the datatype
>part of a literal.

you mean you can't write an n3 rule that looks like :foo^^?x

This is a problem with using cwm (admittedly, since that seems to be your
tool of preference, and given our focus on real world tools, that makes it a
potentially serious problem). Maybe I have mis-characterised it. But if you
use a longhand version with rdf:datatype as a property does the problem go
away?

>So I'm still considering some variations.
>
>> What is the actual impact on existing content?
>
>For one thing, the XPath expression you'd use to get
>at the YYYY-MM-DD string from a Vevent is different, I think.

The diff you provided suggests that we could live with two ways of encoding
the data with two slightly different Xpaths for extracting them, but I am not
sure if they need to actually conflict in terms of rendering each other
invalid automatically. If we have old rules and new rules (a deprecated way
of declaring a date...) that can live side by side that seems to be better
than something that just breaks down.

As with the geo: case it seems to me better to have something where we can
automagically convert successfully for real cases, and then we can see if
there are problems with that (beyond the potential divergence if tools don't
converge towards one way or another, and I suggest the new way 'cause it
solves problems that were there when using the old way).

Is this reasonable (or is it too late at night for me?)

Anyway, good night...

chaals

Received on Thursday, 15 April 2004 13:05:17 UTC