<div dir="ltr">From the 39-year-old curmudgeons-before-their-time camp, I'd like to point out that comments would be bad for two reasons:<div><br></div><div style>1. They're a sure sign somebody's gone and constructed something to fit implementation/consumption of data rather than describe it which ultimately makes modifying any system handling and constructing layered/nested JSON about as much fun as rebuilding a house of cards on a pile of broken glass.</div>
<div style><br></div><div style>2. The very next version of IE would start doing something awful with them because Microsoft engineers simply can not resist the temptation to do neat-o things with comments.</div><div style>
<br></div><div style>But seriously though, let's KISS on the JSON. It ain't broke.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 7, 2013 at 8:41 AM,  <span dir="ltr"><<a href="mailto:es-discuss-request@mozilla.org" target="_blank">es-discuss-request@mozilla.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send es-discuss mailing list submissions to<br>
        <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:es-discuss-request@mozilla.org">es-discuss-request@mozilla.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:es-discuss-owner@mozilla.org">es-discuss-owner@mozilla.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of es-discuss digest..."<br>
<br>Today's Topics:<br>
<br>
   1. Re: JSON Duplicate Keys (Alexandre Morgaut)<br>
   2. Re: JSON specification WAS: Re: JSON Duplicate Keys (Brendan Eich)<br>
   3. Re: JSON Duplicate Keys (Brendan Eich)<br>
   4. Re: JSON Duplicate Keys (Brendan Eich)<br>
   5. Re: JSON specification WAS: Re: JSON Duplicate Keys (gaz Heyes)<br>
   6. Re: JSON Duplicate Keys (Brian Kardell)<br>
   7. Re: JSON Duplicate Keys (Kevin Smith)<br>
<br><br>---------- Forwarded message ----------<br>From: Alexandre Morgaut <<a href="mailto:Alexandre.Morgaut@4d.com">Alexandre.Morgaut@4d.com</a>><br>To: Douglas Crockford <<a href="mailto:douglas@crockford.com">douglas@crockford.com</a>><br>
Cc: es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Fri, 7 Jun 2013 11:04:58 +0200<br>Subject: Re: JSON Duplicate Keys<br><br>
On 7 juin 2013, at 10:58, Alexandre Morgaut wrote:<br>
><br>
> 3) Another approach could be to let the parse() and stringify() methods accept an additional errorCallback parameter<br>
><br>
> It could be nice but it would force the developer to set values for the other optional parameters first even if he doesn't need them<br>
><br>
<br>
Well, of course, the errorCallback might be set via something like JSON.onerror but a specific callback may easily overwrite a previously defined global one and integrating the whole W3C EventTarget interface in ECMAScript might not be easily acceptable<br>

<br>
<br>
<br>
<br>
Alexandre Morgaut<br>
Wakanda Community Manager<br>
<br>
4D SAS<br>
60, rue d'Alsace<br>
92110 Clichy<br>
France<br>
<br>
Standard : <a href="tel:%2B33%201%2040%2087%2092%2000" value="+33140879200">+33 1 40 87 92 00</a><br>
Email :    <a href="mailto:Alexandre.Morgaut@4d.com">Alexandre.Morgaut@4d.com</a><br>
Web :      <a href="http://www.4D.com" target="_blank">www.4D.com</a><br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>><br>To: gaz Heyes <<a href="mailto:gazheyes@gmail.com">gazheyes@gmail.com</a>><br>
Cc: Douglas Crockford <<a href="mailto:douglas@crockford.com">douglas@crockford.com</a>>, es-discuss Steen <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Fri, 07 Jun 2013 11:43:07 +0100<br>
Subject: Re: JSON specification WAS: Re: JSON Duplicate Keys<br>gaz Heyes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When ES5 introduced line/para separators for valid new lines in JavaScript this broke the JSON specification<br>
</blockquote>
<br>
ES3, not ES5, way back in 1999, introduced LINE_SEPARATOR and PARA_SEPARATOR as line terminators. See ECMA-262 Edition 3, 7.3.<br>
<br>
/be<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>><br>To: Allen Wirfs-Brock <<a href="mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a>><br>
Cc: Douglas Crockford <<a href="mailto:douglas@crockford.com">douglas@crockford.com</a>>, es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Fri, 07 Jun 2013 12:13:25 +0100<br>
Subject: Re: JSON Duplicate Keys<br>

<div bgcolor="#FFFFFF" text="#000000">Allen Wirfs-Brock wrote:
<blockquote type="cite">
  <div>The ES5 spec. for JSON.parse requires (ie MUST accept) that 
duplicate keys are accepted and that the value associated with the last 
duplicated key wins.  A valid implementation of JSON.parse MUST not 
reject such JSON strings.</div>
</blockquote>
<br>
IETF has SHOULD as well as MUST, though. Normative specs can say what 
must happen, but also what should happen in a clean-slate or ideal-world
 setting. The Internet evolved with Postel's Law falling out of the 
process.<br>
<br>
Previously you wrote:<br>
<br>
> I would be willing to [lose] the first sentence (containing the 
SHOULD) entirely as it doesn't add any real normative value.
<span><br>
  <br>
But normative RFCs/internet-drafts that use SHOULD not MUST still have 
value.<br>
 </span><br>
>From <a href="http://tools.ietf.org/html/rfc2119" target="_blank">http://tools.ietf.org/html/rfc2119</a><br>
<br>
<span><pre><span><h2><a name="13f1edf46854d546_section-1" href="http://tools.ietf.org/html/rfc2119#section-1" target="_blank">1</a>. MUST  </h2></span>   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

<span><h2><a name="13f1edf46854d546_section-2" href="http://tools.ietf.org/html/rfc2119#section-2" target="_blank">2</a>. MUST NOT  </h2></span>   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

<span><h2><a name="13f1edf46854d546_section-3" href="http://tools.ietf.org/html/rfc2119#section-3" target="_blank">3</a>. SHOULD  </h2></span>   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.

<span><h2><a name="13f1edf46854d546_section-4" href="http://tools.ietf.org/html/rfc2119#section-4" target="_blank">4</a>. SHOULD NOT  </h2></span>   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

<span><h2><a name="13f1edf46854d546_section-5" href="http://tools.ietf.org/html/rfc2119#section-5" target="_blank">5</a>. MAY  </h2></span>   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

<span><h2><a name="13f1edf46854d546_section-6" href="http://tools.ietf.org/html/rfc2119#section-6" target="_blank">6</a>. Guidance in the use of these Imperatives</h2></span>   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmissions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.</pre> </span><br>
/be<br>
<br>
</div>
<br><br>---------- Forwarded message ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>><br>To: es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>
Cc: <br>Date: Fri, 07 Jun 2013 12:19:16 +0100<br>Subject: Re: JSON Duplicate Keys<br>Mark S. Miller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Everyone, please keep in mind that JSON does not and never has claimed to be the best or last data format. No doubt many better ones have been and will be created, some as variants of JSON, some not. If you'd like to create a "fixed JSON" or "enhanced JSON" or whatever, feel free -- whether it treats comments, duplicated keys, or \u2028 differently or whatever. But please don't confuse any of these variants with JSON itself. As a data format, JSON's greatest value is its stability, and the inability for anyone, including us, to version it.<br>

</blockquote>
<br>
+∞<br>
<br>
"Get off my lawn!" comment (I will tag in and tag Doug out of the grumpy old men smackdown ring): you kids stop fiddling with JSON. It needs "fixing" like it needs a hole in the head.<br>
<br>
/be<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: gaz Heyes <<a href="mailto:gazheyes@gmail.com">gazheyes@gmail.com</a>><br>To: Brendan Eich <<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>><br>
Cc: Douglas Crockford <<a href="mailto:douglas@crockford.com">douglas@crockford.com</a>>, es-discuss Steen <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Fri, 7 Jun 2013 12:55:09 +0100<br>
Subject: Re: JSON specification WAS: Re: JSON Duplicate Keys<br><div dir="ltr">On 7 June 2013 11:43, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

ES3, not ES5, way back in 1999, introduced LINE_SEPARATOR and PARA_SEPARATOR as line terminators. See ECMA-262 Edition 3, 7.3.<span><font color="#888888"></font></span><br></blockquote><div><br></div><div>
Oh that makes it better then =) <br></div></div></div></div>
<br><br>---------- Forwarded message ----------<br>From: Brian Kardell <<a href="mailto:bkardell@gmail.com">bkardell@gmail.com</a>><br>To: Brendan Eich <<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>><br>
Cc: es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Fri, 7 Jun 2013 08:49:25 -0400<br>Subject: Re: JSON Duplicate Keys<br><p>(Snipping out everything as this is a holistic response to the whole thread)</p>

<p>....</p>
<p>Re: MUST / last value<br>
Agree, codify the de facto standard.  That is what we do almost universally - it doesn't even actually "break" anything that already works - it just means those parsers aren't strictly conforming - they already aren't in keeping with the norm.</p>


<p>.....</p>
<p>Re: Should allow comments / single quotes<br>
Perhaps if we went back in time and were discussing creating a new format, you might even convince Doug of some of this - what we wouldn't know is how that would affect adoption/development of compatible parsers, bugs, etc - and that is important given the next comment...</p>


<p>.....</p>
<p>Re: The Web can't evolve if you can't...AND create something else, but don't call it JSON.. AND inventing crappy syntax</p>
<p>JSON is maybe the single best proof that the Web can evolve without breaking anything... It started out competing with XML which had every advantage imaginable: it was a REC standard, had support from every big company, hundreds of libraries, had built in/native support in just about every language and was "technically superior".  JSON had simplicity and dev contributions.  It competed in the real world and won hearts and minds against all odds.  Now we have a standard of agreement - you can't break it.  The Web is an enterprise of unparalleled scale, JSON is a data interchange format, so even more so than something that exists only in browsers...Anything that breaks potentially affects people's (not developers) lives in real ways and has to be done with great care.   You can, however, follow the same model and beat it.  In this case, if you have minor changes, it is even easy to make something that can transform to existing JSON format...  If you do, we can easily make it native/standard - and you can expect that eventually someone will have similar criticisms and try to compete  - that's a good thing.  </p>


<p>#extendthewebforward :)</p>
<br><br>---------- Forwarded message ----------<br>From: Kevin Smith <<a href="mailto:zenparsing@gmail.com">zenparsing@gmail.com</a>><br>To: Brendan Eich <<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>><br>
Cc: es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Date: Fri, 7 Jun 2013 09:41:48 -0400<br>Subject: Re: JSON Duplicate Keys<br><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+∞<br>
<br>
"Get off my lawn!" comment (I will tag in and tag Doug out of the grumpy old men smackdown ring): you kids stop fiddling with JSON. It needs "fixing" like it needs a hole in the head.<span><font color="#888888"><br>


<br></font></span></blockquote><div><br></div><div>Comment syntax sure would be nice though : P</div><div><br></div><div>{ Kevin }</div><div><br></div></div></div></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>