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)