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