We can make OCCI transport and representation agnostic, which was suggested early on. That requires a logical model definition and selection of an implementation (a semantic model). The OCCI ended up with that exact structure for the specification. In fact, though the hard work of Andy Edmonds, we even have a start for defacto representation language of the OCCI logical model in XSD.
You're right - churning out XSDs for complex structures can be hard work and Andy's obviously been busy. Fortunately with the latest iteration it's not necessary - each resource is a minimalist OCCI key-value format (be that text, json or xml) accessible over raw HTML with all metadata available via the HTTP headers. We really can't get closer to raw HTTP than that, the only exception being collections which do require some structure in the form of multipart HTTP messages or a lightweight Atom-style meta-model.
If, we re-evaluate transport and representation agnostic strategy for OCCI, we can pick a "first implementation" with the knowledge we will "need" other implementations in the near future. IMO, I do not believe for one second we can get away with one implementation, not with the recent trend in protocol adoption. Adopting this strategy does not exclude providing bridges and gateways, more traditional works, to bridge technology gaps between OCCI and foreign systems, in fact agnostic strategy may produce a more valuable technology.
Agnostic strategy is more of an academic approach - we need something practical and implementable. Fortunately by offloading the meta-model requirements in order to reach flat key-value simplicity we barely need to specify anything (see the wiki for the three examples).
The bottom line; is PICK ONE implementation, if we are not happy with it, or the protocol fashion critics frown on the OCCI for "not playing in top of mind", we can always give it a face lift. Pick one, its a interchange and management system.
Again, with key-value we can have our cake and eat it - rendering all three proposed formats is trivial for implementors (read: ~2 LOC per format). Parsing is a different story but we have a simple and elegant solution by way of form submissions (it's just key-value remember) which as a bonus supports embedding files. Virtually all HTTP user agents support form submission which translates to zero code required for interacting with OCCI.
IMO, there is only ONE big issue that affects the decision on which way to go: human usability/readability in native form. If is is an ABSOLUTE requirement, go with atom. If not, some XML representation. Either way you WILL be representing the OCCI logical model.
One more issue in my rant, on the issue of human usability/readability, once you include links, the protocol is no longer "easily interpretable". An example is the Widows registry: its human readable, but try to read and find all the linked GUIDs. Its nearly impossible to find them, human readable or not. Reading the OCCI will have the same issues as reading the Windows registry. Human usability/readability is a pipe dream, at least without putting a lot of work into publishing rules, which complicates implementations.
If we want to merge the human and programmable web then our default format should be (simple) [X]HTML. Remember machines can read this too and indeed the sample Google Maps style API developed in "RESTful Web Services" (pp126) uses XHTML for an interface that is friendly to both humans and machines. In the context of OCCI your list of networks might end up looking something like this:
<ul class="network">
<li><a href="/abc">Internet</a></li>
<li><a href="/xyz">Private Network</a></li>
</ul>
This still feels a bit funky for me, though it's pretty much the same amount of effort to write xpath queries for this as what it is for POX and users being able to "browse" your API is hugely advantageous for approachability.
I'm guessing that implementors will differentiate on the number/type of formats they support... at a minimum being the ones we specify with the "must" requirement level.
Sam
Sam Johnston wrote:
On Tue, May 26, 2009 at 4:23 PM, Roger Menday <roger.menday@uk.fujitsu.com <mailto:roger.menday@uk.fujitsu.com>> wrote:
Hi Sam,
not to undervalue your hard work, but in my opinion I don't think
we will be able to make a decision this week. We don't have all
the time in the world, but I don't fancy rushing a decision on
this one.
If you're right and we can't make a decision this week (bearing in mind that all the information we need to make it is already on the table) then I fear we'll not be able to make a decision at all. It certainly wouldn't be the first working group to lose inertia after getting caught up in a religious debate and it won't be the last, but we need to draw the line somewhere and get on with the job. Public perception aside, it's important that we don't miss the only opportunity we have to gather information from an OGF event rather than wasting even more of everyone's time.
What more do you need for us to get out of this rut because I'm beginning to lose faith... what started as something I was proud to be involved in is fast becoming an embarassment.
Sam
All,
As you know our already extended deadline for the formats
discussion passed on Friday. Thijs is now in the unfortunate
position of having to explain why we will miss our first
self-assigned deliverable deadline (an implementable draft) on
Thursday and I know well how it feels to have to stand in front
of an audience with nothing to say, having done so twice last
week (it's only with a big "personal vision only" disclaimer that
I was able to say anything at the Cloud Computing Expos).
Iff we can come to consensus about the format today (or at the
very latest tomorrow) then we need not watch another deadline
sail by and in doing so risk being declared a failure
prematurely. Indeed if we can't achieve even a loose consensus
after all the discussion then I may well be the first to say so -
my time (and travel!) budget for OCCI has already been well
exceeded and the irrelevant RF vs RAND discussion has tested
what's left of my patience. Please focus on the task at hand and
if you have any specific issues about the latest proposal then
raise them sooner rather than later - I've put considerable
effort into optimising Atom out for the most common use case
(individual resources) over the weekend and by shifting metadata
to HTTP headers the resulting descriptor format is far simpler
than even I would have thought possible - see APIDesign
<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign>
for examples.
On the subject of rolling our own protocol from scratch, I for
one am dismissing the suggestion for reasons previously
explained. I don't think this group has (nor needs) what it takes
to implement an Internet protocol from the ground up and any
attempt to do so would be fraught with danger, not to mention
completely unnecessary given the corpus of work done by others at
the IETF (who _are_ geared up for such tasks).
Thanks,
Sam
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org <mailto:occi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/occi-wg
Roger Menday (PhD)
<roger.menday@uk.fujitsu.com <mailto:roger.menday@uk.fujitsu.com>>
Senior Researcher, Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
Tel: +44 (0) 208 606 4534
______________________________________________________________________
Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469
This e-mail and any attachments are for the sole use of
addressee(s) and
may contain information which is privileged and confidential.
Unauthorised
use or copying for disclosure is strictly prohibited. The fact
that this
e-mail has been scanned by Trendmicro Interscan and McAfee
Groupshield does
not guarantee that it has not been intercepted or amended nor that
it is
virus-free.
------------------------------------------------------------------------
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg