IMO, defining an API by providing 1 example of the API is not really interoperable.
The point of defining a schema is to specify the 'contract' the API provider
will honor, so a developer coding against the API knows what to write
(for that particular message exchange).
As for extensibility, YANG [RFC 6020] is better than both XSD and RelaxNG at that.
XML namespaces may seem too heavyweight, but they solve extensibility
at the instance level. The JSON prefix solution doesn't seem nearly as robust.
Andy
-----Original Message-----
From: openstack-bounces+biermana=brocade.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+biermana=brocade.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of George Reese
Sent: Friday, June 03, 2011 2:37 AM
To: Mark Nottingham
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] XML and JSON for API's
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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
