Subject: [Tzdist] #11 JSON shema

From: Daniel Migault <[email-masked]>
Date: Tue, 9 Sep 2014 11:13:43 +0200

Dear Friends and Colleagues,

We would like to get your opinion on how to represent JSON data. This is
related to issue 11.

BR,
Daniel

http://trac.tools.ietf.org/wg/tzdist/trac/ticket/11

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Tue, 09 Sep 2014 12:10:14 +0100

> http://trac.tools.ietf.org/wg/tzdist/trac/ticket/11

What IS the status of the draft-newton-json-content-rules since I seee
that a new draft was posted after this ticket was raised?

I think that in the absence of anything else then it is worth sticking
with this unless there are some practical reason as to why it should not
be used?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 9 Sep 2014 14:37:39 +0200

1)
https://datatracker.ietf.org/wg/tzdist/charter/

Quote: "The protocol must scale to vast numbers of
clients, such as the potential "internet of things" devices, as well as
to today's desktop computers and servers."

Quote: "The time zone data distribution protocol will initially be targeted at
iCalendar-based clients,"

2)
http://www.ietf.org/mail-archive/web/tzdist/current/msg00266.html
Proposal to use iCalendar format as basis for field definitions

Maybe at first define what JSON content will NOT exist in iCalendar
format and provide justification for that.

Otherwise any JSON definitions look like duplication of things being
said elsewhere which makes implementation harder, as has been seen
with jCal, which uses prose to describe a transformation from iCal, as
did xCal already.

Also I don't see a justification why JSON should be preferred about
other data formats, e.g. XML. Not defining a XML representation makes
tzdist less usable for many. There exist a lot of tools for XML
validation, and tzdist could take advantage of these and of the
expertise that users have with XML:

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com/