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.
Here’s an example from the now deprecated Google SOAP interface. The equivalent in JSON-RPC would be:
{ "method": "googleGateway.search", "params": [ "absurd obfuscation", 0, 10, 1, "", "", 0, "latin1", "latin1", "00000000000000000000000000000000" ] }
Alternately, if one wishes to preserve the named parameter association of the original SOAP interface, you would end up with something like this:
{ "method": "doGoogleSearch", "params": [ { "key": "00000000000000000000000000000000", "q": "absurd obfuscation", "start": 0, "maxResults": 10, "filter": "true", "restrict": "", "safeSearch": "false", "lr" : "", "ie": "latin1", "oe": "latin1" } ] }
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?
I created it. I’m not satisfied with the sharpness of the angles in the “eye”, so I may go back later and tweak it some more.
Sam,
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)?
Thanks,
Jeff
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.
Are you ever going to have a second element in the params array?
Beat me to it; I was just gonna say the same.
I think the second example is bogus.
I was just trying to follow the specification.
What tool do you use to create your SVG images?
vim. I’ve been known to prototype using InkScape, but I see no need for seven digits of precision. I’ve also used potrace at times, but take a look at what it does to the JSON icon.
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.
I was just trying to follow the specification.
Ah. I am not sure JSON-RPC vs. XML-RPC is an interesting use case for a comparison of JSON and XML.
Meanwhile, if you are using FireFox, compare this and this.
Weird. File a bug? And it’s “Firefox”.
“I was just trying to follow the specification.”
It looks like JSON-RPC 1.1 will be much closer to what you were thinking.
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.