- From: David Booth <david@dbooth.org>
- Date: Wed, 01 Aug 2012 13:49:03 -0400
- To: Steve Harris <steve.harris@garlik.com>
- Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-rdf-comments@w3.org
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. > > > 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? And exactly how would a canonical form be harder to consume in *any* situation? -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Wednesday, 1 August 2012 17:49:35 UTC