[occi-wg] Is OCCI the HTTP of Cloud Computing?

[Tim Bray]

> 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