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

Fri May 8 04:22:51 CDT 2009

Gary

These may help:

http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html?page=1
http://www.json.org/xml.html

Separately we have already agreed to use a flat structure anyway,
regardless of whether XML or Text or JSON is preferred.

a

On Thu, May 7, 2009 at 5:52 PM, Gary Mazz <garymazzaferro at gmail.com> wrote:
> Sam  +2
>
> It is much simpler to map a strongly hierarchal structure to a flat
> representation than the converse.
>
> Moving towards a JSON ONLY solution may alienate and exclude
> interoperability with other well established and standardized management
> schemes. IMHO, this would be very poor approach for this occi effort. In
> fact, using a JSON scheme would prove challenging to clearly represent
> relationships in a unix /dev tree or the /proc file system. For example,
> representing the different views capable in SNIA storage models with
> JSON would be extremely difficult, if not at all.
>
> Rendering a model, whether in XML or JSON should not be the issue.
> Providing an accurately rendered representation reflecting the interests
> of the users, including system managers, is very important. Today, most
> computer systems are organized and represented though management schemes
> that are at least hierarchical if not network models ie: recursion
> though symbolic and hard links. Most storage systems, along with TINA,
> and DMTF's CIM,  are complex systems represented though standardized
> management schemes that are complex network models. As the cloud matures
> and as we adopt collaborative practices, do we actually believe cloud
> systems and architectures will reduce complexity ? I don't believe so.
>
> It is far easier to represent hierarchical and network (not networking)
> information with XML than JSON. It also requires less time and effort,
> we don't have to flatten existing models and delay adoption.
>
> I personally believe there will be many opportunities to represent the
> complex in flatter renderings (mappings) like JSON, flat text or ASN.1,
> SNMP MIBS or enterprise 6bit paper tape. Each entity involved with
> clouds will have their own business models and processes. Roles and
> existing operational models will determine the informations required
> from clouds, one size will not fit all. We cannot treat clouds as a
> university mid-term project or the 20year fiasco of linux. IMHO, again,
> moving to a JSON only solution would radically defeature capabilities
> and significantly limit the value proposition of deployments.
>
> IMHO, Sam is on target,
> Mark:  Go work as an IT tech in a very large data center, your opinion
> will change.
>
> cheers,
> Gary Mazz
>
> Sam Johnston wrote:
>> Including the list this time...
>>
>> On 5/7/09, Sam Johnston <samj at samj.net> wrote:
>>
>>> So examples of the requisite extensibility include creating complex
>>> storage and networking resources and importing the (large) existing
>>> base of compute resources (in OVF or other legacy formats). It is
>>> without doubt better to have the option and not use it than give it up
>>> and find we need it.
>>>
>>> For the componentisation of implementations, it's highly unlikely that
>>> the best architecture is to use the same platforms for everything from
>>> controllers to monitoring to billing to security etc. in which case it
>>> is extremely useful to be able to pass your messages around and build
>>> them iteratively. JSON is great for [de]serialising objects in memory
>>> but is actually more troublesome than XML for this particular use
>>> case.
>>>
>>> I guess a lot of this comes down to the public vs private debate that
>>> Ignacio captured nicely in a recent blog post. I prefer not to
>>> differentiate and have my money on hybrid architectures. As a
>>> potential client implementor I'd mych prefer not to have to implement
>>> OCCi *and* vCloud^W OVF2.0 for things like that function people are
>>> calling 'cloudbursting'.
>>>
>>> With XML we can be light for light users and as fat as need be for the
>>> more demanding ones (like my enterprise clients who are primarily from
>>> the CAC 40 - top 40 companies in France).
>>>
>>> FWIW I actually dislike XML as much as the next guy but I'm also very
>>> practical and like to avoid cutting off my nose to spite my face.
>>>
>>> Sam on iPhone
>>>
>>> On 5/7/09, Mark Masterson <mmasterson at csc.com> wrote:
>>>
>>>> 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
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>