It links to several RFCs. RFC-7158 and RFC-7159 differ only in (a) that one is RFC-7158 and the other is RFC-7159 (b) that one is dated in March 2013 and the other is March 2014 (c) that one obsoletes RFC-7158 in addition to RFC-4627 which they both obsolete. It appears that 7159 was pushed only to handle an error in the dating of 7158, given that the irrelevant RFC-7157 is dated March 2014.
So to say that there's more that five incompatible specs is just a cruel disregard of the facts. No implementation can differ in its parsing of a text based on the metadata of the spec. There needs to be a substantive difference in the spec.
As to the current RFC 8259, it makes no substantial differences from the previous version. There are a few typos that have been fixed ("though" becoming "through", when "though" was not a possible interpretation). It eliminates the obligation to parse public texts not coded in UTF-8. Previously, documents SHALL be UTF-8 - that's barely a change, but it is a change. It has specified more concretely its relationship with ECMA-404. It's possible that someone reading earlier RFCs would have concluded "a valid RFC 7159 json parser can parse and only the documents produced by ECMA-404". If there were any discrepancies between ECMA-404 and RFC-7159, therefore, an interpretation along these lines would lead a person to conclude you cannot parse a document according to RFC-7159, so the spec doesn't really count as an incompatible spec. Under the current spec, it identifies that there are possible discrepancies, and RFC-8259 is intended to accept fewer documents that ECMA-404.
The first RFC did not permit the json documents "true", "false" and "null", accepting only json documents that comprise an object or an array. It permitted any Unicode encoding, defaulting to UTF-8, and non-Unicode encodings as well (so a Latin-1 document is valid RFC-4627, but not valid RFC-7158+). It also included some incorrect statements about its relationship to javascript. These were reduced in later versions and eventually eliminated. They do not affect the specification of the language, but merely how you may handle data in the language.
No document that is accepted by the current RFC will be rejected by any RFC other than the first. The only such documents to be rejected by the first are those which consist entirely of "true", "false", or "null". No UTF-8 document that is accepted by the first RFC will be rejected by subsequent RFC parsers, unless a person reads a paragraph called "security considerations" that says "you can kinda do this but it's insecure" as somehow trumping the clear statements of the grammar in earlier sections.
I have not investigated the other specs and I probably won't. But the idea that there are 6 incompatible specs is false. There is not more than 5, and it is almost trivial to accept documents according to 3 of 5 or 4 of 6 specs at once by ignoring the restrictions on character coding.
> It links to several RFCs. RFC-7158 and RFC-7159 differ only in (a) that one is RFC-7158 and the other is RFC-7159 (b) that one is dated in March 2013 and the other is March 2014 (c) that one obsoletes RFC-7158 in addition to RFC-4627 which they both obsolete. It appears that 7159 was pushed only to handle an error in the dating of 7158, given that the irrelevant RFC-7157 is dated March 2014.
"they only differ in", yeah, indeed.
Dude. We all have work to do and grappling with some obscure JSON parsing corner is the last thing we need in our workday. This applies to 95% of commercial programmers, I am willing to bet.
What you described does sound simple and small in isolation. Now multiply it by 50 and see how "they only differ in" is a problem that must not be allowed in the first place.
Where's the-one-and-only JSON spec? Why no organisation has the courage to step forward and standardise it once and for all?
Given the current realities, just cut your very small and ignorable losses by losing those obscure JSON parsing corners and let people describe JSON simply as:
"RFC #ABCD".
That's it. Nothing else. Only that. Everything is contained in it.
Complexity compounds and makes everything non-deterministic. We should stop allowing that.
It links to several RFCs. RFC-7158 and RFC-7159 differ only in (a) that one is RFC-7158 and the other is RFC-7159 (b) that one is dated in March 2013 and the other is March 2014 (c) that one obsoletes RFC-7158 in addition to RFC-4627 which they both obsolete. It appears that 7159 was pushed only to handle an error in the dating of 7158, given that the irrelevant RFC-7157 is dated March 2014.
So to say that there's more that five incompatible specs is just a cruel disregard of the facts. No implementation can differ in its parsing of a text based on the metadata of the spec. There needs to be a substantive difference in the spec.
As to the current RFC 8259, it makes no substantial differences from the previous version. There are a few typos that have been fixed ("though" becoming "through", when "though" was not a possible interpretation). It eliminates the obligation to parse public texts not coded in UTF-8. Previously, documents SHALL be UTF-8 - that's barely a change, but it is a change. It has specified more concretely its relationship with ECMA-404. It's possible that someone reading earlier RFCs would have concluded "a valid RFC 7159 json parser can parse and only the documents produced by ECMA-404". If there were any discrepancies between ECMA-404 and RFC-7159, therefore, an interpretation along these lines would lead a person to conclude you cannot parse a document according to RFC-7159, so the spec doesn't really count as an incompatible spec. Under the current spec, it identifies that there are possible discrepancies, and RFC-8259 is intended to accept fewer documents that ECMA-404.
The first RFC did not permit the json documents "true", "false" and "null", accepting only json documents that comprise an object or an array. It permitted any Unicode encoding, defaulting to UTF-8, and non-Unicode encodings as well (so a Latin-1 document is valid RFC-4627, but not valid RFC-7158+). It also included some incorrect statements about its relationship to javascript. These were reduced in later versions and eventually eliminated. They do not affect the specification of the language, but merely how you may handle data in the language.
No document that is accepted by the current RFC will be rejected by any RFC other than the first. The only such documents to be rejected by the first are those which consist entirely of "true", "false", or "null". No UTF-8 document that is accepted by the first RFC will be rejected by subsequent RFC parsers, unless a person reads a paragraph called "security considerations" that says "you can kinda do this but it's insecure" as somehow trumping the clear statements of the grammar in earlier sections.
I have not investigated the other specs and I probably won't. But the idea that there are 6 incompatible specs is false. There is not more than 5, and it is almost trivial to accept documents according to 3 of 5 or 4 of 6 specs at once by ignoring the restrictions on character coding.