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 :
[email protected]<mailto:[email protected]>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
