Hi Jean, I browsed your xml, and, at first sight, it is OK. You raise two points that I tried to implement in a problematic way, so to raise comments: -) mixins: depending on the way you specify the schema their content may become indistinguishable from other attributes. I think that they should (unlike in my xml), to allow different implementations for the same solution (i.e., distinct providers may offer distinct mixins to implement the same entity). Which is probably the same concept that you mean with the "bijection", right? -) inline links are introduced in the "infrastructure" document. I hope that my interpretation is correct. It is true that in this way a link is hidden inside the resource. So this is a critical issue in the infrastructure document that should be resolved, or simply clarified Indeed, the xml wants to reflect the system in the paper: kind of an exercise for myself. Augusto 2013/11/1 Jean Parpaillon <jean.parpaillon@free.fr>
Hi, The occi.xsd schema is supposed to allow also instance representations, or better link and resource in OCCI terms.
There is only one element missing to group instances of a user request. In CompatibleOne project, we have defined the 'manifest' element for that.
I have tried to express your xml document with the occi.xsd. It is in attchment and I have the following comments: - in occi.xsd, entities attributes are a flat list: there is no distinction between attributes from mixins or from the kind the entity is an instance of. This is the same for text/plain or text/occi representation but I think we should leverage XML grammar for grouping them in mixins when necessary. The problem is it will break the bijection between representations. - I may be wrong, but inline links break the resource oriented model because every entity (including link) should be accessible with an URI.
Is the attached document describe the same system you described in example.xml or have I misunderstood it ?
Best regards, Jean
Le 23/10/2013 11:53, Augusto Ciuffoletti a écrit :
Dear all,
Jean has recently proposed the formalization of the core model as an XSD schema. This is useful as a clean description of the model, and makes possible to validate the specialization of this model to represent more specific models. We have two examples for this: infrastructure and monitoring described as compliant XML files.
I considered another use of XML for the representation of an *instance* of a system (a monitoring system in my case). This kind of representation has two relevant functions: one is that it gives the ability to check certain requirements (e.g., that required attributes are present), the other is that it can drive the activity of the cloud management system. My question: is this related with the OCCI roadmap?
To go to the attached XML, it is a representation of the example given in the document (the figure is also attached). Some relevant options I use: -) Mixins are represented as distinct stanzas in the XML document. -) Links are defined "inline", inside the origin resource Of course, it is possible to write an XSD, but I'd like to collect opinions about the overall approach.
Comments?
-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)