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

[Mark Masterson]

Sam -- for the record, I find blanket assertions such as "an essential
enterprise feature" to be problematic.  I'm about as enterprisey as anyone
could possibly be, and you are definitely *not* speaking on my behalf here.
I've no doubt that you are speaking for someone or something that relates
to your experience, and an alternative phrasing such as "an essential
feature for the enterprise customers I work with" would clearly articulate
that.  But I"m here to tell you -- there's a large and valid population of
folk who self-identify as "enterprise" who disagree with much of your
reasoning.  Here are some examples:

-- "The schema is a WiP for a start, and an essential enterprise feature".

No, it is not.  In my world, we are busy trying to learn many lessons from
the Web, only some of which fit within the scope of the term REST.  One of
the most important lessons we are trying to internalise and apply is that a
priori schemas are sometimes much more trouble than they are worth.  In
that world, among other things, there are any number of examples of cases
where I am trying to figure out how to *store my data* without an a priori
schema, because that confers on me all sorts of advantages which seem to
move me an inch or two towards the holy grail of disposable software.  I
can assure you that, in those sorts of contexts, the idea of going to those
lengths, only to move data to and from those schema-less data stores via
"standard" mechanisms that impose one of its own can provoke gales of
(slightly bitter) laughter.

-- "Our success *requires* playing nice with OVF. And SNIA. And probably a
bunch of other stuff in the future" followed then by "Our spec will be
concise anyway given how we use XML in the lightest way possible".

It worries me that you may not see the contradiction lurking in those two
statements.  At best, these statements have a high probability of both
being true only at a given point in time; one quite early in the life cycle
of OCCI (which, of course, is where we are).  Over time, it is *very*
unlikely (verging on the impossible, IMO) that both statements can *remain*
true.  This is because the imperative underlying each of these statements
is in direct conflict with the other -- "playing nice with others" is in
direct conflict with "concise".  We all seem to be in agreement about the
merits of concise -- the disagreement revolves around the degree of
"playing nice with others", and / or preparing for playing nice with
others.  I think there is a strong argument to be made for making a
deliberate decision, at this point in the lifecycle, to *not* make playing
nice with others a goal.  Explicitly -- IOW, making it a non-goal.
Instead, focus on what I thought this group was chartered to do -- the
simplest possible common representation of what's already out there,
working.  The "others" be damned.

-- "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"

That sounds, to this "enterprise voice", like a feature, not a bug.
Constraints are good.  I like constraints.  You have not yet convinced me
that the "extensions" you refer to here are critical to the core of the
aforementioned simplest possible common representation of what's already
out there, working.  Instead, the impression I get is that these extensions
(or even the possibility of having them) serves primarily the "play nice
with others" (non) goal.  Since I don't think worrying about playing nice
with others is a good idea, imposing a contstraint that makes it harder to
do seems like a good idea to me.  Helps focus on the core goal --
distractions fall away.  In my experience, that's a design approach that,
in turn, produces *very* robust artefacts -- ones on which it is
subsequently relatively easy to build more stuff (to play with other, for
example).  Doing things the other way round (trying to anticipate and
account for possible "extensions"), in my experience, too often leads to
fragile, brittle designs.

This argument, OTOH:

-- "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"

... is quite compelling, and in my view.  And that may outweigh all other
concerns, given the desire to hold the date.  Dunno.



Mark Masterson
Enterprise architect, troublemaker
CSC

Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss
Masterson | Public blog: Process Perfection
(http://jroller.com/MasterMark/) | mmasterson at csc.com | www.csc.com.


CSC • This is a PRIVATE message. If you are not the intended recipient,
please delete without copying and kindly advise us by e-mail of the mistake
in delivery.  NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal
Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered
in England No: 0963578