Commit eeaccfa
committed
glossary: Make objects explicitly unordered and forbid duplicate names
Pin down our JSON definition to a particular RFC (which we can
explicitly bump if neccessary), instead of referencing the floating
JSON homepage.
Explicitly make objects unordered and forbid duplicate names to avoid
relying on unportable behavior. RFC 7159 is a bit more relaxed [1]:
The names within an object SHOULD be unique.
but warns [1]:
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. When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the
object, and some implementations report all of the name/value pairs,
including duplicates.
The RFC also warns about order portability [1]:
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.
And has some (informative?) language about entries being unordered
[2]:
An object is an unordered collection of zero or more name/value
pairs...
[1]: https://tools.ietf.org/html/rfc7159#section-4
[2]: https://tools.ietf.org/html/rfc7159#section-1
Signed-off-by: W. Trevor King <[email protected]>1 parent 1c7c27d commit eeaccfa
1 file changed
+3
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
20 | 20 | | |
21 | 21 | | |
22 | 22 | | |
| 23 | + | |
| 24 | + | |
23 | 25 | | |
24 | 26 | | |
25 | 27 | | |
| |||
31 | 33 | | |
32 | 34 | | |
33 | 35 | | |
34 | | - | |
| 36 | + | |
35 | 37 | | |
36 | 38 | | |
0 commit comments