The I-JSON Message Format

#1

Post by pjvds » Mon, Mar 23, 2015, 7:28 AM UTC

Re: The I-JSON Message Format

#2

Post by atonse » Mon, Mar 23, 2015, 2:12 PM UTC

For a lot of the tips (don't repeat keys, use ISO8601 dates), most JSON libraries should follow these conventions. So as long as you aren't hand-generating your JSON, you'd need to do very little work to conform to these guidelines.

Re: The I-JSON Message Format

#3

Post by rdebeasi » Mon, Mar 23, 2015, 2:41 PM UTC

I'd love to see someone fork https://github.com/arc90/jsonlintdotcom and add an option for I-JSON validation.

[edit] Actually, it looks like the guts of this tool live here: https://github.com/zaach/jsonlint

Re: The I-JSON Message Format

#4

Post by thom_nic » Mon, Mar 23, 2015, 2:55 PM UTC

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it.

Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization.

Unfortunately from what I can tell, I-JSON doesn't appear to solve this problem (or does it??) One nice thing about BSON is they made Date types first class citizens of the format.

Re: The I-JSON Message Format

#5

Post by pjungwir » Mon, Mar 23, 2015, 2:55 PM UTC

I'm surprised to see nothing about formatting dates, which in my experience is the worst interop issue with JSON. I'm glad people are working on this though---thank you!

Re: The I-JSON Message Format

#6

Post by zdw » Mon, Mar 23, 2015, 3:00 PM UTC

atonse wrote: post #2

For a lot of the tips (don't repeat keys, use ISO8601 dates), most JSON libraries should follow these conventions. So as long as you aren't hand-generating your JSON, you'd need to do very little work to conform to these guidelines.

More specifically, RFC3339 dates, which are ISO8601 with a lot of extraneous cruft (week of year? really?) removed.

Re: The I-JSON Message Format

#7

Post by kjhughes » Mon, Mar 23, 2015, 3:09 PM UTC

pjungwir wrote: post #5

I'm surprised to see nothing about formatting dates, which in my experience is the worst interop issue with JSON. I'm glad people are working on this though---thank you!

Dates and times are covered:

   4.3.  Time and Date Handling

   Protocols often contain data items that are designed to contain
   timestamps or time durations.  It is RECOMMENDED that all such data
   items be expressed as string values in ISO 8601 format, as specified
   in [RFC3339], with the additional restrictions that uppercase rather
   than lowercase letters be used, that the timezone be included not
   defaulted, and that optional trailing seconds be included even when
   their value is "00".  It is also RECOMMENDED that all data items
   containing time durations conform to the "duration" production in
   Appendix A of RFC 3339, with the same additional restrictions.

Re: The I-JSON Message Format

#8

Post by kjhughes » Mon, Mar 23, 2015, 3:21 PM UTC

thom_nic wrote: post #4

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it. Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization. Unfortunately from what I can…

One might wish for a strict requirement for date formats for better interoperability, but at least I-JSON recommends something: ISO 8601 [per RFC3339] (with additional restrictions - see section 4.3 which I've quoted elsewhere on this page).

Re: The I-JSON Message Format

#9

Post by huherto » Mon, Mar 23, 2015, 3:24 PM UTC

kjhughes wrote: post #8

thom_nic wrote: post #4

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it. Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization. Unfortunately from what I can…

One might wish for a strict requirement for date formats for better interoperability, but at least I-JSON recommends something: ISO 8601 [per RFC3339] (with additional restrictions - see section 4.3 which I've quoted elsewhere on this page).

Relevant. https://xkcd.com/1179/

Re: The I-JSON Message Format

#10

Post by btown » Mon, Mar 23, 2015, 3:29 PM UTC

kjhughes wrote: post #7

pjungwir wrote: post #5

I'm surprised to see nothing about formatting dates, which in my experience is the worst interop issue with JSON. I'm glad people are working on this though---thank you!

Dates and times are covered: 4.3. Time and Date Handling Protocols often contain data items that are designed to contain timestamps or time durations. It is RECOMMENDED that all such data items be expressed as string values in ISO 8601 format, as specified in [RFC3339], with the additional restrictions that uppercase rather than lowercase letters be used, that the timezone be included not defaulted, and that optional…

For what it's worth, Salesforce even conforms to ISO 8601 internally. So, you know, if you're trying to develop agile tools for translating between JSON and Salesforce API records, then, um, things should just work...

takes a brief moment to contemplate the reality of his existence

The flip side of this is that if you're not using ISO 8601 in your JSON, you're doing worse than Salesforce. That's about as good of an incentive I can give this community to try to standardize their organizations around this standard!