W3C home > Mailing lists > Public > public-rdf-comments@w3.org > August 2012

Re: Encouraging canonical serializations of datatypes in RDF

From: Steve Harris <steve.harris@garlik.com>
Date: Wed, 1 Aug 2012 23:34:42 +0100
Message-Id: <3189DE91-B862-41AD-84AA-CE94FB6971F8@garlik.com>
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
To: David Booth <david@dbooth.org>
On 1 Aug 2012, at 18:49, David Booth <david@dbooth.org> wrote:

> On Wed, 2012-08-01 at 17:56 +0100, Steve Harris wrote:
>> On 2012-08-01, at 17:09, David Booth wrote:
>> 
>>> On Wed, 2012-08-01 at 10:10 -0400, Peter F. Patel-Schneider wrote:
>>>> OK, both use cases are acknowledged.
>>>> 
>>>> Given that there is a use case where the time zone is important, how can 
>>>> suggesting only using Z when timezone is not important be any help to 
>>>> application writers?
>>> 
>>> Because using a fixed Z timezone simplifies applications for which
>>> xsd:datetime is only used to unambiguously encode a point in time -- not
>>> also a location.  Again, different applications have different needs. 
>>> 
>>> Just because this will not help *all* applications does not mean that it
>>> won't help *some* applications.  
>> 
>> It *might* help some applications (ones that don't have a
>> xsd:dateTime / ISO 8601 library, which should hopefully be rare), but
>> it will prevent others from working at all. That doesn't seem like a
>> good idea to me.
> 
> Whoa!  Not true at all.  Again, I am *not* saying that a fixed Z
> timezone should be used for *all* data.  Clearly in your use case where
> timezone provenance is needed, a fixed Z timezone should *not* be used.
> Nothing changes that.  The apps will still work fine.

How is the store to know the intent of the consumer? An xsd:dateTime is what it is. If there was a function to normalise the timezone (where that's possible) then fine, but that doesn't seem to be what you're asking for. 

>>> The more we can make RDF manipulable by simple tools as often as
>>> possible the better, even if it cannot be done 100% of the time.
>> 
>> I agree, but I don't think this change would do that. It would move
>> RDF further from XML, and make it very hard to use is some common
>> situations.
> 
> Can you explain?  Exactly how would encouraging the use of a canonical
> form of an XML data type when appropriate move RDF further from XML?

You're talking about changing the recommended behaviour of one of the XML data types, when used in RDF. 

> And exactly how would a canonical form be harder to consume in *any*
> situation?

A new, non-standard canonicalisation, just for RDF? Which is a lossy transform? Surely that's harder to consume (in the general case).
> 


- Steve
Received on Wednesday, 1 August 2012 22:35:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:53 UTC