[occi-wg] XML to represent an instance

[Jean Parpaillon]

Hi Augusto,

Le 06/11/2013 09:55, Augusto Ciuffoletti a écrit :
> 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?

No. I suppose the term was not correct ;)
What I meant is: if the XML description allows distinction of mixin's
attributes, text/plain can not. In this case, one can translate from xml
description to text/plain but not the other way.


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

Could you point the section where it appears ? I can not find it.

> Indeed, the xml wants to reflect the system in the paper: kind of an
> exercise for myself.
> 
> Augusto
> 

Regards,
Jean

> 
> 2013/11/1 Jean Parpaillon <jean.parpaillon at free.fr
> <mailto:jean.parpaillon at 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 at ogf.org <mailto:occi-wg at ogf.org>
>     > https://www.ogf.org/mailman/listinfo/occi-wg
>     >
> 
> 
>     --
>     Jean Parpaillon
>     Open Source Consultant
>     Phone: +33 6 30 10 92 86 <tel:%2B33%206%2030%2010%2092%2086>
>     im: jean.parpaillon at gmail.com <mailto:jean.parpaillon at gmail.com>
>     skype: jean.parpaillon
>     linkedin: http://www.linkedin.com/in/jeanparpaillon/en
> 
>     _______________________________________________
>     occi-wg mailing list
>     occi-wg at ogf.org <mailto:occi-wg at ogf.org>
>     https://www.ogf.org/mailman/listinfo/occi-wg
> 
> 
> 
> 
> -- 
> Augusto Ciuffoletti
> Dipartimento di Informatica
> Università di Pisa
> 56100 - Pisa (Italy)


-- 
Jean Parpaillon
Open Source Consultant
Phone: +33 6 30 10 92 86
im: jean.parpaillon at gmail.com
skype: jean.parpaillon
linkedin: http://www.linkedin.com/in/jeanparpaillon/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jean_parpaillon.vcf
Type: text/x-vcard
Size: 241 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20131112/da57aabc/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20131112/da57aabc/attachment.pgp>