I find it amusing that in all of the recent JSON[-RPC] vs XML[-RPC] discussion, I see a lot of opinions, but I don’t see a single instance where the actual wire level bits were examined, let alone be analyzed.
I’ve seen enough character encoding errors in allegedly XML content to say that unlike Tim, I don’t see that as a slam-dunk reason to prefer XML in order to improve your chances for interop on the web.
The advantage I see to JSON is when you don’t really have a need to be redundantly self-descriptive, an example being Planet Intertwingly’s memes.json.
And now the important question, where did you get the SVG version of the JSON logo? ;)
What tool do you use to create your SVG images? I notice how clean your inline SVG is - are you later stripping it after some tool generates it for you (like Inkscape, etc)?
Also, do you mind if I ask why you prefer inline SVG in HTML over using the HTML:object tag and providing fallback content (rasters)?
I think the second example is bogus. Are you ever going to have a second element in the params array? JSON loses the named root element, and that feels uncomfortable for some people.
<doGoogleSearch><q>foo</q></doGoogleSearch>
in JSON
{"doGoogleSearch":{"q":"foo"}}
but, adding that extra root object seems weird.
{"q":"foo"}
feels better. It’s the root element name that JSON has a hard time making natural.
Also, do you mind if I ask why you prefer inline SVG in HTML over using the HTML:object tag and providing fallback content (rasters)?
My images tend to be less than 1K (this one is 499 bytes). Providing a fall-back simultaneously requires more work on my part, increases my page size, increases the load on my server, and reduces the incentive for browser makers to support SVG natively. And in the case of lynx, doesn’t help anyway.
Meanwhile, if you are using FireFox, compare this and this.
There has been a fair amount of hype/discussion recently over the fairly new JSON format. JSON is a lightweight data-interchange format based on a subset of the JavaScript programming language. Since many people that read my blog do not program for...
xml is a markup. namespaces and DTD’s and DOM are just the entrance places to a huge labrynth of machinations designed to bend XML into being accessible in programmatic ways.
json is an object markup. theres a lot less impedance issues if you work in an object oriented programming environment.
i just dont see where the added complexity of xml is justified. as a programmer, i spend way way too much of my life writing XPath again and again and again to deserialize XML into objects. what is the point? those couple days a month when i can play with just json + javascript, its a loosely coupled heaven of web browser + server.
The last week or two has seen a flurry of discussion about the use of JSON in web apps vs. XML. Most folks have been coming at it from a developer’s point of view - asking which has better tool support or is less bandwidth...
Sam Ruby: Examining JSON Examining JSON -------------------------------------------------------------------------------- Sat 23 Dec 2006 at 02:50 I find it amusing that in all of the recent JSON[-RPC] vs XML[-RPC] discussion, I see a lot of...
Acesta este fitilul care ar putea declansa explozia unei noi generatii de aplicatii web. Asa se laudau initiatorii JSONRequest. Nu se exprimau chiar asa, dar era evident ca asa gandeau. Totusi, au trecut doi ani, iar JSONRequest este in continuare...