About the choice of format, as much as I like XML and Atom specially,
Sorry about my low level of participation. Anyone who has worked with Sun engineers knows that in the weeks leading up to JavaOne, we're typically useless for anything external. In my case, I'm actually working on making a cloud-computing facility deployable. But a bunch of things have gone by that I should really comment on. [For those who don't know, I was co-editor of XML 1.0 and co-chair of the IETF Atom working group. So I like XML and Atom too.] 1. Background I am neither a supporter nor an opponent of this OCCI work. My personal opinion is that the best time to do standards is after there is experience with interoperable implementations; so on that basis this is too early. On the other hand, I'm aware that there may be market pressure for standards sooner than would be ideal, so this work might prove to be very useful. I'm amused that there are at least three organizations working on cloud interoperability standards before we have any experience with cloud interoperability, but that's the IT business. 2. Sun Position We are going to run with our CC-licensed REST API until we have some experience operating a cloud-computing service because we think we have a whole lot to learn about where the real pain points are. That API is *not* frozen. There are other parties also experimenting with using it as a front-end to various cloud-computing services. BTW, I saw a remark in some earlier email about the Creative-Commons licensing being a problem for someone who might want to use some or all of our API spec. That is very surprising to me; if it's going to be a problem for people we'd like to hear about it. Our idea was simply to make it clear that we assert no intellectual-property claims on the API itself. 3. General advice on making standards 3.1 Dare to do less. Consider Gall's Law. Try to hit 80/20 points. Build "The simplest thing that could possibly work". When in doubt, leave it out. Essentially all the technologies that have enjoyed widespread rapid adoption on the Internet have been initially lean and mean, and were criticized for being incomplete and insufficient. Also, this increases the chances that you get it done in time to be relevant. 3.2 No optional features. Every time, in a standard, you say "you can do this or you can do that", you lose interoperability. The best example is SQL; the committee, whenever they came to a fork in the road, took both paths. As a result, SQL compliance means essentially nothing in practical terms, and database vendors use SQL to lock in their customers. 4. Specific advice on multiple formats Don't do it. Pick one data format and stick with it. Look at the RFC series, which is the most successful set of protocol designs in the history of the universe. They do not rely on interoperable models, they rely on agreement on what bytes I send you and what bytes you send me and what the meanings of the fields are. Allowing multiple formats in general, or XML and JSON in particular, is actively harmful. It is very easy in XML to create formats that can't be represented reasonably in JSON, and JSON carries a bunch of useful semantics (lists, hashes) that require extra work to specify in XML. I have opinions on which formats are most useful for a cloud-computing protocol, but the choice isn't that important. What is important is to pick one and stick with it. See 3.2 above. 5. When to use XML 5.1 When the order of elements in the message might matter. 5.2 When you anticipate trouble dealing with i18n, and can't simply say "Use UTF-8". 5.3 When you have document-like constructs, e.g. <p>This <a href="/docs/policy"> is <em>important</em>.</p> <p>So is the discussion above.</p> That kind of thing can't be represented sanely in anything but XML. 6. When to use Atom 6.1 When you are usually dealing with ordered collections of resources. 6.2 When it's essential that every item have a human-readable title, a globally-unique identifier, and a time-stamp. 6.3 When you have to wrap up document-like content, e.g. blog posts or HTML pages. [Is it now obvious why we chose JSON?] 7. Suggested reading: 7.1 Architecture of the World Wide Web: http://www.w3.org/TR/webarch/ 7.2 Modeling is hard: http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax 7.3 On XML Language Design: http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design - Tim Bray, Sun Microsystems Distinguished Engineer, Director of Web Technologies +1-877-305-0889 Sun ext. 60561 AIM: MarkupPedant, Jabber: timbray@{gmail,jabber} http://www.tbray.org/ongoing/ http://twitter.com/timbray