jorge.williams at rackspace
Apr 12, 2012, 5:28 PM
Post #34 of 36
Generally, I agree with a lot of what you're saying, but I want to point out a couple of things:
1. Static language folks gravitate to XML, not simply because they're invested in it, but because it solves a real problem:
In a static language, I want to to say something like:
myServer.name = "hello";
if I misspell "name"
myServer.nam = "hello";
I should see an error...if I assign it to an integer...
I should also see an error...
and I should see those errors at compile time or while I'm authoring my code if a have a good editor or IDE....I shouldn't have to wait until my program is run to catch those errors.
Sure, I can parse some JSON turn the result into a hashtable and if I'm using something like Scala, I can do this
myServer("name") = "hello"
but at that point, there's very little benefit to having a static language, because I don't have the assurances and guarantees that the language provides. So I don't see a lot of Java folks dealing with JSON in that manner. Most devs will need to build a class before hand. So, you decrease barriers for static language clients because there's a set of tools that can extract the relevant info from XML schema languages and generate a set of class files at compile time. There's nothing saying you can't do something similar with JSON, but those sort of tools aren't there yet.
2. Then there's the issue of extensibility....especially distributed extensibility. XML has that notion built in, JSON has no concept of it...and we are building extensible APIs. There are no standard way in JSON to introduce a new property without guaranteeing that there won't be clash. You've mention the need for namespaces in JSON precisely to deal with this sort of issue (http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json).
In the absence of a standard method, we're been using prefixes, which has worked out well, but most JSON tools don't know how to deal with them and they seem alien to folk that are used to using JSON day to day. This is a big deal because dynamic language folks are more likely to deal with the JSON directly...Static language folks are generally not dealing with XML in the same way. In XML, the notion of extensibility is build into parsers and data binding tools directly. Most folks don't have to worry too much about it. In fact extensible protocols like XMPP and Atom Pub generally benefit from the extensibility that's already built in: http://metajack.im/2010/02/01/json-versus-xml-not-as-simple-as-you-think/
Given that, if we're going to go the route of just picking one format, I think the fact that our API is extensible means that we might want to ask ourselves whether XML isn't a better fit :-)
Having said all of that, I realize that our devs are working in a dynamic language, and don't see a lot of value in XML. It's important to take that into consideration, but we should also be asking whether there's value to our current clients and potential clients. Like it or not, there's a lot of folks out there using static languages.
You're right in stating that if we had really good language bindings for Java and .Net, then issue #1 would essentially go away -- especially if we had language binding that was flexible enough to remove the need to go down to the HTTP level. Also, if the language binding itself was extensible we could also deal with issue 2. As things stand today though, I don't thing that we are even remotely there yet.
On Apr 12, 2012, at 2:58 PM, Mark Nottingham wrote:
> A little fuel for the fire / entertainment before the summit:
> On 10/04/2012, at 3:56 PM, Vishvananda Ishaya wrote:
>> On Apr 10, 2012, at 2:26 AM, Thierry Carrez wrote:
>>> Jay Pipes wrote:
>>>>> I take it you didn't attend the glorious JSON debate of a couple of
>>>>> summits ago :-)
>>>> Glorious it was indeed.
>>> I think the key quote was something like:
>>> "Please don't bastardize my JSON with your XML crap"
>> According to my twitter, the actual quote was: "Don't bring your XML filth into my JSON"
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
> Mark Nottingham
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp