RFC7159 -> RFC8259
This commit is contained in:
parent
35726436c9
commit
3c7215397d
|
@ -939,14 +939,14 @@ Specifically, JSON does not:
|
|||
In short, JSON syntax doesn't *denote* anything.[^xml-infoset] [^other-formats]
|
||||
|
||||
[^meaning-ieee-double]:
|
||||
[Section 6 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-6)
|
||||
[Section 6 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-6)
|
||||
does go so far as to indicate “good interoperability can be
|
||||
achieved” by imagining that parsers are able reliably to
|
||||
understand the syntax of numbers as denoting an IEEE 754
|
||||
double-precision floating-point value.
|
||||
|
||||
[^string-key-comparison]:
|
||||
[Section 8.3 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-8.3)
|
||||
[Section 8.3 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-8.3)
|
||||
suggests that *if* an implementation compares strings used as
|
||||
object keys “code unit by code unit”, then it will interoperate
|
||||
with *other such implementations*, but neither requires this
|
||||
|
@ -954,12 +954,12 @@ In short, JSON syntax doesn't *denote* anything.[^xml-infoset] [^other-formats]
|
|||
contexts.
|
||||
|
||||
[^json-member-ordering]:
|
||||
[Section 4 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-4)
|
||||
[Section 4 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-4)
|
||||
remarks that “[implementations] differ as to whether or not they
|
||||
make the ordering of object members visible to calling software.”
|
||||
|
||||
[^json-key-uniqueness]:
|
||||
[Section 4 of RFC 7159](https://tools.ietf.org/html/rfc7159#section-4)
|
||||
[Section 4 of RFC 8259](https://tools.ietf.org/html/rfc8259#section-4)
|
||||
is the only place in the specification that mentions the issue. It
|
||||
explicitly sanctions implementations supporting duplicate keys,
|
||||
noting only that “when the names within an object are not unique,
|
||||
|
|
Loading…
Reference in New Issue