Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re^4: Outputting JSON with sorted names/keys

by afoken (Canon)
on Jan 27, 2020 at 08:09 UTC ( #11111919=note: print w/replies, xml ) Need Help??

in reply to Re^3: Outputting JSON with sorted names/keys
in thread Outputting JSON with sorted names/keys

what I remember were two contradictory RFC's but I can't find the discussion anymore.

JSON has several RFCs:

Regarding objects, 4627 is quite short. The introduction defines them as "unordered collection", and the grammer states that the "names within an object SHOULD be unique."

7158 keeps the definition as "unordered collection" in the introduction, and keeps the requirement that the "names within an object SHOULD be unique", but adds observations of existing implementations regarding duplicate names, and observations of existing implementations regarding member ordering. It also adds a change log.

7159 is nearly identical to 7158, except for the copyright date. It has only a change log comparing to 4627.

8259 is a reworked revision of 7159, but the introduction still defines objects as "unordered collection". The object definition is completely unchanged, it has just been moved down so that it now crosses a page boundary. The changelog compares to 7159. 8259 also links to ECMA-404, the ECMA version of the JSON specification.

ECMA-404, second edition, explicitly states that the "JSON syntax specified by this specification and by RFC 8259 are intended to be identical." Syntax graphs and large parts of the text seem to be copied from The introduction does not specify objects as "unordered collection", instead just as "collections of name/value pairs". But chapter 6 differs from the RFCs: "The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange."

The "historic" first edition of ECMA-404 did not contain that text in chapter 6.

So ECMA-404, 2nd edition, allows duplicate keys that should be avoided according to the RFCs, and it allows implementations to assume that objects are ordered collections.

Great. ECMA-404, 2nd edition, defines something different than RFC-8259 and the 1st editition of ECMA-404.


Forgot this one from JSON "is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999".

The link on the website is broken, but the 3rd Edition can still be found on the "historical edititons" ECMA page.

4.3.3 defines "An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function. A function stored in a property of an object is called a method." JSON explicitly has no functions, so we can safely ignore the function/method part.

8.6 repeats: "An Object is an unordered collection of properties. Each property consists of a name, a value and a set of attributes." JSON has no attributes, so we only have to consider name and value. JSON also has no internal properties.

Everything else, especially name handling, is specified in pseudo-code. Technically, the code implementing Javascript's objects could have special cases to allow sorted keys and non-unique keys. But the definitions for [[Get]], [[Put]], [[CanPut]], [[HasProperty]], and [[Delete]] in 8.6.2 all treat the PropertyName argument as unique. So, in ECMA-262 3rd Edition, object keys are unique. And that matches what we see in Javascript.


Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
  • Comment on Re^4: Outputting JSON with sorted names/keys

Replies are listed 'Best First'.
Re^5: Outputting JSON with sorted names/keys
by LanX (Archbishop) on Jan 27, 2020 at 09:33 UTC
    Thanks for tracking it down. :)

    I think of it like of Perl code without strict and warnings . They are recommended but not obligatory.

    See also the definition of SHOULD:

    > Key words for use in RFCs to Indicate Requirement Levels

    3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11111919]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2020-06-07 10:56 GMT
Find Nodes?
    Voting Booth?
    Do you really want to know if there is extraterrestrial life?

    Results (42 votes). Check out past polls.