4 ms·

I would like to comment that "there is a discrepancy between the Javascript JSON parser (used in validation scripts) and the one used internally by CouchDB [...

by nolok 9y ago

I would like to comment that "there is a discrepancy between the Javascript JSON parser (used in validation scripts) and the one used internally by CouchDB [...] For a given key, the Erlang parser will store both values, but the Javascript parser will only store the last one" should probably read "the Erland parser is wrong". I'm not saying what javascript does is smart, or the right way, or anything like that, but JSON is defined specifically as "a subset of Javascript", as such I find it normal to expect that javascript rules applies. Of course, one could argue that a key being defined twice is undefined behavior (is it ? I admit to not reading the javascript specs) and thus "what the js implementations actually do" isn't a reference.

Zalastax 9y ago
He links to a stack overflow question and I think this answer is pretty good https://stackoverflow.com/a/23195243/497116 https://stackoverflow.com/a/23195243/497116. https://www.ietf.org/rfc/rfc4627.txt https://www.ietf.org/rfc/rfc4627.txt says "The names within an object SHOULD be unique". https://tools.ietf.org/html/rfc7159 https://tools.ietf.org/html/rfc7159 is more lax and instead says "An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings". It's unfortunate that the correct behavior is not agreed on and today we saw the consequences of that.
- sratner 9y ago
  From https://www.ecma-international.org/ecma-262/5.1/#sec-15.12 https://www.ecma-international.org/ecma-262/5.1/#sec-15.12 -- "NOTE: In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten."
  - Zalastax 9y ago
    Yes, a good point! For interoperability it would be best if everyone followed the ECMA standard for JSON from 2011. It seems like they forgot to even mention duplicate keys in ECMA-404 from 2013 which seems very strange. RFC7159 uses the word SHOULD but I don't think the JSON parser Jiffy has actually understood the full implications and carefully weighed before choosing to allow duplicate elements.

by nolok 9y ago

Zalastax 9y ago

He links to a stack overflow question and I think this answer is pretty good https://stackoverflow.com/a/23195243/497116 https://stackoverflow.com/a/23195243/497116. https://www.ietf.org/rfc/rfc4627.txt https://www.ietf.org/rfc/rfc4627.txt says "The names within an object SHOULD be unique". https://tools.ietf.org/html/rfc7159 https://tools.ietf.org/html/rfc7159 is more lax and instead says "An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings". It's unfortunate that the correct behavior is not agreed on and today we saw the consequences of that.

sratner 9y ago
From https://www.ecma-international.org/ecma-262/5.1/#sec-15.12 https://www.ecma-international.org/ecma-262/5.1/#sec-15.12 -- "NOTE: In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten."
- Zalastax 9y ago
  Yes, a good point! For interoperability it would be best if everyone followed the ECMA standard for JSON from 2011. It seems like they forgot to even mention duplicate keys in ECMA-404 from 2013 which seems very strange. RFC7159 uses the word SHOULD but I don't think the JSON parser Jiffy has actually understood the full implications and carefully weighed before choosing to allow duplicate elements.