Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The I-JSON Message Format

tbray.org

Post reply on HN
Print view View original

31–40 of 46 posts

Re: The I-JSON Message Format

#31

Post by deeviant »

nly wrote: post #28

Kind of a bummer that nothing was suggested wrt tightening the number grammar. "99" and "99e0" are both valid serializations of 99, and "0e7" and "0" of zero. JSON also allows arbitrary trailing and leading 0s in the fraction and exponent, respectively. Personally I don't know why for instance "0.0" can't be the only valid interpretation of a double 0 and "0" be the only valid interpretation of an integer 0. In fact,…

Schemas are anything but a free lunch.

It has been said that the limit of the ratio of (creating, groking, interacting with) the hundreds to thousands of XML schemas/documents that invariably creep up in the average large-scale-XML-using enterprise environment versus (doing actual work) increases without bound as t goes to infinity.

Re: The I-JSON Message Format

#32

Post by pjungwir »

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…

Oh that's great! It looks like the HTML version of his link doesn't have any subsections under section 4:

http://rfc7159.net/rfc7159

but the plaintext version does:

http://www.rfc-editor.org/rfc/rfc7493.txt

Maybe the document is still in flux and the text version represents a later addition?

EDIT: Oops, my first link is to the original JSON spec. Sorry for the confusion!

Re: The I-JSON Message Format

#33

Post by drudru11 »

brianolson wrote: post #24

See also RFC 7049 "Concise Binary Object Representation" (CBOR), a 'binary JSON' http://tools.ietf.org/html/rfc7049 http://cbor.io/ Faster, smaller, pretty sure it will parse on the other end.

very cool - I haven't heard of this before. It looks like it resolves a lot of the issues I have with JSON.

Re: The I-JSON Message Format

#34

Post by KaiserPro »

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…

but its only "recommended" which means it can not adhere to this, and still be compliant. It seems a bit pointless to make a new spec and not enforce one of the main things that trip people up.

Re: The I-JSON Message Format

#35

Post by stouset »

thom_nic wrote: post #25
tomchristie wrote: post #21

Earlier quoted context omitted.

> I-JSON doesn't appear to solve this problem It's not within the scope of what I-JSON is intended to address. This is a more formally specified and slightly more constrained variation of the existing JSON spec. Adding new datatypes would mean that it would no longer be JSON.

I'll agree there aren't many ways this could be solved without breaking compatibility with JSON. Certainly something like {"created": Date("2013-12-1T12:00:00Z")} a la BSON seems elegant but is incompatible with JSON. Maybe something like "String values that match (some computationally inexpensive ISO-8601-matching regex) shall be converted to Date instances by the JSON parser" could be possible without huge compatib…

No, definitely don't do that. You're just trading one set of small annoyances for a huge set of unpredictable problems.

Re: The I-JSON Message Format

#36

Post by pdw »

pimlottc wrote: post #27
deitcher wrote: post #20

Earlier quoted context omitted.

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?

Epochs don't tell you what time zone you're working with and they aren't very easy to read/debug at a glance.

Another annoyance is seconds since epoch (traditional Unix) vs milliseconds since epoch (e.g. Java).

Re: The I-JSON Message Format

#37

Post by jameshart »

deitcher wrote: post #29
pimlottc wrote: post #27

Earlier quoted context omitted.

Epochs don't tell you what time zone you're working with and they aren't very easy to read/debug at a glance.

Fair enough @pimlottc. But most of the time I am far more concerned with accurately capturing a moment in time than I am with making it instantly readable. I also have helped some companies that ran into serious datetime management issues when they worked with strings that led engineers to assume a certain timezone, others to assume others, and chaos ensued. Epochs may not be instantly readable, but they do force eve…

So by epoch, obviously you mean the number of seconds since Jan 1 1970. Midnight - 00:00, right? Ah... but then... UTC? or TAI? There's a 35 second difference, after all. There's a school of thought that the UNIX epoch counts from 1970-01-01 00:00:10 TAI...

Re: The I-JSON Message Format

#38

Post by jerf »

nly wrote: post #28

Kind of a bummer that nothing was suggested wrt tightening the number grammar. "99" and "99e0" are both valid serializations of 99, and "0e7" and "0" of zero. JSON also allows arbitrary trailing and leading 0s in the fraction and exponent, respectively. Personally I don't know why for instance "0.0" can't be the only valid interpretation of a double 0 and "0" be the only valid interpretation of an integer 0. In fact,…

"In fact, why can't all floats that are ambiguous wrt an integer interpretation have a ".0" tail?"

In JavaScript Object Notation, everything's a float. There are no integers, just floats that happen to not have any fractional elements.

Numbers are the weakest part of the JSON spec in general because Javascript has very weak numbers. A spec merely intending to tidy up certain questionable corners hasn't really got license to "fix" the numbers problem.

(And just to make it clear one more time, I fully agree that the numbers are really problematic in JSON... I just don't think that problem can be fixed here. It would take a JSON 2.)

Re: The I-JSON Message Format

#39

Post by smoyer »

deitcher wrote: post #19
huherto wrote: post #9

Earlier quoted context omitted.

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.

Looks like ISO-8601 to me! We've standardized on using this format (extended to include time where necessary) whenever our JSON objects include a date or date/time. We've also standardized on UTC. Since our system clocks are already synchronized that way, it's easy for us and we simply i18n/l12n them on entry and/or display.

Re: The I-JSON Message Format

#40

Post by nknighthb »

jameshart wrote: post #37
deitcher wrote: post #29

Earlier quoted context omitted.

Fair enough @pimlottc. But most of the time I am far more concerned with accurately capturing a moment in time than I am with making it instantly readable. I also have helped some companies that ran into serious datetime management issues when they worked with strings that led engineers to assume a certain timezone, others to assume others, and chaos ensued. Epochs may not be instantly readable, but they do force eve…

So by epoch, obviously you mean the number of seconds since Jan 1 1970. Midnight - 00:00, right? Ah... but then... UTC? or TAI? There's a 35 second difference, after all. There's a school of thought that the UNIX epoch counts from 1970-01-01 00:00:10 TAI...

POSIX specifies the Epoch to be UTC and has since at least 2001. People may have other opinions on how it should be specified, but if you're going to follow POSIX as it exists, you're not left with a choice in the matter.

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...

Post reply on HN