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