[occi-wg] XML rendering

[Jean Parpaillon]

Of course ;)

Le mercredi 11 décembre 2013 à 11:42 +0100, Augusto Ciuffoletti a
écrit :
> Ah! Going functional!
> 
> 
> 
> 2013/12/11 Jean Parpaillon <jean.parpaillon at free.fr>
>         Hi Augusto,
>         I can only answer quickly on some points. I will have an eye
>         to your xml
>         file later, sorry.
>         Comments inside:
>         
>         Le mardi 10 décembre 2013 à 17:43 +0100, Augusto Ciuffoletti a
>         écrit :
>         > Hi Jean,
>         >
>         >
>         > I have completed the exercise of translating to XML the
>         example in the
>         > document (compose.pdf). There is one XML that describes the
>         mixins
>         > specific for the provider (example.xml), and the xml
>         document that
>         > describes the entities that implement the example in the
>         document
>         > (occi-monitoring-example.xml). They are uploaded in the
>         "monitoring"
>         > branch.
>         >
>         >
>         > I have left your comments in the occi-monitoring-example.xml
>         > complaining about the fact that mixin attributes "melt" into
>         the
>         > resource in a completely opaque way. On my side, I add that
>         it is also
>         > impossible to characterize an attribute with any sort of
>         semantic (in
>         > my case, input, control, metric).
>         >
>         >
>         > About the occi.xsd document:
>         >
>         >
>         > -) line 113: amyURI instead of anyURI
>         >
>         >
>         > -) the attribute type
>         >
>         >     <xs:complexType name="attributeType">
>         >         <xs:sequence>
>         >             <xs:element name="value" type="xs:anyURI"
>         minOccurs="0"
>         >                 maxOccurs="unbounded">
>         >             </xs:element>
>         >         </xs:sequence>
>         >         <xs:attribute name="name"
>         type="xs:string"></xs:attribute>
>         >         <xs:attribute name="value"
>         type="xs:string"></xs:attribute>
>         >     </xs:complexType>
>         >
>         >
>         > The two attributes are ok (name+value) but the unbounded
>         sequence of
>         > URIs puzzles me: what is its meaning exactly.
>         
>         
>         I think it is useful to have 2 forms of attributes:
>         1/ when attributes have single value:
>           <occi:attribute name="occi.ext.attr1" value="value1" />
>         2/ when attributes have multiple values:
>           <occi:attribute name="occi.ext.attr2" >
>             <occi:value>value1</occi:value>
>             <occi:value>value2</occi:value>
>           </occi:attribute>
>         But I must admit I don't remember why I've limited to
>         xs:anyURI... :)
>         
>         I remember a discussion in CompatibleOne project where we
>         expressed the
>         need for referring to a resource as an attribute value. This
>         could be
>         achieved in XML with allowing 'href' or 'xref' xml attribute
>         instead if
>         'value' xml attribute.
>         
>         I will update the xsd ASAP.
>         
>         > And, overall, this is not the "attribute" as defined in the
>         core
>         > model, upper right corner of fig. 2: this is represented as
>         the
>         > "attributeSpecType", right? Is there a relationship between
>         the two? I
>         > guess no.
>         >
>         
>         
>         You're right, in the XSD, I separate the attributeSpecType
>         from
>         attributeType, the latter representing an instance of the
>         former.
>         Basically, you will find attributeSpecType in kind, mixin or
>         action
>         definition, while attributeType in resource or link.
>         
>         > Also: I have not found an easy way to test the example: do
>         you have an
>         > inexpensive suggestion for me?
>         >
>         
>         
>         I am currently writing an OCCI implementation in erlang which
>         read OCCI
>         API definition in XML file. Unfortunately, it is not ready
>         yet. If you
>         want to check it out, you will only be able to read the xml
>         file and
>         expose the categories at query url (in json or text/plain).
>         Code is here: http://github.com/jeanparpaillon/erocci
>         
>         Of course, any contribution welcome, but I'm more focusing on
>         finishing
>         the first implementation rather than documenting or
>         stabilizing APIs....
>         
>         
>         Regards,
>         Jean
>         
>         >
>         > Bye!
>         >
>         >
>         > Augusto
>         >
>         >
>         >
>         > PS: ah, is there interest regarding XMPP?
>         >
>         > --
>         > 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
>         
>         _______________________________________________
>         occi-wg mailing list
>         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