openstack team mailing list archive

[George Reese <george.reese@xxxxxxxxxxxxx>]

A lot of the arguments against both XML and JSON seem to boil down to "here's why XML sucks..."

The reality is, for whatever reason, good or bad, a lot of people prefer to parse complex data in XML. There's a big market for it. Supporting both formats doesn't add horrible complexity.

-George

On Jun 2, 2011, at 11:41 PM, Mark Nottingham wrote:

> The problem I mentioned before, though, is that XML Schema brings more issues to the table than it solves.
> 
> 1) People inevitably use schema to generate bindings to [insert language], and because of the complexity of the underlying data model of XML (Infoset), the mapping of information items to objects can happen in a variety of different ways. This is an endless source of bugs.
> 
> 2) It's very, very hard to define an XML Schema that's reasonably extensible; unless you use exactly the right design patterns in your schema (which are absurdly convoluted, btw), you'll end up locking out future backwards-compatible changes. The authority in this space is Dave Orchard; see his conclusions at  <http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSchemaEvolution.html>.
> 
> 3) An XML Schema can never express all of the constraints on the format. So, you'll still need to document those that aren't captured in the schema.
> 
> I suppose the central question is what people are using the schema for. If it's just to document the format, that's great; we can have a discussion about how to do that. If they're using it for databinding, I'd suggest that JSON is far superior, as a separate databinding step isn't needed. Finally, if they're using it for runtime validation, I'd agree with Jay below; it's much easier to use json parse + runtime value checks for validation (especially in HTTP, where clients always have to be ready for errors anyway).
> 
> Just my .02.
> 
> Cheers,
> 
> 
> On 03/06/2011, at 5:20 AM, Jorge Williams wrote:
> 
>> It's not just about the service itself  validating it, its as Joseph said, making sure that the data structures themselves are documented in detail to the client.  To my knowledge there is no accepted schema language in JSON  though JSON schema is starting to catch on.
>> 
>> At the end of the day it should be a matter of providing our customers with a representation that they can readily use.  It could be that my perception is wrong, but it seems to me that there's support for both representations.   I'll try to get some data to back this up.
>> 
>> -jOrGe W.
>> 
>> 
>> On Jun 2, 2011, at 2:00 PM, Jay Pipes wrote:
>> 
>>> On Thu, Jun 2, 2011 at 1:54 PM, Rick Clark <rick@xxxxxxxxxxxxx> wrote:
>>>> Hi All,
>>>> Is it required for new openstack API's to support both JSON and XML, or
>>>> would it be acceptable to only support JSON?
>>> 
>>> Glance currently does not support XML and I have no plans in the
>>> immediate future to add support for it.
>>> 
>>> IMHO, JSON can be validated just as easily as XML. Simply
>>> json.loads(req.body) and then, if parsing succeeds, compare the
>>> mapping against a model. No need for XSDs, WADLs, or any other
>>> acronym.
>>> 
>>> -jay
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

--
George Reese - Chief Technology Officer, enStratus
e: george.reese@xxxxxxxxxxxxx    t: @GeorgeReese    p: +1.207.956.0217    f: +1.612.338.5041
enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese

Attachment: smime.p7s
Description: S/MIME cryptographic signature