4 ms·
The other spec (ECMA-404) disagrees with RFC 7159 on this point. That's the great thing about specs -- if you don't like what one says, there's always another
by gmfawcett 6y ago
The other spec (ECMA-404) disagrees with RFC 7159 on this point.
That's the great thing about specs -- if you don't like what one says, there's always another to support your position. :)
- Latty 6y agoWell, falling back to the pragmatist position: a lot of JSON tooling assumes the order isn't relevant semantically. Not taking that position will cause you a lot of headaches.
- gmfawcett 6y agoAgreed, and if you want to write tools that are conformant with both specs, you really don't have a choice. The RFC pretty much spells out this point: "JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences." (This kind of text is why I prefer the ECMA document -- it's clearly written to be a normative standard, rather than as a field-report and Request for Comments.)
- stickfigure 6y ago...and a lot of other tooling assumes the order is relevant. Quite a lot of application logic in the real world, too. Which is why browsers preserve iteration order. JSON is a serialization format. Its components inherently have a serial order. You can't change this any more than you can legislate the value of pi to be 3.
- gmfawcett 6y agoNitpicking, but JSON was designed as a data-interchange format, it only happens to be used for serialization. I agree that any kind of pipeline component (i.e., not a source, and not a sink) should preserve ordering where possible, for the sake of robustness.
- stickfigure 6y agoJSON is defined (and has always been) as a serial stream of characters. I think it's fair to call that serialization.
- gmfawcett 6y agoI'm not disagreeing that JSON is used for data serialization, but your last comment just muddies the waters. There are plenty of things that are serial in nature, but have nothing to do with "serialization" in the sense of data marshalling. I guess that the term is kind of unfortunate. Consider just how how many data formats are ultimately defined as a "serial stream of characters" -- and then consider how few of those you would practically use for marshalling a general data structure.
- mywittyname 6y agoWell, you, as a programmer, can make the assumption that anyone creating JSON for consumption by your program will obey this requirement. Generally speaking, it's not a good idea to make that assumption, because even people within your team or company may not know of that rule or expect it to be enforced and may break it. Also, there's the problem of different JSON libraries behaving differently. Such as using unordered hashmaps as an internal data representation for parsed content, making compliance difficult.
- Latty 6y agoSure, but we were talking about being a consumer. In general, I would argue Postel's law: be careful with what you send, be liberal with what you accept. Don't mess with the order yourself, but don't assume other tooling will respect it.
- dragonwriter 6y agoThat ECMA (via ECMA-404) and IETF (via RFC 8259, and before that RFC 7159) have subtly incompatible standards with the same title is annoying; perhaps we need to talk about “IETF JSON” (or “application/json”, as it is expressly the basis of the MIME type) vs “ECMA JSON”.
- gmfawcett 6y agoHere is our opportunity to publish an ANSI or ISO spec, and take the market by storm. :) Personally, I will adopt the first version of JSON that lets me insert a flipping comment!