Cheers for the feedback! J Inline…

 

Andy

PS: I removed the CC’ed folk – only wanted originally to notify them directly of their mentioning in the original mail.

 

 

Andy,

Thanks for your efforts - I find it easiest to look at this rendering to work out what it boils down to and I can't help but to notice there are already some strong similarities with Atom (as well as some serious limitations courtesy the "simplification"):

[AE: ] Compare atom to many other models and I’m sure there’s a reasonably easy mapping. The rendering may not be perfect, I’ll be the first to admit it J If there are other limitations do please list them. I’d be keen to hear.

• How do I tell the difference between resources without a unique identifier (Atom "id")

[AE: ] The current OCCI nouns/verbs/attributes do not specify this, hence a requirement. I’ve only taken what’s on the wiki and worked with that along

• How do I tell when the resource was updated (Atom "updated") and/or what version it is (ETag)

[AE: ] Same as above

• How do I find one or more resources by search/category/tag/etc.?

[AE: ] See occi:Tag

• How do I represent a single object?

[AE: ] See occi:Compute or indeed occi:Resource

• How do I differentiate between tag vocabularies - "small" and "virtualmachine" are talking about two completely different concepts (Atom "category")

[AE: ] J tag == folksonomy. I guess you are referring to ontology?

• How do I create generic links to supporting resources e.g. screenshots, consoles, etc. (Atom "link")

[AE: ] See my first answer. Also occi:Link – oops my bad this is there but should be xs:complexType not xs:attributeGroup. I’ll update this.  

• How do I create associations with arbitrary resources e.g. users (Atom "link")

[AE: ] See first answer. Extend atom:linkType or simply import it. Arbitrary? I thought OCCI was focused on the specific domain of Infrastructure and we spent time on extracting core nouns.

• How do I carry critical information that we nonetheless consider out of scope (e.g. OVF)

[AE: ] can introduce xsd:anyType into the model easily

• How do we extend the spec? (e.g. rinse & repeat)

[AE: ] Extend the XSD.

• How do vendors/users extend the spec? (e.g. namespaces?)

[AE: ] As above plus some notions of governance from OCCI, yet to be discussed.

• How do I import/export resource(s) (e.g. OVA)

[AE: ] Now we’re into application specific functionality/features… something of an orthogonal for modelling activities. Perhaps closest here is model transforms.

• etc.

[AE: ] The more requirements the better. In fact OCCI does not define the base units of attribute values that are part of the model. I don’t think these can be found within Atom. Perhaps there’s an XSD out there that we could import and reuse those based units (e.g. MB, MHz etc). Also it would be nice to be able to add arbitrary infrastructure related parameters to any entity in the model.

You need not answer these questions but the thought exercise should leave you with something that looks almost identical to Atom. I know because this was the exact process I used to arrive at Atom in the first place - library and information science is similar regardless of the subject.

[AE: ] Ah I did it anyway J

Following a (long) conversation over (numerous) beers with Alexis on Friday I have come to the conclusion that the meta-model is quite separate from the representation, which is to say that collections, organisation, association, etc. can be done generically while providing a simple "OCCI" representation of the various resources is a domain-specific task.

[AE: ] Meta-model constrains the model. The model defines how a model instance can be created. Representation is the model instance and can be rendered. So in my view they are related, albeit through 2 levels of indirection.

For the former (meta-model) HTTP and/or Atom clearly make the most sense but for the latter we need to be careful not to end up reinventing CIM. Gary's list of network attributes gave me pause over the weekend and I think the best way to filter this is to consider what functionality is supplied rather than what functionality is demanded. That is to say, today public cloud providers do IPv4 so we provide attributes for IPv4. If multiple vendors do IPv6 we add IPv6. If nobody does IPX/SPX then too bad for those who need it. This stuff still needs to go somewhere though, which is why multiple representations are essential.

[AE: ] I agree on this (being careful not extending CIM). In fact this is one of OVF’s strengths. It’s quite easy to include elements and attributes defined in the RASD schema in OVF, allowing people extending OVF reach into a huge library of entity definitions. Regarding IP issues and hence specific technology dependencies, I remember you describing a solution where we not concentrate on such details but rather assign compute resources (VM) to networks by tag. Whatever came of that?

If it wasn't already clear, I'm very anti the approach of modeling the problem and blatting out one or more representations, irrespective of the delimiters used. A lot of good work has already been done on HTTP and Atom meta-models and giving everyone else the forks by creating yet another domain-specific language is not something I plan to be in any way associated with... the result will almost certainly be an interop train wreck not unlike WS-*

[AE: ] The modelling approach through to XSD is just one that was followed by the Atom folks in one way or another to arrive at a domain-specific model for the publishing and manipulation of content. If you don’t model the problem – even on paper, napkin or beer mat how do you expect to fully understand it? /joke If you wish not to be domain-specific then might I introduce you to my little friend void* :-D

With atom imho if you want to use it other than publish blog articles then you will have to create something more domain specific – I wouldn’t be attempting to cout my void* to atom:entry and hope someone understand the content within atom:entry.

In summary I'd like to see us use Atom where absolutely necessary (e.g. collections) and raw HTTP with multiple representations everywhere else. One of those representations can be a restricted syntax based on features with multiple deployments (but users would also be free to send/receive OVF or even their own home grown guff if they want).

[AE: ] That’s perfectly fine but what will those representations look like? Who will define them? How will you verify them? If we’re not using even Atom, what will it be?

Sam

 

-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.