openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

>
> 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? ;-)