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

Wed May 6 19:02:06 CDT 2009

Sam,

Painting this as a mere difference between angle brackets or curly braces
trivializes or avoids the central problem: the very tools you cite as
advantages of XML are, in my opinion, merely symptoms of the complexity
inherent in using XML, especially in the so-called "enterprise
environment".  The question of maturity seems to be entirely about those
same tools, rather than about any concerns about JSON being a moving target
(it isn't).

Sun has provided a compelling example of how to use JSON in the construction
of a simple, RESTful cloud interface, yet all your arguments against it are
nebulous.  What _specific_ thing is it you believe meets these criteria:
 1) Is a concrete requirement of the core interface
 2) Is possible with XML (without dragging in the very baggage that has sunk
so many other "enterprise" protocols based on it)
 3) Is not possible with JSON

I am not talking nice-to-haves, here.  I mean real, protocol can't function
without it stuff, because if the core protocol _can_ function without a
feature, why on earth would you put it in?  I recommend the following
exercise:  divide the features into "definitely need right now", "might need
at some point", "definitely won't need".  Discard all but the first category
in creating the core protocol, compare the result to the Sun API, smile with
recognition, adopt it as the base, move on.

Ben

On Wed, May 6, 2009 at 4:42 PM, Sam Johnston <samj at samj.net> wrote:

> 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
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090506/dffb30f5/attachment.html 