[occi-wg] On repainting the bikeshed at the 11th hour...

[Sam Johnston]

Morning all,

So I've been on the road for the last half a dozen hours watching somewhat
of a debate has kick off as to whether we should continue to use angle
brackets (XML) to dice our data or start from scratch with curly braces
(JSON). Sure it's understandable given the previous
mess<http://stage.vambenepe.com/archives/700>(whereby literally dozens
of different "standards" were born only to end up
dead and dying) but that's essentially what it boils down to and it does
feel a lot like we've taken a trip back to
2006<http://www.oreillynet.com/xml/blog/2006/12/and_the_winner_of_the_json_vs.html>.
As one person pointed out in private it's clear there is now a good deal of
backlash against "XML/SOAP/complexity" - apparently enough to consider
wiping the slate clean of many years of hard (albeit thus far largely
futile) work.

I'm not particularly religious about the matter either way (my only vested
interest is in the time I've volunteered to date and what little I have left
in which to deliver results) but I do think the model is *far* more
important and worthy of detailed discussion than the protocol. I've seen
neither XML nor Atom impinge on anything we've needed to codify so far and
once you have to reach for a library (as you do in both cases) the machines
could talk pig latin to each other for all we care. The primary (and only
valid IMO) objection to XML is that it tends to be abused more often than
not, but zero examples of such abuse in our designs have been given and
we've agreed to limit ourselves to an essentially flat structure (that must
be able to be cleanly represented in alternative formats including JSON and
TXT) so this is a non-issue anyway.

Looking at the practicalities, XML is very mature with plenty of expertise
and tools (from editors to application accelerators/firewalls) available for
it while JSON is a rapidly developing new kid on the block (or is at least
perceived to be by enterprise users - and perception/marketing is half of
the battle). There are a lot of things we can do today with XML that we
can't [and may never be able to] do with JSON such as transparently
embedding supporting formats like OVF (which like it or not is going to have
its time in the sun), transforming it to whatever format(s) we like in a
mechanical, platform independent fashion and serialising, encrypting and
signing it (for storage, queueing, etc).

Atom itself is already arguably the single most successful "cloud" standard
with Google using it for pretty much every public facing interface (protocol
buffers are used under the covers for efficiency) and every feed on the web
is using it (or something like it). There is a good deal of overlap with
whatever domain specific language we might have invented ourselves (I know
because I tried this before [re]discovering Atom) and it is a better fit
than you might first think - feel free to go through the exercise if you
need to see for yourself. In terms of the future it's also far more
extensible in that adding new resources et al to a domain specific language
would almost certainly require us to reconvene to create OCCI 2.0, while
extensions can be safely implemented (and validated) without risk to the
rest of the spec; this is not something I see as being particularly well
handled with JSON now or any time soon. Furthermore, things we currently
take for granted behind the scenes with XML (like being able to pass around
a DOM object and have different components update it as necessary before
handing the result to a renderer) are not possible unless you happen to be
writing JavaScript (one of the only languages where JSON is a first class
citizen rather than a third party extension).

Given the current plan is to support multiple formats (even if we only
actually require one of them) while maintaining the ability to move
losslessly between them, there is nothing stopping us from shifting our
weight to the other foot if and when JSON matures. The web never mandated
the use of a single format so I don't see why we should start now (though
telling implementors they must support all of them is a tall order). In
terms of reaching a loose consensus I think the EH/GG guys will be satisfied
if we can get clean[er] transforms, Sun ought to be happy if we follow their
methodologies if not their exact protocol (e.g. single entry point,
"buttons" for state changes, etc.), Google may well get on board if we make
it easy for them and I'll be satisfied if I don't have to throw away a
substantial base of work already completed as well as the opportunity to use
the myriad existing XML/Atom/GData tools and clients (remembering a domain
specific language starts with exactly zero implementations).

Of course if someone *does* have a particularly strong fetish for curly
braces and cares to rewrite the spec as well as a reference implementation
and a bunch of transforms by next week then be my guest.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090507/7556a30d/attachment.html