Talk:JSON

From Wikipedia, the free encyclopedia

Contents

[edit] 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)

[edit] External link to BarracudaDrive and JSON security

I have re-introduced the external link removed by Sleepyhead81. For what reason did you remove this link? This is a good example of how to use JSON. I changed the link to the technical information page for BarracudaDrive.

I do not agree with the security considerations when using JSON in a browser: "in practice, however, security and other considerations generally preclude using eval"

This is only a problem if doing cross site scripting, which is normally not allowed anyway. A DHTML application is loaded on demand from a server and communicates with the origin server i.e. you cannot trust the DHTML application itself if you cannot trust the JSON returned form the server as it originates from the same server. How many users do "view source" and study the JavaScript code before trusting a DHTML application.

What I am trying to say is that any code loaded on demand, including a JSON parser cannot be trusted. It is for this reason no difference between using eval and using a JSON JavaScript parser when it comes to security.

I removed it because I consider is a spamlink. It is an example, but there are heaps of examples. Adding one example will only attract other links which has been the case with other similar articles. --Sleepyhead 08:20, 15 February 2006 (UTC)
That is an opinion.
BarracudaDrive is designed to be an example and a showcase for what is possible with HTTP, AJAX, etc. The search is a particular good example as it shows how much faster asynchronous RPC can be made using JSON than with SOAP. BarracudaDrive is also a good platform for users that are interested in experimenting with the JSON server API. Personally, I do not think you should remove any links. What gives you the right to act as the police and censor what other readers may find useful? There is already a lot of spam in the JSON article and many statements that are not necessarily correct.

[edit] JSON and YAML

Can anyone compare JSON and YAML?

Ruby on Rails NPOV?: Right now, part of the article reads:
  • YAML, the data serialization language favored by the Ruby programming language...
  • ...makes for quite elegant integrations between Rails and Javascript.

I was unfamiliar with YAML, and this gave me the false impression that it was a "Ruby thing". After poking around on YAML.ORG, I see that it's not Ruby specific at all. YAML.ORG's front page makes mention of "scripting languages such as Perl and Python" but Ruby is not mentioned up front (by name). Mentioning Ruby on Rails in this context doesn't look very NPOV. If there's a good NPOV reason that Ruby and RoR should be mentioned in this JSON article, please let us know. If not, I'm going to pull those references next week (unless someone does it before I do). -Gamol 05:01, 3 December 2005 (UTC)

It seems to me that you've probably misunderstood the article. As I understand it, the standard Ruby libraries fully support YAML, and furthermore that this can be said for very few if any other comparable languages. If it is true (or if it later becomes true) of some other comparable language, then the article can accordingly be modified. In the meantime, therefore, it seems to me appropriate to retain the reference, given that JSON is a subset of YAML. Peak 06:55, 3 December 2005 (UTC)
I don't think I've misunderstood the article as it is written. After doing some reading, I have a recommendation I feel quite sure about.
As I understand it, Ruby has used YAML as its "de facto serialization format .... since 1.8" (YAML wiki ref). Now since YAML is (by lucky coincidence) is a superset of JSON, Ruby programmers can use JSON almost as if it's a native data type. This is very cool and--I agree--worthy of mention. The problem I see now is that the article introduces and defines YAML in terms of its relationship to Ruby. I still feel that this is misleading. YAML.ORG and Wikipedia's own YAML article don't do this because, although it's integrated nicely with Ruby, YAML is not Ruby specific.
I think it's more appropriate to define YAML in terms of its relationship to JSON. Then, mention the Ruby integration afterwards. Give this a read:
YAML, another data serialization and lightweight markup language, is a superset of JSON. YAML can be thought of as JSON with a handful of extended data types. JSON is much easier to parse, though[1]. Although coincidental, this relationship means that YAML tools can process JSON data. The Ruby language, which uses YAML as its built-in serialization format, can handle JSON like a native data type.
Now I'm not a Ruby programmer (yet), so I'm not sure my use of "native data type" is wholly appropriate but I think the paragraph should be changed so that it reads something like the above text.-Gamol 13:50, 3 December 2005 (UTC)
Perhaps you missed a small change I made in the intro, that introduces YAML as an extension of JSON. Anyway, your basic proposal is fine, but perhaps the wording would benefit from a bit more research. In the meantime, please consider this:
Some of the limitations of JSON are addressed by YAML, which is a superset of JSON. Although JSON is significantly simpler than YAML[1], YAML is still considered lightweight. The Ruby programming language uses YAML as its de facto serialization format and can therefore handle JSON.
By the way, I am not sure that YAML is usefully considered a markup language (They don't call it 'YAML ain't Markup Language' for nothing :-) Perhaps the articles on JSON and YAML can be strengthened by explaining their superiority as "data interchange" languages compared to vanilla XML.Peak 19:26, 3 December 2005 (UTC)
P.S. I just noticed that the article List of lightweight markup languages states categorically that JSON and YAML are not markup languages. Perhaps the point of confusion is the difference between being a ML versus being used as a ML? Peak 20:39, 3 December 2005 (UTC)
Hmm, I got that "lightweight markup language" part from the (apparently) underdeveloped YAML article itself. Knowing this, I would have written "lightweight serialization syntax". I liked your last paragraph much better than the one in the article so I made that change. -Gamol 11:01, 6 December 2005 (UTC)

I would like to see the YAML/JSON relationship fleshed out in the future. Right now, readers can see that YAML is a superset of JSON and reasonably conclude that YAML was based on JSON (when in fact, the superset/subset relationship is coincidental). Also, some readers might miss the implications of this. I think it would be helpful to spell out that, because of this relationship, any YAML parser can be used to deal with JSON data structures (because strictly speaking, they're JSON parsers too). -Gamol 11:01, 6 December 2005 (UTC)

No-one has remedied any of the problems with this section. As it is now (Sept 2006), it is poorly written. In fact it almost makes no sense, because it says "The Ruby programming language uses YAML as its de facto serialization format and can therefore handle JSON with particular ease" without ever mentioning the subset/superset relationship. Nothing in the section, or elsewhere in the article, bears out the "therefore" part of that sentence.

To maintian a neutral POV this article needs to have the outspoken critics view that eval()ing code sent from the server is not a good thing. See http://blogs.ebusiness-apps.com/jordan/index.php/17/. I would modify this article myself, but I just found out what JSON is this morning. - Jay Buffington 16:41, 20 October 2005 (UTC)

This is an incendiary opinion article on why XML is better than JSON, not on the relative security of evaling JSON sent from a server. The assertion still stands: without cross-domain access (disabled by default), if you cannot trust the JSON coming over the XMLHttpRequest, then you can't trust the page itself, as both are guaranteed to be coming from the same source. capnmidnight 15:54, 5 December 2006 (UTC)

YAML is not a subset, superset, anything related to JSON other than that both seek to be lighter, simpler alternatives to using XML. Don't let the fact that you can write files that are equally parsable by JSON and YAML parsers fool you.

I was going to comment on the exact same thing: the syntax of YAML is certainly not a superset of JSON, so saying that YAML is a superset of JSON is very confusing. Possibly, YAML is functionally a superset of JSON? In that case, we should change the formulation. --Ebruchez 13:27, 2 June 2006 (UTC)

answer: see YAML. In a nutshell, JSON is a small subset of YAML. Any JSON document can be parsed by YAML, after striping out the block comment tags. Both YAML and JSON are based around the representation of data structures by hierarchies of maps, arrays and scalars. JSON format is basically a special use case in YAML that is convenient and vertically compact when one does not care about human legibility. In general YAML users prefer the standard YAML syntax which avoids having to enclose things in braces and quotation marks. For example both of the following are valid syntax for a YAML map. One of these is also valid syntax for JSON which is why YAML can read JSON but not vica versa. The first form is the "preferred" yaml style for most situations, though the vertical compression of the JSON-style is sometimes handy.

name:  john smith
age:     13

and

{ "name": "john smith", "age": 13 }

YAML specifies many datatypes beyond JAVASCRIPT primitives like floats, ints, and strings: for example, binary, ordermaps, timestamps, and user defined classes. Also it has anchor and references so that duplicate data need not be redundantly entered. Likewise arrays in YAML can either be like JSON which uses brackets [], quotes, and commas, or it can use the YAML indented form that avoids those enclosures. —Preceding unsigned comment added by Cems2 (talk • contribs) 11:13, 20 July 2007

[edit] Security risk?

As kind of implied in the comment above, doesn't eval()ing code from another server require that you have absolute trust in the "data" source? I mean, in the example code on the article, anyone who can insert content into http://example.net/this/is/a/fake/url/ can execute whatever JavaScript code they want, in the context of the website "receiving" the data.

Obviously, it's not impossible to trust the "data" source (and I saw somewhere that XMLHttpRequest() can only retrieve from the same server), but surely the importance of doing so should be mentionned very explicitly in the article. Or is there something I'm missing? - IMSoP 13:00, 4 November 2005 (UTC)

XMLHttpRequests are bound by the Same origin policy. But it is possible to load JSON objects using a proxy or other techniques. Now about evaling potentially dangerous code: I agree that this should get some mention. Perhaps the gist of the additional material could read:
If you're loading data from your server there shouldn't be a problem (and if there is a problem, you've got a serious issue that has nothing to do with JSON). But if you're using any of the techniques that can load data from a server you don't have control over, you are putting your trust in whoever's running that server. If, for some reason, you are loading JSON from a source you don't trust (WHY ARE YOU DOING THAT!?), you should validate the code before evaling it (by checking for function calls that shouldn't be there, etc).
...or something along those lines. - Gamol 08:17, 24 November 2005 (UTC)
OK, I've gone ahead and added a subsection on this. Incidentally, I came up with a reason this might end up happening - with people talking of JSON as an alternative to XML, imagine something like RSS being translated into JSON; then imagine people making "JSON/RSS" readers that blithely eval() code from Joe Random Hacker's blog... I think this is a rather important limitation of JSON as compared to a "proper" data format like XML (or rather, a flaw in its widely used parser and selling point, the eval() function). - IMSoP 20:49, 29 November 2005 (UTC)
> imagine something like RSS being translated into JSON
Actually, I forgot about JavaScript feeds. People are doing this sort of thing and they're doing it in a way that doesn't let them validate the foreign data. At least if they were using JSON, they could vet the info and make JavaScript feeds safer. I'm sure there's some your-site-is-in-danger security warning about these but I haven't heard of any serious exploits via the practice. Here's some JS feed sites: The Scotsman, RSS-to-JavaScript, some Google results.-Gamol 04:04, 7 December 2005 (UTC)

[edit] JSONT

I inserted a link to my article about JSONT. The combination JSON/JSONT can be seen as roughly equivalent to XML/XSLT.

JSONT

If you think it is closely related to JSON, I could write some more about JSONT.

If you don't think so, feel free to also remove the link.

Meanwhile there is also a link from json.org to JSONT.

--

Stefan Gössner

well ok, it doesn't seem to fit.

[edit] History

Where is the history section? Who coined the term, etc.? 70.20.193.90 19:05, 2 July 2006 (UTC)

A month later, and I'm still trying to figure out where "JSON" came from. Who started the spec? And why doesn't this article mention him/her??? 70.20.147.17 03:33, 1 August 2006 (UTC)

I partly answer your question with a couple of sentences with info about JSON specifications and roots. Right now it's the second paragraph. --Gosub 22:23, 9 September 2006 (UTC)
Douglas Crockford might be worth mentioning as his page claims he created it. 207.126.230.225 22:59, 24 October 2006 (UTC)

[edit] Cross-site request forgery

User:69.232.196.25 wrote (on the article page, moved here):

This section is not concerned with JSON. It does not belong in this article. It is concerned with a misuse of the HTML script tag. It also recommends an incorrect solution to the problem. The correct solution is for the server to be more discriminating as to where it sends passwords and other sensitive data.

I assume the IP failed to understand the issue; perhaps it could be explained better? The attack works as follows:

  1. Alice logs into her webmail, run by Bob
    1. Bob sends Alice a session cookie
  2. Alice's web client uses the session cookie to retrieve her emails
    1. Bob sends Alice an AJAX page
    2. Bob's AJAX page, running in Alice's web client, sends a JSON request
    3. Bob responds to the request, sending the data to Alice
  3. Edgar sends Alice an email containing a link (free porn, perhaps)
  4. Alice clicks the link and goes to Edgar's web site
  5. Edgar's web page contains a script tag pointing at a URL on Bob's webmail site
  6. Alice's web client follows the script tag
  7. Bob's webmail site validates Edgar's request (because Alice's web client sent the session cookie) and responds with JSON
  8. Edgar's web page, having peeked into the JSON from Bob's webmail, has been able to read Alice's email and sends that email to Edgar.

--EdC 01:11, 17 December 2006 (UTC)

Note that:
  • the person who is misusing the script tag is the attacker, so neither the web services provider nor the user can do anything about it
  • Alice may know not to click links in emails; that won't help, as an alternate attack scenario is to pollute a high-traffic web site (e.g. Slashdot) and hope that some of the visitors are logged into GMail (which they will be)
  • "The correct solution is for the server to be more discriminating as to where it sends passwords and other sensitive data" — how? The server is sending data to the victim's web client, which has requested that data with a currently valid session cookie.
--EdC 01:26, 17 December 2006 (UTC)

[edit] JSON vs XML

"XML is however a markup language and is thus significantly more complex than JSON, which is specifically designed as a data interchange format, not a markup language"

I don't follow this reasoning. Markup languages are not more complicated by definition over data interchange formats. The two are also not mutually exclusive -- XML is a markup language designed for data interchange.

As to complexity:

  {
      "firstName": "John",
      "lastName": "Smith",
      "address": {
          "city": "New York, NY",
          "zipCode": 10021,
          "streetAddress": "21 2nd Street"
      },
      "phoneNumbers": [
          "212 732-1234",
          "646 123-4567"
      ]
  }

vs.

 <person>
    <firstName>John</firstName>
    <lastName>Smith</lastName>
    <address>
       <city>New York, NY</city>
       <zipCode>10021</zipCode>
       <streetAddress>21 2nd Street</streetAddress>
    </address>
    <phoneNumbers>
       <phoneNumber>212 732-1234</phoneNumber>
       <phoneNumber>212 732-1234</phoneNumber>
    </phoneNumbers>
  </person>


I'll grant you that XML is more verbose, but 'significantly more complex'? 209.131.211.194 18:52, 20 December 2006 (UTC)

To enhance your statement, XML is for eXtensible Markup Language. --80.217.189.168 19:14, 26 January 2007 (UTC)
  • For the human eye the complexity between both languages isn't much different, specially in your example which isn't really a valid XML document and only covers extremely basic XML features. On the other hand, if you want to write a parser then JSON will be a lot easier to parse than XML. I'm writing a JSON parser and the finite state machine to read a JSON document DOM-style has less than 40 states, being the bulk for parsing the number value alone. do you care to know the order of magnitude of states a FSM to completely parse a XML document, with namespaces and all? Hundreds, if not thousands. --Mecanismo | Talk 13:59, 10 June 2007 (UTC)
  • No need for your XML parser to support XML Namespace if you don't want to, especially when it comes to comparison with JSON. Your point still stands on the matter of doctype declarations, which are needed to be a valid parser, though. 82.66.241.96 09:33, 25 June 2007 (UTC)

[edit] JSON and AJAX isn't "compatible"

The page states that JSON and AJAX is commonly used together over AJAX and XML. AJAX means "Asynchronous JavaScript And XML".

Do I get my point across? Oh and, Ajax is commonly used to refer to the cleaning soap. --80.217.189.168 19:12, 26 January 2007 (UTC)

If the point you're trying to get across is that you're a humourless pedant, then yes, you have succeeded. The article states that JSON is an alternative to XML in AJAX; could it be any clearer? –EdC 21:34, 26 January 2007 (UTC)
EdC, please remember to stay civil. Thank you. Let me attempt to paraphrase the anon's comment. I believe what that person is saying is that you can not have "AJAX" without "XML". Therefore, using JSON in lieu of XML makes it no longer AJAX, but something totally other. Given that, the sentence is somewhat confusing. I tend to agree with the anon in this. -- ShinmaWa(talk) 19:20, 25 March 2007 (UTC)
  • I do believe that this "compatibility" debate is pontless. AJAX may be an acronym for "asynchronous JavaScript and XML" but it represents a way to develop web applications, not concrete methods. It's the same thing as claiming that you can't have a LAMP stack if you use postgresql --Mecanismo | Talk 14:12, 10 June 2007 (UTC)

[edit] JSON and Python

JSON does not 'happen to be' a subset of Python: for starters, 'true' and 'false' have capitals in Python. The claim about eval() in Python being useful for JSON should go until somebody takes the time to find all differences between JSON and valid Python. And, as said by others, eval() is unwise anyway, especially in a non-sandboxed language like Python. --Habbie 11:29, 20 February 2007 (UTC)

[edit] Why JSON?

Why programmers call it JSON? (Javascript Object Notation) JSON is an incomplete copy of ECMA-262 and not as it should be.

Stop once and for all call in it JSON, and call it as it is. Literal Javascript which is far more than JSON. Read the Javascript ECMA-262 You'll find it easier to understand than as a sole concept not as JSON.

Understand the Object Oriented Nature of Javascript and understand that ... to start ... The correct use of Javascript is Literal Javascript What is it for? Simple ... Javascript was designed with a concept of inline porgramming.

So when you understand the structure of Javascript you will understand that the correct use of Javascript is literal, and talking about JSON is an incorrect, absurd concept.

Simple diffences like

for Javascript {key:value} or {"key":value} are the same for JSON only {"key":value} is correct

for javascript var x= 0005; is correct for JSON only var x = 5;

                                             JSON !== Javascript

So is it clear? literal Javascript === Javascript

literal javascript is only another way (the correct way for web programming) to use javascript

  as it is   x  [ "y" ] = value  or   x.y=value  <- this is liteal javascript in Javascript, don't call it JSON.
  as it is  x [ "y" ] = value   or  x={Y:value} <- this is literal javascript too, not JSON

—The preceding unsigned comment was added by 216.62.70.35 (talk • contribs).

OK, I can't say I entirely understand all the points you're trying to make here, but the one phrase that stands out (both visually and intellectually) is "JSON !== Javascript". Now, presumably, you are under the impression that some people are claiming that this is not true, and that JSON is JavaScript; that's not the impression I got - the 'J' in the name stands for 'JavaScript' because that is it's origin, and as the article states: "JSON is a subset of the object literal notation of JavaScript and is commonly used with that language."
If you're trying to say "there are ways of writing data structures in JavaScript that are not JSON" then yes, absolutely; that's what "subset" means. Why this means that "talking about JSON is an incorrect, absurd concept" I honestly have no idea. If anything, it makes the term all the more necessary, because we need some way of talking about the data format without mentionning the language; if you prefer, think of the JS as meaning "JavaScript-like". - IMSoP 20:00, 25 March 2007 (UTC)
I think he is merely pointing out that it is silly to be calling "JSON" it's own data format. Object literals, the basis for JSON, were a conciously built in feature of Javascript/ECMAScript. It's like keeping data in a C Array, sending that C Array to a server, and claiming you have created a new data exchange format: all you've done is send C to a server. "JSON" is simply sending Javascript to a server. Javascript is Javascript, no matter how it is parsed. I concur with his post, it is silly to give a feature of javascript an entirely new name like this. - Gavin86 11 May 2007
JSON may be valid JavaScript, but not all JavaScript is valid JSON. If you contend that it is "silly" to give JSON a name, then how will you describe the kind of data that you are sending over the network / storing in a file / etc.? "JavaScript object notation", I hear you say? Congratulations, you have just reinvented the name. Shinobu 23:23, 13 May 2007 (UTC)
Meh. I still think it is silly. They just force the use of quotation marks. And nah, I wouldn't say JSON, I would say, "I am sending object literals". Not a huge deal, I just think it's silly Gavin 23:13, 15 May 2007 (UTC)
It doesn't really matter whether you think JSON is a good name or a bad name. This is what it is officially called, so this is what WikiPedia must document. Now, as far as JSON goes, it is important for it to have a name since it really is a separate and distinct "language", regardless of it's similarity to JavaScript. It has a distinct MIME type, a different intentended purpose, a different standardization path. And keep in mind that at this point JSON is used as a generic data format in systems that don't use a shred of JavaScript code; and also that JSON does differ from JavaScript in some other minor aspects as well, such as the numeric semantics or the permissible white space characters. So JSON, although similar to and based upon JavaScript, truely is a separate language. - Dmeranda 16:55, 16 May 2007 (UTC)
Consider an analogous situation: the XBM image format, which is a proper subset of the C language. Just because XBM is C code, using literals, doesn't mean the separate name XBM wasn't useful. The same argument can be applied with JSON and JavaScript. - Dmeranda
  • Sir, you are totally clueless. JSON is not JavaScript. JSON may have arise from JavaScript but it isn't JavaScript. JSON is a very light markup language. Is JavaScript a markup language? No. Is JSON a scripting language? No. So how can they both be the same thing? They can't. --Mecanismo | Talk 14:05, 10 June 2007 (UTC)
If anyone out there wants to "invent" PSON (Perl-Style Object Notation), CShON (CSharp Object Notation), ConFUSiON (ColdFusion-style Object Notation), XSySON (XML-style Object Notation) or any other similar notation for any known or yet-to-be-invented programming, scripting or markup language ... too late, I hereby declare my inventions to the public.
The specifications are as follows: a subset of the already-made specifications for the already-made aforementioned languages, using just a proper subset of the relevant specifications to represent data structures of type: 'list', 'mapping', 'string', 'true','false','null','integer','float', and any other built-in intrinsic type of any 3GL or 4GL programming language, and any combination thereof.
I would have declared JSON and the rest of my inventions back in 1995, but I have to give recognition to Doug Crockford, since it never occurred to me that I could take credit for "inventing" something that was already available as a pattern of sensible coding practice in any given language.
Now that my inventions have been declared, I request that you wait for them to become acknowledged by mainstream reliable sources before writing Wikipedia articles about them. This exciting breakthrough, although destined to change the course of history, still must be treated like any other article topic. Thank you. dr.ef.tymac 18:54, 5 October 2007 (UTC)

[edit] 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)

[edit] 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)

[edit] Comparison

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)

[edit] 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)

[edit] 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)

[edit] 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)