This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We should reference the new JSON specification ECMA-404 http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf This isn't just a matter of changing the bibliography, because we allow parse-json to specify which spec it's dealing with. I don't know of any significant differences in this version.
Because the two specifications are (as far as I can determine) identical, I have simply replaced all references to ECMA-262 with references to ECMA-404, mutatis mutandis.
There is now yet another JSON specification at http://rfc7159.net/rfc7159
See also Tim Bray's blog at https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON explaining the rationale for the new RFC. Since the JSON spec is moving in the direction that other internet specs have followed of containing lots of fuzzy interoperability advice and guidance rather than hard and fast rules, I'm inclined to abandon our attempts to legislate exactly what products should do, and just point them to best practice. It's not our task to write yet another version of the JSON spec.
I think you can also add http://json5.org/ to this list
Does JSON5 have any official backing or community momentum, or is it just one geek who has appropriated the name for his own private project?
The XSL WG agreed today that we will reference rfc7159 normatively; we may also include a non-normative reference to Tim Bray's blog posting. We need to get XQuery WG to agree this is the way forward. We should remove the "spec" option from the relevant functions that allows the user a choice of which specification to use.
The change has been applied.
I understand that we now don't support RFC4627 or ECMA-404 anymore, except as an extension to liberal := yes. Reopening, because there are still a few references left over that refer to the "spec" option, or refer to the old specifications or old syntax. Summarizing: Validate option: "or against an implementation-defined schema if the spec option has the value liberal." should become: "or against an implementation-defined schema if the liberal option has the value yes. Error [ERR XTDE3240] "It is a dynamic error if the value of $input does not conform to the JSON grammar, as selected using the explicit or implicit spec option." should become: "It is a dynamic error if the value of $input does not conform to the JSON grammar, as specified by [RFC7159], and when liberal is set to yes." Error [ERR XTDE3260] 'It is a dynamic error if the value of $options includes an entry whose key is "spec" and whose value is not a single xs:string, or an entry whose key is "validate" or "unescape" and whose value is not a single xs:boolean.' should become: 'It is a dynamic error if the value of $options includes an entry whose key is "liberal", "validate" or "unescape" and whose value is not a single xs:boolean, or an entry "fallback" whose value is not a function item that conforms to function(xs:string) as xs:string.' Errors under E. Summary of Error conditions have the same texts, currently. Notes: The paragraph "ECMA-404 differs from RFC 4627 in two respects: [...] array." can be removed. The paragraph "Many JSON implementations allow commas [...] Representation of JSON." should be revised or removed. Examples: Example "The expression json-to-xml('"abcd"', map{'spec': 'RFC4627'}) [...] not a string.)." should be removed or revised. Example "The expression json-to-xml('"abcd"', map{'spec': 'ECMA-404'})[...] abcd</string>." should be removed or revised. Example: the last example, right under "The following example illustrates ..." contains the "spec" option, this should be revised. Normative references The text of the link contains "4627", while the link was updated to refer to 7159: "IETF. The JavaScript Object Notation (JSON) Data Interchange Format. July 2006. See http://www.ietf.org/rfc/rfc4627.txt"
The corrections noted in comment #8 have been applied.