Talk:JSON/Archive 2

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

YAML comparison

It seems that the YAML comparison section is again becoming more of an evangelism forum (pushing the WP:NOR and WP:NPOV boundaries) and contains both stylistic problems as well as factual errors. (It should also be noted that some of these same comparison problems are also repeated on the YAML article.)

"With the exception of comment strings, JSON is entirely[1] a subset of YAML."

Although casual observation may lead one to this conclusion, the statement is wrong (and it is not obvious that the one cited reference is either notable or reliable, per WP:RELY). From direct examination of the JSON specification (RFC 4627) and the YAML specification [2] (titled "Working Draft 2004-12-28" as of 2007-09-15), there exist valid JSON documents which YAML does not permit. Just some of the incompatibilities include:

UTF-32: JSON requires all parsers to accept UTF-32 encoding, YAML disallows UTF-32.
Tabs: JSON liberally permits tab characters (U+0009), such as surrounding "structural characters"; YAML is more restrictive.
Linebreaks: JSON allows line break characters (such as U+000A) to appear inside double-quoted strings where they are interpreted literally, while YAML will invoke multi-line folding on such a sequence.
Unescaped characters: JSON permits any unicode character (except U+0000..U+001F, U+0022, U+005C) to appear within a double-quoted string un-escaped; YAML disallows some of these. For example the non-printable character U+003B is permitted in JSON but disallowed in YAML.
Non-BMP characters: JSON allows Unicode characters outside the BMP to be represented by a double-surrogate-escape syntax, for example "\uD834\uDD1E" which is interpreted as U+1D11E; YAML does not permit this (since each \u escape is treated independently and it does not allow such escapes to evaluate to a surrogate codepoint).

Additionally the "exception of comment strings" remark makes little sense as JSON does not support a comment string.

[...]it enforces avoidance of the security pitfall of using a built-in interpreter to evaluate code into native data structures.

This is not entirely true either. Granted, it is unlikely that JavaScript programs will attempt to knowingly parse YAML documents using the eval() function as is frequent with JSON. But eval() is not the only way to get YAML to be evaluated by the JavaScript interpreter. YAML documents could still be subject to similar cross-site request forgery attacks, specifically because some YAML documents are also valid JSON (or more importantly are valid JavaScript). Those subsets of YAML documents are just as XSRF vulnerable as is JSON. So it's not an entirely false statement, but not entirely true either; and regardless it is bordering on original research. --Dmeranda 06:28, 15 September 2007 (UTC)

Don't forget about commas: [ 1,23 ] parses as [ 1, 23 ] in JSON but [ 123 ] in YAML. It's very misleading to say that JSON is a subset of YAML and I think that the sentence you quoted should be removed since it's wrong on both counts. TomJF 21:38, 23 September 2007 (UTC)

CHANGED: I updated the YAML comparison section to have a NPOV and to enumerate the distinguishing characteristics with specific factual, rather than opinionated and arguably misleading, content. There is a danger that some JSON evangelists might still consider any comparisons to another format as blasphemy. However the entire section on comparison to other related formats is absolutely essential to an article of this type. It serves multiple purposes and in this case it has the added bonus of permitting a terse discussion of serialization concepts that have no expression in JSON. This is perhaps a best way to enumerate such issues in languages (e.g. contrast this with the rather unhelpful dog's dinner of listed defects in XML on the XML page, which don't teach the user anything helpful since you can't actually understand them without a comparison of how it could be done differently.) By giving concrete comparisons: e.g. XML has the notion of validation as well as well-formed. YAML has the notion of Relational data. The reader has some concrete points of comparison and it avoids becoming abstract criticism. Cems2 23:46, 21 October 2007 (UTC)

I also deleted the point of distinction on YAML lacking JSON's eval security pitfall. I'm not sure I should have done that. The argument against removing it is that in the real world it's one of the most expensive and common pitfalls, so ignoring it is like ignoring the elephant in the room and does the reader poorly with a lack of teaching. The argument for removing it is that it's not really a difference is syntax which is what that paragraph is about, it's simply a pragmatic issue. In theory both languages are equally secure so including it lacks a certain NPOV quality in favor of YAML, since user experience is the difference.Cems2 23:46, 21 October 2007 (UTC)

References to software implementations

I've written the M's JSON library, which is a JSON parser written in C. The project is hosted by sourceforge and it's listed as the top JSON project in sf.net, which isn't much. Yet, I do believe that a link to the project's site should be included in the reference section. As I'm the project's author, I don't believe it would be right for me to add it there. So, can anyone add a reference to it? The project page is [3] --Mecanismo | Talk 16:07, 8 December 2007 (UTC)

Thanks for making your software available for others; unfortunately Wikipedia is not really the right place to link to this, see WP:NOT#LINK. Since there are probably over 50 different JSON implementations, linking to each would quickly overwhelm the external links section. Fortunately the website json.org seems to serve that purpose well: as a nearly comprehensive list of implementations and links to them. I see that your "M" C implementation is already listed on that site. For anybody else's project, please consider getting your site listed on the json.org list rather than adding links in this article. On the other hand, links to topical information about JSON (rather than just software libraries) may be appropriate for linking here. - Dmeranda (talk) 19:22, 10 December 2007 (UTC)

Comparison

There are two versions of potentially equivalent XML provided on the page, with the one used for size comparison bending the implied semantics of the example to collapse an array of phone numbers into a single tag. This likely invalidates the example for size comparison purposes.

76.202.78.34 (talk) 00:45, 19 July 2010 (UTC)

Is it possible to add and delete records/items in a JSON object using JavaScript? If no, this should be mentioned under the section about comparison. 220.227.179.4 (talk) 15:45, 6 January 2008 (UTC)

delete obj.foo. 202.54.176.51 (talk) 05:18, 6 March 2008 (UTC)

The first version of XML is not equivalent to the second, or to the JSON. In particular, element descendants are always ordered (even if that ordering is ignored by the consumer of the data), whereas a JSON object is always unordered. So the XML contains more information. In effect, the first version of XML corresponds to a nested array of objects (some of which have a single key:value pair).

The second example is limited because attribute values in XML are not equivalent to JSON values. In particular, XML attributes cannot be nested. It is possible to use attribute values as references, or stuff them with specially encoded representations, neither of which are within the direct purview of XML.

JSON is a broad but still special case initialization notation and I don't think it can directly represent all JavaScript objects. Any String, Number, or Array with attached properties must be expressed indirectly and handled in application code. As noted, there are also several unsupported JavaScript data types. XML can express these, but again handling the conversion is application or library code (just as it is with JSON), not something that XML handles directly. The XML syntax does not have to be extended to express the relationships or types (though the tag set does). Applications are left with the responsibility for enabling such mappings in both XML and JSON. — Preceding unsigned comment added by 75.189.231.100 (talk) 16:31, 10 December 2011 (UTC)

Associative Array

JSON is not an associative array if I'm reading the articles right. It appears like one, but isn't one. Correct? -- 72.155.222.134 (talk) 14:12, 15 March 2008 (UTC)

No, the JS Object type is an associative array. EdC (talk) 14:06, 16 March 2008 (UTC)

I think it is fair to say that the JSON "object" type is an associative array, or is meant to be interpreted as one. The main difference between the JavaScript Object and the JSON object is that in JSON only strings may be used as keys. However, remember that JSON is only a representational data format, so there are no requirements that any particular algorithm or data structure (e.g., hash tables) must be used by any software implementing the JSON specification. -- Dmeranda (talk) 05:05, 17 March 2008 (UTC)

JSON and CSRF

The section on CSRF security risks contained incorrect information. I have removed it and replaced it with correct information, but do not want to clutter the main page with a bunch of references about why the old stuff was wrong. So, here.

Per Joe Walker, using an array as the outer container is indeed insecure and can lead to data theft. His followup about stealing data from objects assumes that the data sent will be in the form "({...})". However, this is actually *invalid* JSON. Valid JSON using the "{...}" format is not vulnerable, because a syntax error will be raised before any attribute assignments are executed. Tom Hughes-Croucher writes about this. John Millikin (talk) 03:02, 30 March 2008 (UTC)

JavaScript eval

This statement:

   eval is meant for JavaScript, not for JSON; using it for such is abusing the interface

appears to be unsubstantiated and sufficiently ambiguous as to warrant a citation. Absent that, it appears to be inappropriate editorializing on the subject matter of this article.

For example, the relevant section of the article does not cite any authoritative source to support the claim of what JavaScript eval() is "meant" for. Similar problems apply to the assertion of "abuse".

If there is a normative statement to be made about the "proper" practices of JavaScript coding, it belongs in an article on JavaScript. Moreover, even in a JavaScript article, such normative claims would be inappropriate unless properly attributed to a reliable source as a statement of such-and-such person's opinion, industry convention, or whatever.

Please help to keep this article as neutral, well-substantiated and objective as possible. Thanks. dr.ef.tymac (talk) 00:50, 21 April 2008 (UTC)

It is fine to request citations on merit, but please don't be so quick to cast judgments concerning perceived editorializing. Omission of this information is itself a form of editorializing.

I am beginning to have doubts whether this entire section, Security issues, even belongs in this article. None of this directly concerns JSON, the language-independent data interchange format; it is all about the security or insecurity of one particular method used by one particular language, JavaScript. In fact JSON is not even needed for this JavaScript security problem; one could try using eval to process a calculator language expression; and would similarly see the exact same security problems. Perhaps this material is better moved to eval, JavaScript, AJAX, or some such page where it may have more relevance.

As far as what eval was meant for, I will grant that perhaps the word "meant" should instead read "is required to do", as it would not require any subjective determination of motive (since the ECMAScript standard does not include a non-normative rationale section as some other language standards do). Additionally, eval clearly predated the existence of JSON and so was certainly not meant to process JSON (even though it may be made to do so): ECMAScript r3 was published in 1999, and the json.org website didn't exist until 2000, with JSON only being standardized as an RFC in 2006. Anyway, concerning what eval does, straight from the normative reference ECMA-262, 3rd Ed. Dec. 1999:

10.1.2 Type of Executable Code

...
Eval code is the source text supplied to the built-in eval function. More precisely, if the parameter to the built-in eval function is a string, it is treated as an ECMAScript Program [emphasis added]. The eval code for a particular invocation of eval is the global code portion of the string parameter.
...

15.1.2.1 eval(x)
When the eval function is called with one argument x, the following steps are taken:
1. If x is not a string value, return x.
2. Parse x as a Program. If the parse fails, throw a SyntaxError exception (but see also clause 16).
3. Evaluate the program from step 2.
...

At no place does the standard make any notion of demarshaling JSON-encoded data, or data in any other format for that matter. It is very explicit about evaluating only a "JavaScript Program". So it should be a non-controversial statement and very clearly supported that eval was meant for JavaScript (albeit a better choice of words could be used for meant). One needs to be careful of conflating JSON (type "application/json" per RFC 4627) with JavaScript (type "application/javascript" per ECMA-262). Furthermore, as it is very clearly documented in a normative manner that any string you pass into eval will be treated as if it is an ECMAScript Program; any caller of eval is thereby making an implied claim that the provided string argument is in fact ECMAScript. Therefore, knowingly passing in JSON data to eval is by any strict interpretation misrepresenting the type of the data. Please note this is not a judgment on whether this is correct or reasonable or good or bad; it is a factual technical statement of an intentional type-mismatch. Just a using a C-style cast is misrepresenting the type; it may be a perfectly okay thing to do, but it is still intentional misrepresentation. In as much as this is the root cause of many security issues, it is worthy of mention. -- Dmeranda (talk) 05:59, 21 April 2008 (UTC)

Review of Dmeranda's "intentional misrepresentation" analysis

Your analysis contains some substantiated information, however none of the substantiated information is under dispute. What is under dispute are the parts of your analysis that seem to derive from wholly unsubstantiated origins.

For review:

One needs to be careful of conflating JSON with JavaScript

The validity of this point is not at issue, the issue is that all material claims put forward in this article need to have some basis in citable, relevant authority.

At no place does the standard make any notion of demarshaling JSON-encoded data.

Nor have you provided a cite to the standard (or any other relevant source for that matter) that specifies an unambiguous method for distinguishing an instance of JSON from an instance of JavaScript, in those cases where syntax of each is mutually indistinguishable.

If you wish to emphasize this distinction, please provide some authority for it.

any caller of eval is making an implied claim that the provided string argument is in fact ECMAScript

This is a serious deficiency of your analysis. It entirely lacks support. The same goes for your use of the terms "misrepresent", "abuse", "meant", "intended", "intentional misrepresentation" and others.

For example, the ECMAScript specification states in relevant part:

   An implementation may treat any instance of the following kinds of runtime errors 
   as a syntax error

the specification also states ...

   An implementation may report syntax errors in eval code

Unless you can provide reliable support to the contrary, these terms clearly and completely refute any claim that eval code that is not valid ECMAScript code somehow constitutes a kind of "abuse" or "intentional misrepresentation".

Clearly, your "intentional misrepresentation" theory needs either a citation and much better support, or it needs to go somewhere else besides a WP article. dr.ef.tymac (talk) 15:00, 21 April 2008 (UTC)

Native client-side support for JSON

Native support is coming soon. IE8 and Firefox 3.1. I think this should be noted --Voidvector (talk) 05:50, 11 December 2008 (UTC)

Cross-site request forgery

Note that the section in which script inclusion attacks are called a variant of XSRF directly contradicts the XSRF article, which defined XSRF attacks as a wholly different animal, and specifically says they are "blind" (e.g., data is posted, but cannot be read back). Sadly, this misnomer is repeated on a number of sites; a more appropriate, but slightly less popular name is "cross-site script inclusion". We might want to either stop calling it XSRF and use XSSI instead, or at least resolve the conflict by saying that the current name is not technically accurate. --lcamtuf (talk) 22:24, 11 January 2009 (UTC)

I believe the appropriate term is term is Cross-Site Scripting (XSS), rather than XSSI. 82.133.80.50 (talk) 10:01, 4 January 2012 (UTC)

in general, JSON is neither valid YAML nor valid ecmascript

The following JSON text is not valid YAML, as YAML does not support surrogate codepoint encoding, while JSON requires it for non-BMP characters:

  ["\ud808\udf45"]

This is a problem in practise, as it makes JSON non-interoperable with YAML with non-BMP characters. Also, YAML puts a limit of 1024 characters on the length of strings used as object property names in JSON notation, while JSON does have no such limit.

Similarly, the following JSON text (where \x2028 stands for the literal U+2028 character) is a valid JSON text, but not valid ECMAscript, as ecmascript disallows literal U+2028 characters in string literals:

 ["\x2028"]

This also comes up in practise, as JSON generators usually do not escape those characters, as this is not required by JSON.

So all claims that YAML is a superset of JSON, or JSON is a subset of ecmascript, are wrong, and should be removed.

Also, the article keeps having statements like "JSON is a YAML subset, you only have to remove ...". Do not do this: if you have to change JSON texts before it becomes valid YAML, it isn't a subset.

91.89.172.190 (talk) —Preceding undated comment was added on 22:53, 17 February 2009 (UTC).

No clue about your YAML comment, since I am not familiar with it. "\x2028" is not valid JSON, because JSON spec does not support "\x" (see this chart). It is valid ECMAScript. In ECMAScript it is " 28" because "\x20" is the space character. --Voidvector (talk) 02:42, 18 February 2009 (UTC)

*sigh. I explicitly wrote that \x2028 is the literal U+2028 character - please read what I wrote, not just the two indented lines. 91.89.172.190 (talk) —Preceding undated comment was added on 01:11, 19 February 2009 (UTC).

Regardless of what your own interpretation of "\x2028" is, it does not represent "U+2028" in JSON or ECMAScript. --Voidvector (talk) 02:13, 19 February 2009 (UTC)

OMG. I never claimed it would represent U+2028 in JSON. Please care to *read* what I wrote. I claimed it represents U+2028 _in the example only_. You are supposed to replace it by an actual U+2028 character when trying out the example. Thats what *literal* means. The example *is* a valid JSON text, but *not* valid ecmascript. 91.89.172.190 (talk) —Preceding undated comment was added on 04:54, 19 February 2009 (UTC).

GP is correct — you're reading his post incorrectly. He's not trying to say that "\x2028" is valid JSON, he's trying to say, "when you read this snippet, in your head, replace '\x2028' with U+2028." He doesn't want to actually put a U+2028 in the example itself, as this would be confusing (U+2028 is a line separator; it would be invisible), thus, he's using the pseudo syntax "\x2028" to represent it. GP would also appear to be correct in his overall point: JSON is not a subset of JavaScript. Deathanatos (talk) 01:32, 28 July 2012 (UTC)

Updated YAML spec

The YAML 1.2 specification also explicitly states:

"Note version 1.2 is mostly a superset of version 1.1, defined for the purpose of ensuring JSON compatibility." (see Section 6.8.1. “YAML” Directives [4]) Peak (talk) 05:08, 20 February 2009 (UTC)

iddqd

onreadystatachange should be set before calling send() —Preceding unsigned comment added by 90.150.217.213 (talk) 16:07, 3 June 2009 (UTC)

Pronunciation of "JSON"

(pronounced /ˈdʒeɪsɒn/, i.e., "Jason")

I (a native speaker from Michigan) pronounce "Jason" as /ˈdʒeɪsʌn/ (or, reduced, /ˈdʒeɪsən/ or /ˈdʒeɪsɨn/). In other words, I rhyme the last syllable with "run" and "fun", not with the /ɒ/ in "on" or "con". So I think one of the pronunciations in the article now is wrong. I couldn't find an official pronunciation on json.org.

--Arundelo (talk) 16:10, 30 June 2009 (UTC)

I've removed the pronunciation altogether. The IPA wasn't complete with regards to emphasis (and I don't know how to fix it), and didn't even match the pronunciation of Jason. I suggest not putting one, or putting multiple up pronunciations, with a possible section in the article about it. I can't find an official pronunciation, nor a reliable source that says how it is pronounced, and I'm pretty sure developers are split on it. Some say it's like the name Jason, while others pronounce it Jay-sawn. I've always pronounced it Jay-sawn, but that's just how my mind thinks it would be pronounced with English pronunciation rules (I'll see if I can come up with why). -- Austin512 (talk • contribs) 04:21, 2 August 2009 (UTC)

According to coiner Crockford as quoted at StackOverflow, he "strictly" does not care about its pronunciation, but says it like "Jason" most of the time, himself. He riddiculed the argument by asserting a nasal French pronunciation, like "Je Só(n)". As for normal English rules, perhaps it depends whether you consider it JS-ON (like "Jace on") or J-SON (like "jay son" and "Jason"). All considered, "Jay son" is apparently more canonical, with "Jace on" being a commonly-used and approved alternative, yet neither being official. Clears everything right up... :) 99.49.35.118 (talk) 16:55, 12 February 2012 (UTC)

Differences between JSON and Javascript literals

Could it be worth to list in detail the differences between JSON syntax and the one of Javascript literals? The reason would be to explain how JSON is a subset of Javascript.

JSON syntax forces some notations (most notably strings delimited only by quotes, object property names which must be string and a smaller set of escape sequences) which may not be clear to people who know Javascript but didn't read the JSON specs carefully.

--Alessio (talk) 12:35, 2 July 2009 (UTC)

Yes, I agree such a section should be written down. I could write it if I have more time. Hope someone is more free than I am and could write it first :) 石庭豐 (talk) 21:04, 22 April 2011 (UTC)

Fragment regarding Efficiency moved from main page

"edit: While data compression is not covered in the standard, there is no reason one could not compress/decompress the entire response on both ends of the transmission. Also strings may be interned if needed by having an array structure, call it strings that contains all the strings to be interned, and then using the indexes into the array in place of the string. One must note though that string interning only makes sense with large documents, because while it lowers transmission time it also increases processing time. If responses are large it may be best to split the transaction into several shorter and more versatile requests."

—Preceding unsigned comment added by Balrog-kun (talk • contribs) 07:56, 20 September 2009

Efficiency versus Redundancy

JSON's lack of efficiency is not always a disadvantage. Lack of efficiency derives from the fact that most strings are not JSON encodings. But this implies that if a JSON string is corrupted it will almost certainly not parse - which is a good thing. Does anyone know of a statistical analysis showing the probability of being able to parse a corrupted JSON string? — Preceding unsigned comment added by 71.80.122.62 (talk) 13:26, 22 November 2011 (UTC)

Better example?

The example at the top of the page only shows objects, arrays and strings. Could a better example please be put up showing a number, a boolean and a null? --91.85.161.65 (talk) 22:58, 2 November 2009 (UTC)

Done. Things like that bother me as well. 71.214.223.133 (talk) 20:32, 27 November 2009 (UTC)

Technical template

This article, as written, is quite effective in describing JSON to those you wish to use it. Most included technical details are relevant and contribute to the articles usefulness IMHO. Consequently, I removed the technical template. Roesser (talk) 21:44, 12 February 2010 (UTC)

Remove JSONP reference?

I don't believe that the JSONP reference belongs in this article. It doesn't follow from the subject being discussed and it sounds "shoehorned" into this article to be able to piggy back from it. This article, along with the info related to JSONP, would benefit if the part regarding JSONP was cut off this article and added into a new article. -- Mecanismo | Talk 09:36, 18 April 2010 (UTC)

I agree with this. I don't know how WP:NOTABLE JSONP is, but it is certainly not important enough to have all this space, and subsections of its own, in this main article. It is shoehorned into here too, and not very well: The JSON article is about an internationally agreed data format, no longer a detail of JavaScript. JSONP is only relevant in limited client-side JavaScript (probably Ajax) scenarios, yet it is not introduced in this way here, or given with any caveats at all in fact. I propose a new JSONP article, move all this stuff into it and mention it here as a 'See also' link. Does anybody have any objection to this plan? --Nigelj (talk) 19:24, 14 June 2010 (UTC)

Done. 22 March 2011. —Preceding unsigned comment added by 166.137.142.50 (talk) 00:03, 23 March 2011 (UTC)

Does JSON define 'objects'?

I just removed a comment in <ref> tags from the lede that said that the 'objects' defined by JSON are not 'true' objects, because they only contain name-value pairs and no executable code. There is a strict sense in which this may be true, but there are various other 'readings' of the facts in which it is not.

First, in JavaScript, the executable part of a 'function' is defined as a 'value'. These values are exactly equivalent to any other values and can be stored in variables, arrays and objects, as well as being able to be invoked and executed (see JavaScript the definitive guide, Flanagan, P. 32). Therefore, a JSON string can indeed include executable functions, along with other data, and these can be invoked by a JavaScript interpreter later. This is the reason that there can be security issues to using eval() on untrustworthy JSON.

However, looking at http://groups.google.com/group/json-schema/browse_thread/thread/edfe56779c9196ea we see a couple of examples of making use of this syntax. The first thing to note is that, because JavaScript is prototype-based, object-based language (rather than a class-based, object-oriented one like Java or C#) there is slightly more to assembling a prototype-based object correctly than might first occur to one.

Lastly, notice the comments in that discussion from the JSON Schema folk: Although all this may work in JavaScript, JSON Schema was meant to define a notation that could (and is) used by just about every programming language. Clearly, a function written in JavaScript cannot be run in another language.

So, I think we could have a short section on this in the article, but I don't think we can write it off in an uncited footnote buried in the lede. Does anybody else think it's worth covering properly? Or not at all? --Nigelj (talk) 17:29, 7 June 2010 (UTC)

Comparison with other formats

I'm not happy with most of this section. First, JSON is an "open standard designed for human-readable data interchange", second it has a media-type, an RFC and a wide use-base on the internet, particularly related to Ajax data, but other uses too. That makes it somewhat comparable to XML, which is often a realistic option when JSON is used for data interchange. But, recently some editors have taken the view that because JSON has historical links to a JavaScript language construct, then internal language structures from other languages and some proprietary file-formats are comparable too, and need comparing here. This is not so. Windows registry format could have been standardised and gained wide use on the internet for data transfer, but it did not. Nor did ini files, PHP array initialisers, MAC OSX property files, nor YAML. Nor are they likely to gain the user-base of JSON (or XML) any time soon, and even if they did, they have their own articles and need not be described in detail with large examples here. I feel that this whole section just dilutes the focus of this article on JSON with other might-have-beens that are not comparable. Many other languages now have JSON parsers available, the equivalent of JavaScript's eval(), so even the historical link with that language are irrelevant now. Can we prune this section right down, please? --Nigelj (talk) 20:20, 25 August 2010 (UTC)

Well, nobody had any comment to make for over 6 months here, so I have gone ahead and removed the irrelevant sections. The article is much clearer now. Considering the vast section on JSONP, and the still heavyweight comparisons with XML, I would say that still less than half of the article is actually about JSON, but it's a lot better than it was when maybe only 10% - 20% was about the main subject. --Nigelj (talk) 20:23, 14 March 2011 (UTC)

Data types, syntax and example

I fail to see why an XML example is given in this section, surely that is only relevant in the comparison section? The first of the two XML examples given is possibly the most ridiculously poor use of XML I've ever seen. The whole article reads like an attempt at balance is being made by giving equal space to two factions in a holy war.95.209.209.247 (talk) 20:48, 27 January 2011 (UTC)

Unique keys?

Is it required that the keys in an object are unique? Example:

{
   "foo":"bar",
   "foo":"yuk",
   "foo":"bar",
   "foo":42
}

If not: Do the common JSON libraries support the above example? A simple key lookup is not possible for that. --RokerHRO (talk) 18:24, 21 February 2011 (UTC)

I'm not sure how to understand your first question. By "keys", you actually meant "properties" (of objects) because we are using the language/jargon of JavaScript. For your second question, the simple answer is "yes" but maybe not as what you expected. Let me explain.

In order to interpret your data, we have to go back to the source of JSON: Javascript. Maybe you would like to consider the object structure as a collection in some language you're using or thinking about, but in order to make sure that JSON is "language neutral", we must also guarantee that the same data are read in all supported language (otherwise, that would mean JSON depended on one particular language to get a particular set of data)

Your data is essentially equivalent to

var a = {  // a is just a variable name which isn't important here, could have been b, c, whatever
   "foo":"bar",
   "foo":"yuk",
   "foo":"bar",
   "foo":42
}

So, at the end, you just have a.foo = 42 as the previous values were all replaced by successive assignments. And when I look at your data structure, I'm not sure it's very useable. What do you expect to get when you access the "foo" property (or key, as you like)? I mean, it's very common to see one-to-one collections or many-to-one collections, but I'm not sure one-to-many collections is manipulatable. 石庭豐 (talk) 10:02, 18 April 2011 (UTC)

Thanks for your answer.

Albeit JSON was invented with JavaScript syntax in mind, and being evaluable by JavaScript interpreters, JSON got a different formal syntax definition that differ in some aspects from JavaScript, i.e. JSON is much stricter and does not allow anything that JavaScript allows in its objects.

I read the RFC again and more carefully and it seems that JSON forbid our example. --RokerHRO (talk) 15:02, 21 April 2011 (UTC)

It's not correct to say "JSON got a different formal syntax definition" (which implies it could have something that JavaScript doesn't support). Better to say "JSON got a stricter formal syntax definition" as you've written later.

I haven't read RFC carefully, to be honest. So I'd like to know which part of it forbids your example because I don't think it's forbidden. For me, the example is completely syntactically correct but it just won't give result as you expected, as I've written. 石庭豐 (talk) 10:49, 22 April 2011 (UTC)

For me stricter is a kind of different. ;-) But I think the article can be better to emphasize the differences between JavaScript and JSON. --RokerHRO (talk) 11:24, 24 April 2011 (UTC)

Exact, but the other way round is not true (ie, different is NOT a kind of stricter). Think of this simple logical example:

A - There's this message "This room is reserved to every woman" written on a door

B - every woman is a kind of everyone

Can you change the message to "This room is reserved to everyone"?

The answer is "No, it's (logically) not correct to say/do so".

On the other topic, yes, the article should show the differences between both JavaScript and JSON. 石庭豐 (talk) 15:10, 27 April 2011 (UTC)

JSON is not a subset of JavaScript

As referenced at http://timelessrepo.com/json-isnt-a-javascript-subset JSON is not actually a subset of javascript; there are some valid json strings that are not valid javascript code. I propose removing references to "JSON is a subset of javascript", though it might be worth mentioning this common misconception. I am not going to make this edit today but will later if it has not been done and there is no good reason not to. Thomblake (talk) 17:46, 16 May 2011 (UTC)

Damn! I think that is a specification bug. I assume the JSON guys were not completeley aware of all the Unicode pitfalls. :-( I hope it is fixed in the next JSON standard. --RokerHRO (talk) 13:44, 21 May 2011 (UTC)

File:Json-syntax-diagram-array.gif Nominated for speedy Deletion

An image used in this article, File:Json-syntax-diagram-array.gif, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status

What should I do?