FYI: Ecma-404 approved and published
looks like Douglas C. website put in PDF ... I guess that's good for backward compatibility :-)
Thanks for the heads up, JSON FTW!
On Tue, Oct 8, 2013 at 7:59 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See www.ecma-international.org/publications/standards/Ecma-404.htm
I'm glad the alphabet is now defined (and that it's Unicode). It wasn't entirely clear to me whether that comment made it all the way. Looks good.
On Tue, Oct 8, 2013 at 7:59 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See www.ecma-international.org/publications/standards/Ecma-404.htm
I'm glad the alphabet is now defined (and that it's Unicode). It wasn't entirely clear to me whether that comment made it all the way. Looks good.
On 8 Oct 2013, at 19:59, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See www.ecma-international.org/publications/standards/Ecma-404.htm
As for Unicode, it explicitly refers to Unicode 6.2.0, even though version 6.3.0 was released last week.
On Tue, Oct 8, 2013 at 4:10 PM, Mathias Bynens <mathias at qiwi.be> wrote:
On 8 Oct 2013, at 19:59, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See www.ecma-international.org/publications/standards/Ecma-404.htm
As for Unicode, it explicitly refers to Unicode 6.2.0, even though version 6.3.0 was released last week.
The document was written in July, which was before last week.
On 08/10/2013, at 19:59, Allen Wirfs-Brock wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See www.ecma-international.org/publications/standards/Ecma-404.htm
It provides the normative specification of the syntax of JSON Text used for data interchange. Note that it does not define any semantics for such texts. There are many such possible semantics. Actual data interchange requires agreement between a producer and consumer regarding the semantic interpretation of a JSON text. This might, for example, take the form of ad hoc agreement between a producer and consumer upon an application specific JSON "schema" or it might be the subject of other standards that defines a semantics for some particular use case of the Ecma-404 JSON syntax.
IIUC top level values are valid JSON texts now, is that right?
""" 4 JSON Text A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar. """
The document is sublime. 14 pages of which 8 are not content. Now that's concise. I love it. The intro is, well, chapeau!.
Thank you,
There's a typo in 9.-String: the phrase "All characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F. " is repeated.
On Tue, 08 Oct 2013 22:19:52 +0200, Rick Waldron <waldron.rick at gmail.com>
wrote:
On Tue, Oct 8, 2013 at 4:10 PM, Mathias Bynens <mathias at qiwi.be> wrote:
On 8 Oct 2013, at 19:59, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See www.ecma-international.org/publications/standards/Ecma-404.htm
As for Unicode, it explicitly refers to Unicode 6.2.0, even though
version 6.3.0 was released last week.The document was written in July, which was before last week.
The document says
[[
The following referenced documents are indispensable for the application
of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document
(including any amendments) applies.
ISO/IEC 10646:2012, Information Technology – Universal Coded Character Set
(UCS)
The Unicode Consortium. The Unicode Standard, Version 6.2.0, (Mountain
View, CA: The Unicode
Consortium, 2012. ISBN 978-1-936213-07-8)
www.unicode.org/versions/Unicode6.2.0. ]]
AFAICT it's a dated reference, so only 6.2.0 applies. Was there a reason
to not use an undated reference, i.e. latest Unicode?
On 8 Oct 2013, at 22:19, Rick Waldron <waldron.rick at gmail.com> wrote:
On Tue, Oct 8, 2013 at 4:10 PM, Mathias Bynens <mathias at qiwi.be> wrote:
As for Unicode, it explicitly refers to Unicode 6.2.0, even though version 6.3.0 was released last week.
The document was written in July, which was before last week.
No need to get snarky.
Why not just refer to www.unicode.org/versions/latest, i.e. the latest available Unicode version? The version number doesn’t really matter for JSON as all it cares about is the concept of “code points”, the range of which is fixed.
Sorry for not raising this earlier, I must’ve missed the call for feedback in/before July.
JSON must not change. If it refers to "the latest Unicode, whatever that is", then it is potentially subject to disruption by (admittedly unlikely) future changes to Unicode.
If you look at the actual dependencies, it hardly matter as they are upon things that is very hard to image ever changing.
The dependencies are: 1)The definition of "code point" www.unicode.org/versions/Unicode6.2.0/ch03.pdf#G2212 2) the actual code point to abstract character associations for the "ASCII characters" mentioned in the spec. 3) the UTF-16 encoding algorithm used for non-BMP code points 4) ?? is there anything else?
I suspect the version specificity could be removed in the future.
On Tuesday, October 8, 2013, Mark S. Miller wrote:
JSON must not change. If it refers to "the latest Unicode, whatever that is", then it is potentially subject to disruption by (admittedly unlikely) future changes to Unicode.
I had a draft that said this, but Mark's arrived before I sent, so I'm giving the obnoxious +1 ;)
On 8 Oct 2013, at 23:39, "Mark S. Miller" <erights at google.com> wrote:
JSON must not change. If it refers to "the latest Unicode, whatever that is", then it is potentially subject to disruption by (admittedly unlikely) future changes to Unicode.
By that logic, it should have referred to either Unicode v5.0.0 or v4.1.0 because that were the latest available versions back in July 2006 as per www.unicode.org/history/publicationdates.html.
On 8 Oct 2013, at 23:51, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
If you look at the actual dependencies, it hardly matter as they are upon things that is very hard to image ever changing.
The dependencies are: 1)The definition of "code point" www.unicode.org/versions/Unicode6.2.0/ch03.pdf#G2212 2) the actual code point to abstract character associations for the "ASCII characters" mentioned in the spec. 3) the UTF-16 encoding algorithm used for non-BMP code points 4) ?? is there anything else?
Not as far as I can tell.
On 8 Oct 2013, at 23:51, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
I suspect the version specificity could be removed in the future.
Yay!
On 08/10/2013, at 19:59, Allen Wirfs-Brock wrote:
The Ecma General Assembly has approved by letter ballot Ecma-404
Hmmm, ECMA-404... why 404? The "not found" web standard? Pun intended?
Is it possible to add proposals to spec?
The Ecma General Assembly has approved by letter ballot Ecma-404: THE JSON Data Interchange Formal See www.ecma-international.org/publications/standards/Ecma-404.htm
It provides the normative specification of the syntax of JSON Text used for data interchange. Note that it does not define any semantics for such texts. There are many such possible semantics. Actual data interchange requires agreement between a producer and consumer regarding the semantic interpretation of a JSON text. This might, for example, take the form of ad hoc agreement between a producer and consumer upon an application specific JSON "schema" or it might be the subject of other standards that defines a semantics for some particular use case of the Ecma-404 JSON syntax.