openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

Justin,

>From a JAX-RS / Java  persecutive, starting with an XML schema and having that dictate what the JSON will look like -- doesn't just make sense -- it makes life *A LOT* easier. And a lot of services written in Java do just that.   Unfortunately, as you pointed out, this approach has the  tendency to create very  unJSONic JSON -- in that case JSON is just an afterthought..it's a second class citizen -- essentially it's XML with curly braces...and that doesn't jive well with dynamic languages.

You can go the other route and start from JSON to create XML -- and some well intended folks do this, but you end up in the other direction...essentially you have <JSON/>, which is essentially JSON in XML form.  That kind of XML sucks and it's pretty useless if you work with static languages like Java and .Net -- where having a static (but extensible) schema is really useful.

That's the world we live in today...static languages work really well with XML and dynamic languages work really well with JSON.  In my opinion, you have to account for both and treat both as first class citizens.   I'd vote for having an abstract model and treat the XML and JSON  as different renderings.   Doing so is not easy as pie -- but it's not rocket science either.

I am totally with you on a couple of points though:

1.  We do need to differentiate between user data and core attributes. Jay and I have had debates about this before.
2.  Having entirely dynamic discoverable schema, seems nice, but it has the potential to introduce a lot of complexity.   In particular, i'm not exactly sure how to process the schema and  keep the goodness that comes from using a statically typed language.   And, as you point out,  it's not clear how one would support multiple media types given that approach.

How about we discuss this further at the summit :-)

-jOrGe W.


On Apr 9, 2012, at 4:14 PM, Justin Santa Barbara wrote:

When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done.  If you're designing generically,
you'd probably use { key: key1, value: value1 }.

You mean we'd have to do dumb crap because XML doesn't have the native concept of a list? ;)

XML has lists, as does Avro, ProtocolBuffers & Thrift.  XML supports extensible lists, which is why the syntax is different.


You'd *think* this would work. In practice, however, it really doesn't. Neither does (good, valid) code generation...

Of course it works!  Every JAX-RS webserver does this.  You just can't start with JSON first and expect everything to magically be OK.

If you think it doesn't work, can you provide an example?

You start with an abstract model, and then check what it looks like in JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR, etc...  If you start with JSON, then of course it won't work.  If we're going to treat XML as an afterthought, then I'd rather we just didn't support XML at all (and yes, I absolutely mean that - it is good that Glance is honest that they don't support XML.)

Even ignoring XML, I can't help but think that not having a strict delineation between user-provided data and the structure of your document is a pretty risky idea.


In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...

Are JSON schemas an April Fool's joke?  Once you introduce schemas, you might as well just go with XML ;-)

> I think the only thing you need to avoid is
"no changing-at-runtime keys"; I think this makes it compatible
with XML, Avro, ProtocolBuffers & Thrift.

That is antithetical to having dynamic, but discoverable, schemas. JSON Schema (and XSD, fwiw) provide things like additionalProperties and <xsd:any> for just this sort of thing. Making a schema entirely static is really only useful for generating (bad and soon-to-be-outdated) client code.

Having dynamic and discoverable schemas enables clients to respond to backwards-compatible schema changes (like the addition of standard properties or the addition of "extra-standard" additionalProperties) without having to recompile a client or change any client code at all...

I couldn't disagree more: "what does it mean"?  There's the implicit contract underlying the interface; the semantics that underpin the syntax.  e.g. syntax: a glance image id is a string, semantics: the id is unique to a glance installation and is used to refer to an image in REST calls.

xsd:any allows you to put elements _from another schema_ into your XML document.  That foreign schema defines the semantics of those elements.  It's schemas all the way down, giving semantics to your syntax.

If your additional properties in Glance are properly schematized, then that's great.  But true cross-representation schemas are an open problem, I believe, so you're really painting yourself into a corner (how do you support XML output, if you let people upload arbitrary JSON schemas?)


Incidentally, I just heard about yet another new format - apparently
this one is going to be the standard for use with node.js
- Hypertext-Powered-State-Transfer-Representation.

HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)

Are you sure it wasn't mine? ;-)

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp