[occi-wg] Fwd: Re: XML for OCCI
Ralf Nyren
ralf at nyren.net
Thu Sep 26 15:03:28 EDT 2013
On Thu, 26 Sep 2013 10:11:39 +0200, Jean Parpaillon
<jean.parpaillon at free.fr> wrote:
> Hi Ralph,
>
> Le 24/09/2013 13:36, Ralf Nyren a écrit :
>> I think it would be really cool to have an XML data-format for OCCI :)
>>
>> Priority wise I would like to see the protocol vs data-format split
>> first
>> though.
>
> Is there some draft on that topic ?
Not anything in draft status yet but there is a start in the
"protocol-data-format-split" branch.
> I have some (early) draft about OCCI use with XMPP protocol. I may try
> to propose some ideas when I will implement the XML rendering on HTTP
> and XMPP.
> What other protocol are you thinking about ? websocket ?
The first thing would be to split up the current http_rendering into two
documents, one describing purely the HTTP protocol parts and the other
describing the text/plain data-format. This makes the whole thing
decoupled so that new data-formats like e.g. JSON and XML can be added
without the risk of creating incompatibilities at the HTTP layer.
regards, Ralf
>> When that is done the JSON spec could finally be released and an
>> XML data-format would be much easier to accomplish as well.
>>
>> Just my two cents.
>>
>> regards, Ralf
>>
>
>
> Regards,
> Jean
>
>> On Tue, 24 Sep 2013 11:10:38 +0200, Jean Parpaillon
>> <jean.parpaillon at free.fr> wrote:
>>> Sharing this discussion on XML rendering...
>>>
>>>
>>> -------- Message original --------
>>> Sujet: Re: XML for OCCI
>>> Date : Tue, 24 Sep 2013 11:03:22 +0200
>>> De : Augusto Ciuffoletti <augusto.ciuffoletti at gmail.com>
>>> Pour : Jean Parpaillon <jean.parpaillon at free.fr>
>>>
>>>
>>>
>>> You can certainly share with the group. I'm elaborating an answer, that
>>> I'll post to the group.
>>>
>>>
>>> 2013/9/24 Jean Parpaillon <jean.parpaillon at free.fr
>>> <mailto:jean.parpaillon at free.fr>>
>>>
>>> Hi Augusto,
>>>
>>> Le 24/09/2013 10:06, Augusto Ciuffoletti a écrit :
>>> > Jean,
>>> >
>>> > sorry for not being at your presentation: I concentrated on the
>> OGF
>>> > session, and I did not consider other good reasons to
>>> participate.
>>> >
>>>
>>> No harm: I'm really interested in contributing to OCCI
>> specifications
>>> and I have no doubt we have another occasion to meet !
>>>
>>> On my side, I have seen your spec about monitoring I consider a
>> really
>>> important topic but I am now more focusing on core and renderings
>>> parts.
>>>
>>>
>>> > I always started from the assumption that the "true" rendering
>>> was
>>> HTML,
>>> > which is definitely not a simplifying assumption. The JSON and
>>> XML
>>> > renderings open entirely new horizons.
>>> >
>>> > I submit you two problems I have with the monitoring API:
>>> >
>>> > -) one is subtyping mixins, binding their semantic (not simply
>> their
>>> > syntax): this is done by introducing tagging mixins, and then
>> saying
>>> > that a mixin related with a certain tag must have "certain"
>>> > attributes
>>> >
>>>
>>> Mixin can also have their own attributes, isn't it enough ? Can you
>>> give
>>> me an example ? I must admit mixin is a concept I'm not really
>>> confortable with. I consider they should be use to add attributes
>>> to
>> a
>>> resource when is does not make sense to have a separate id for it,
>> but
>>> I
>>> may be wrong.
>>>
>>> > -) the other is describing such "certain" attributes: their value
>> is
>>> > used to establish a relationship with complementary attributes in
>>> > another entity, which is the desired "semantic" (like a
>> "port_number"
>>> > attribute)
>>>
>>> Ok, this is a problem not specific to mixins, IMO. Attributes
>>> typing
>> in
>>> general should be more advanced in OCCI and, in particular, an
>>> attribute
>>> could be an OCCI type.
>>> My proposal does not handle yet this complex type, even if think it
>> is
>>> necessary to handle it. As a quick draft of proposal, I think the
>>> following should work:
>>>
>>> <occi:kind term="manifest" scheme="http://example.org/myschemas#" >
>>> <occi:rel term="resource"
>>> scheme="http://schemas.ogf.org/occi/infrastructure#" />
>>> <occi:attribute name="nodes" type="occi:entityAttr" minOccurs="0"
>>> maxOccurs="unbounded" >
>>> <occi:rel term="compute"
>>> scheme="http://schemas.ogf.org/infrastructure#" />
>>> </occi:attribute>
>>> </occi:kind>
>>>
>>>
>>> .. my proposal is missing the definition of "entityAttr", which
>>> would be:
>>> <xs:complexType name="entityAttr" >
>>> <xs:sequence>
>>> <xs:element name="rel" type="occi:relatedType" />
>>> </xs:sequence>
>>> </xs:complexType>
>>>
>>> We could then validate the following resource:
>>>
>>> <occi:resource id="...." >
>>> <occi:kind term="manifest" scheme="http://example.org/myschemas#"
>> />
>>> <occi:attribute name="nodes >
>>> <occi:value>/path/to/compute/resource</occi:value>
>>> <occi:value>/path/to/another/compute/resource</occi:value>
>>> </occi:attribute>
>>> </occi:resource>
>>>
>>> Of course, this would imply some code to implement it (it is not
>> pure
>>> XSD), but the information is there.
>>>
>>> >
>>> > I see no way to introduce this in an xml schema, but I've never
>> tried
>>> > to. In these days, I'm thinking to RDF. Any opinion about this?
>>> >
>>>
>>> I have never used RDF.
>>> Anyway, thank for the occasion to provide concrete example of
>> complex
>>> attributes.
>>> Do you mind I forward this to occi-wg list for comments ?
>>>
>>>
>>> Best regards,
>>> Jean
>>>
>>> >
>>> > --
>>> > Augusto Ciuffoletti
>>> > Via Milano 118
>>> > 38122 - Trento
>>>
>>>
>>> --
>>> 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
>
More information about the occi-wg
mailing list