>From the 39-year-old curmudgeons-before-their-time camp, I'd like to point out that comments would be bad for two reasons:
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. 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. But seriously though, let's KISS on the JSON. It ain't broke. On Fri, Jun 7, 2013 at 8:41 AM, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: JSON Duplicate Keys (Alexandre Morgaut) > 2. Re: JSON specification WAS: Re: JSON Duplicate Keys (Brendan Eich) > 3. Re: JSON Duplicate Keys (Brendan Eich) > 4. Re: JSON Duplicate Keys (Brendan Eich) > 5. Re: JSON specification WAS: Re: JSON Duplicate Keys (gaz Heyes) > 6. Re: JSON Duplicate Keys (Brian Kardell) > 7. Re: JSON Duplicate Keys (Kevin Smith) > > > ---------- Forwarded message ---------- > From: Alexandre Morgaut <[email protected]> > To: Douglas Crockford <[email protected]> > Cc: es-discuss <[email protected]> > Date: Fri, 7 Jun 2013 11:04:58 +0200 > Subject: Re: JSON Duplicate Keys > > On 7 juin 2013, at 10:58, Alexandre Morgaut wrote: > > > > 3) Another approach could be to let the parse() and stringify() methods > accept an additional errorCallback parameter > > > > 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 > > > > 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 > > > > > Alexandre Morgaut > Wakanda Community Manager > > 4D SAS > 60, rue d'Alsace > 92110 Clichy > France > > Standard : +33 1 40 87 92 00 > Email : [email protected] > Web : www.4D.com > > > > > ---------- Forwarded message ---------- > From: Brendan Eich <[email protected]> > To: gaz Heyes <[email protected]> > Cc: Douglas Crockford <[email protected]>, es-discuss Steen < > [email protected]> > Date: Fri, 07 Jun 2013 11:43:07 +0100 > Subject: Re: JSON specification WAS: Re: JSON Duplicate Keys > gaz Heyes wrote: > >> When ES5 introduced line/para separators for valid new lines in >> JavaScript this broke the JSON specification >> > > ES3, not ES5, way back in 1999, introduced LINE_SEPARATOR and > PARA_SEPARATOR as line terminators. See ECMA-262 Edition 3, 7.3. > > /be > > > > ---------- Forwarded message ---------- > From: Brendan Eich <[email protected]> > To: Allen Wirfs-Brock <[email protected]> > Cc: Douglas Crockford <[email protected]>, es-discuss < > [email protected]> > Date: Fri, 07 Jun 2013 12:13:25 +0100 > Subject: Re: JSON Duplicate Keys > Allen Wirfs-Brock wrote: > > 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. > > > 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. > > Previously you wrote: > > > I would be willing to [lose] the first sentence (containing the SHOULD) > entirely as it doesn't add any real normative value. > > But normative RFCs/internet-drafts that use SHOULD not MUST still have > value. > > >From http://tools.ietf.org/html/rfc2119 > > 1 <http://tools.ietf.org/html/rfc2119#section-1>. MUST This word, or the > terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > 2 <http://tools.ietf.org/html/rfc2119#section-2>. MUST NOT This phrase, > or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > 3 <http://tools.ietf.org/html/rfc2119#section-3>. SHOULD 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. > 4 <http://tools.ietf.org/html/rfc2119#section-4>. SHOULD NOT 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. > 5 <http://tools.ietf.org/html/rfc2119#section-5>. MAY 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.) > 6 <http://tools.ietf.org/html/rfc2119#section-6>. Guidance in the use of > these Imperatives 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. > > > /be > > > > ---------- Forwarded message ---------- > From: Brendan Eich <[email protected]> > To: es-discuss <[email protected]> > Cc: > Date: Fri, 07 Jun 2013 12:19:16 +0100 > Subject: Re: JSON Duplicate Keys > Mark S. Miller wrote: > >> 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. >> > > +∞ > > "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. > > /be > > > > ---------- Forwarded message ---------- > From: gaz Heyes <[email protected]> > To: Brendan Eich <[email protected]> > Cc: Douglas Crockford <[email protected]>, es-discuss Steen < > [email protected]> > Date: Fri, 7 Jun 2013 12:55:09 +0100 > Subject: Re: JSON specification WAS: Re: JSON Duplicate Keys > On 7 June 2013 11:43, Brendan Eich <[email protected]> wrote: > >> ES3, not ES5, way back in 1999, introduced LINE_SEPARATOR and >> PARA_SEPARATOR as line terminators. See ECMA-262 Edition 3, 7.3. >> > > Oh that makes it better then =) > > > ---------- Forwarded message ---------- > From: Brian Kardell <[email protected]> > To: Brendan Eich <[email protected]> > Cc: es-discuss <[email protected]> > Date: Fri, 7 Jun 2013 08:49:25 -0400 > Subject: Re: JSON Duplicate Keys > > (Snipping out everything as this is a holistic response to the whole > thread) > > .... > > Re: MUST / last value > 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. > > ..... > > Re: Should allow comments / single quotes > 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... > > ..... > > Re: The Web can't evolve if you can't...AND create something else, but > don't call it JSON.. AND inventing crappy syntax > > 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. > > #extendthewebforward :) > > > ---------- Forwarded message ---------- > From: Kevin Smith <[email protected]> > To: Brendan Eich <[email protected]> > Cc: es-discuss <[email protected]> > Date: Fri, 7 Jun 2013 09:41:48 -0400 > Subject: Re: JSON Duplicate Keys > > +∞ >> >> "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. >> >> > Comment syntax sure would be nice though : P > > { Kevin } > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
