<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">When you're designing JSON considering only JSON, you'd probably use {</div></blockquote><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

key1: value1 } - as you have done.  If you're designing generically,<br>
you'd probably use { key: key1, value: value1 }.<br>
</blockquote>
<br></div>
You mean we'd have to do dumb crap because XML doesn't have the native concept of a list? ;)</blockquote><div><br></div><div>XML has lists, as does Avro, ProtocolBuffers & Thrift.  XML supports extensible lists, which is why the syntax is different.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You'd *think* this would work. In practice, however, it really doesn't. Neither does (good, valid) code generation...</blockquote></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>If you think it doesn't work, can you provide an example?</div><div><br></div><div>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.)</div>
<div><br></div><div>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.</div><div><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...</div></blockquote><div><br>
</div><div>Are JSON schemas an April Fool's joke?  Once you introduce schemas, you might as well just go with XML ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> I think the only thing you need to avoid is<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"no changing-at-runtime keys"; I think this makes it compatible<br>
with XML, Avro, ProtocolBuffers & Thrift.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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...</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?)</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Incidentally, I just heard about yet another new format - apparently<br>
this one is going to be the standard for use with node.js<br>
- Hypertext-Powered-State-<u></u>Transfer-Representation.<br>
</blockquote>
<br></div>
HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)<br></blockquote><div><br></div><div>Are you sure it wasn't mine? ;-)</div><div><br></div></div>