Re: [xml-dev] json v. xml

["David Megginson" <david.megginson@gmail.com>]

On 05/01/07, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com>

> I've heard it alleged
> that among the other attractions of JSON is that typical browser security
> policies allow one to do cross-site retrieval of JavaScript in
> circumstances where XML retrieval would be disallowed.  Two questions:
>
> 1. Is this true?

No, that's not accurate -- there was a misunderstanding in some blogs,
but I think it's been cleared up now.  We're talking about two
separate issues:

1. It's possible to work around the cross-site limitations of
XMLHTTPRequest using iFrames or the On-Demand JavaScript pattern.

2. JSON is the data-representation format most commonly used with the
on-demand pattern, because it is the most convenient.

That's *not* the same as saying that JSON allows cross-domain
retrieval.  While it will be less convenient, you can use XML, CSV, or
any other text-based format with the on-demand pattern (which involves
splicing an external script with inline data declarations onto your
document's own DOM tree so that it looks like it came from your
domain), just as you can use JSON or CSV instead of XML with
XMLHTTPRequest.

> 2. If so, am I the only one who thinks this is bizarre?  Whatever the
> history of these policies, we have a situation in which information
> transmitted in the form of an executable Turing-complete programming
> language (JavaScript) are allowed, but in which information in the form of
> a declarative markup language are blocked as a security risk?

Not so.  Both JSON and XML are blocked if you're using XMLHttpRequest,
and both are possible (by accident rather than by design) if you use
the On-Demand JavaScript pattern.

Note also that like XML, JSON is purely declarative and (thus) not
Turing-complete -- to make JSON executable, you have to wrap it with
JavaScript, just as you would have to wrap XML to make it executable.
It just happens that the wrapping is more convenient with JSON.

I strongly recommend that everyone read the very short JSON spec and
grammar productions at www.json.org to understand what JSON is (and
isn't).


All the best,


David