It's great to see this! We've been bitten by JSON allowing arbitrarily large numbers at Snowplow. This is what a JSON Schema trying to enforce sensible (int64) numeric limits ends up looking like: https://github.com/snowplow/iglu-central/blob/master/schemas...
The I-JSON Message Format
11–20 of 46 posts
Re: The I-JSON Message Format
#12Lack 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).
Yes, conformance to a single string representation of a datetime is nice. Unfortunately that still doesn't help the issue when deserializing, you're just going to get a string that needs to be manually converted to a Date object.
Re: The I-JSON Message Format
#13Earlier quoted context omitted.
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 i…
I'm really surprised there's still a lot of people out there that don't use ISO 8601, I haven't used anything but for nearly a decade :/
Re: The I-JSON Message Format
#14I've run into the date formatting issue that others are mentioning, and just this weekend I discovered the hard way that the V8 JSON parser does not correctly parse the following hierarchy:
object --> array --> object --> array
I must have spent a few hours trying to figure out why Angular wasn't iterating through the first array, only to discover that it was being parsed like so:
object --> object --> object --> object
Re: The I-JSON Message Format
#15I've run into the date formatting issue that others are mentioning, and just this weekend I discovered the hard way that the V8 JSON parser does not correctly parse the following hierarchy: object --> array --> object --> array I must have spent a few hours trying to figure out why Angular wasn't iterating through the first array, only to discover that it was being parsed like so: object --> object --> object --> obj…
I couldn't repo this. What am I missing?
Re: The I-JSON Message Format
#16I've run into the date formatting issue that others are mentioning, and just this weekend I discovered the hard way that the V8 JSON parser does not correctly parse the following hierarchy: object --> array --> object --> array I must have spent a few hours trying to figure out why Angular wasn't iterating through the first array, only to discover that it was being parsed like so: object --> object --> object --> obj…
That does not seem plausible. That would break a million different things. Are you sure you're interpreting your results correctly? Do you have a test case you can share?
Re: The I-JSON Message Format
#17To me, I know of Tim Bray because of XML.
Re: The I-JSON Message Format
#18If the author of this RFC is still doing edits, I think it might be worth mentioning in section 4.2 "Must-Ignore Policy" something along the lines of,
An I-JSON implementation supporting a "Must-Ignore" policy SHOULD pass any such new protocol elements on, untouched, to any downstream consumers of the message, because those downstream consumers may understand the new elements.
Re: The I-JSON Message Format
#19Earlier quoted context omitted.
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/
I love it. When I first started in IT (1994, don't ask...) working with London and Tokyo and San Fran and Singapore and everyone wrote dates differently. I just started writing YYYY-MM-DD everywhere, and all of the questions went away.
Re: The I-JSON Message Format
#20Lack 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…
Dunno, I always liked storing date/time as epoch. Every language under the sun seems to have a native method for working with it. Yeah, I need to deal with de/serialization, but it is a small price to pay, no?