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

Thu May 7 12:04:27 CDT 2009

Sam,

You are consistently switching back and forth between specification issues
and implementation issues in such a way that it is unclear if you recognize
the importance of keeping them independent.  That a _current_ implementation
uses a number of XML features in a certain way that is convenient for its
implementers does not mean we should force the use of XML on all
implementers.  Further, the notion that we can adopt XML, in large part for
those vague, enterprise users, and manage, against all evidence, to _not_
pull in all the XML bells and whistles (meaning: keep it lightweight)
boggles the mind.  If the OCCI charter requires it to do such things, the
charter should be changed.

I am not religiously against XML, I am religiously in favor of simplicity.

Ben

On Thu, May 7, 2009 at 6:21 AM, Sam Johnston <samj at samj.net> wrote:

> On 5/7/09, Alexis Richardson <alexis.richardson at gmail.com> wrote:
> > Morning Sam,
> >
> > On Thu, May 7, 2009 at 12:42 AM, 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).
> >
> > We did agree to come back to the data formats, so I don't think we are
> > starting from scratch.
>
> Agreed but that was before we had an almost complete spec, a rough
> reference implementation complete with mechanical transforms to the
> requested formats and the start of a HTML interface for good measure.
> For JSON we have nothing and I'm on a flight to the cote d'azur for my
> birthday so you're on your own if you insist on making changes.
>
> >> 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.
> >
> > +1
> >
> > The model is really important.  But that does not mean the formats
> > discussion is a bikeshed discussion. Well, maybe it is.  I am not
> > sure.  But several strong advocates have emerged for JSON which at
> > least is consistent with our approach of keeping data formats flat and
> > simple.  So let's work this out.
>
> Given the way we use XML it is 100% religious, and unfortunate given
> JSON does not in any way cater for playing nice with other standards
> efforts nor transforming to multiple formats, among other things.
>
> >> 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.
> >
> > Now there's an API I would like to see ;-)
> >
> >
> http://3.bp.blogspot.com/_w55opxuxeX8/RgBBr8FpH0I/AAAAAAAAAQs/W3OwpT_LRF8/s320/pig+latin.jpg
>
> Can't see that on the iPhone unfortunately :(
>
> >> 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.
> >
> > I'd like to hear more about why Sun moved off XML onto JSON.
>
> Q-Layer was always JSON wasn't it?
>
> > That said, the issue is not whether we abuse our own design, it's
> > about whether we make it easy for end users to do so.  That could be
> > worse.
> >
> >
> >
> >> 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).
> >
> > Personally I disagree with this.  JSON is not rapidly developing.  I
> > have not encountered any enterprise that objects to JSON in my own
> > experience with RabbitMQ, possibly because enterprise users are also
> > (usually) humans.
>
> The schema is a WiP for a start, and an essential enterprise feature.
>
> >
> >
> >> 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).
> >
> > I think this is the point we need to consider.
> >
> > Our charter talks about playing nicely with OVF.
>
> Our success *requires* playing nice with OVF. And SNIA. And probably a
> bunch of other stuff in the future. Still zero answers on this
> absolute requirement from the JSON junkies too.
>
> > Richard --- how would you feel about OVF-JSON?  I note that the OVF
> > spec XML appears to be flat.  Perhaps a machine could rewrite it as
> > JSON ;-)
> >
> > I am only half joking.  We did this with AMQP, which condensed the
> > spec down to just a few pages, see e.g.
> > http://hg.rabbitmq.com/rabbitmq-codegen/file/1e6ad9a9cd37/amqp-0.8.json
>
> Our spec will be concise anyway given how we use XML in the lightest
> way possible.
>
> >> 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).
> >
> > This argument carries weight if we need FEEDS for OCCI.  I have a
> > hunch that feeds would be useful but it would really help if you could
> > make the argument that they are necessary.  You also made the point
> > that Atom gives us a way of dealing with metadata and it would be
> > helpful to spell that out again.
>
> Seeing the world as a bunch of feeds works better than you might
> think... look at Google's great example (which, unlike a lotof the
> other stuff we've been talkig about is in production on a massive
> scale).
>
> >> 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.
> >
> > It would be much easier if you took us through the exercise ;-)
>
> Will have to find some Internet in the south for that but sure, good idea.
>
> >
> >> 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).
> >
> > Sure ... but why is it necessary to mess with DOM objects.  I am not
> > saying you are wrong, I am just trying to understand what use case
> > this solves.  I have no problem with reconvening for OCCI 2.0 or 1.1
> > ... but that won't happen unless 1.0 is good.
>
> Cloud architectures are complex with many differs t extensions having
> to contribute to answers. JSON does not lend itself to this kind of
> thing so it's actually (a lot) more work for implementors. Suck it and
> see if you like.
>
> >
> >
> >> 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.
> >
> > I think Tim has come forward with a strong counterargument to our
> > initial view.  As I understand it, he makes the point that we as a
> > community do not have a strong basis for understanding interop which
> > casts doubt on the value of standards work at this time.  Yet, by
> > giving people a way to see if interop can be achieved in any sense at
> > all, based on some common and open interface, we can deliver value.
> > In order to make interop maximally likely, one format is desirable.
> > Allowing format flexibility *at this time* could compromise the main
> > goal of being able to show interop using an open interface, which is
> > the justification of OCCI.
>
> That's only true if you lack an automated way of supporting multiple
> formats, and we don't. I'm all for being nice to the users first and
> implementors second, even as someone with a foot in both camps.
> >
> >
> >
> >
> >
> >> 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).
> >
> > Well arguably some folks will be satisfied if we don't throw away a
> > substantial base of work done by Sun ;-)
> >
> > Please can you elaborate re Google.  GData supports JSON.
>
> GData clearly uses a standard XML to JSON XSLT stylesheet to do
> that... The result is pretty damn ugly but still very useable.
>
>
>
> >
> >
> >> 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.
> >
> > It's not just about curly braces.  It's about lowering the total cost
> > of interop.
>
> Right, and I reckon it rises without XML.
>
> Anyway taking off... gotta run
>
> Sam on iPhone (on plane)
>
> > alexis
> >
> >
> >
> >
> >
> >> Sam
> >>
> >>
> >> _______________________________________________
> >> occi-wg mailing list
> >> occi-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/occi-wg
> >>
> >>
> >
> _______________________________________________
> 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/20090507/8cc41705/attachment.html 