[occi-wg] XSD rendering of OCCI model(s)

Thu Dec 10 03:42:47 CST 2009

Hi Andy,

No problem -- just to remind, these are still draft. In particular, I  
am not sure about the approach of using all those root elements, it  
may well be the case that they are not required eventually. As soon as  
I get a chance to actually test them inside WS-Agreement documents  
with some such implementation, I'll let the group know of results and  
possible modifications.

Best regards,

  Costas

On 10 Dec 2009, at 01:43, Edmonds, AndrewX wrote:

> Many thanks for this useful contribution Costas! :-)
>
> Andy
>
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On  
> Behalf Of Constantinos (Costas) Kotsokalis
> Sent: Tuesday, December 08, 2009 4:26 PM
> To: Gary Mazz
> Cc: occi-wg at ogf.org
> Subject: Re: [occi-wg] XSD rendering of OCCI model(s)
>
> Hi Gary,
>
> Thanks for your reply. As regards the schema, I have attached to  
> this email some first effort on it. Apologies if emailing  
> attachments is not acceptable here, I couldn't find my way around  
> uploading to the gridforge. There are two files attached, a schema  
> that corresponds to the spec, and one that imports it to reuse some  
> data types, and extends to a number of elements that (I think) would  
> be more convenient for use w/ WS-Agreement. The main problem is  
> that, in WS- Agreement, the links are not really necessary; rather,  
> one would just declare a service description (e.g. "compute"), its  
> properties in a separate place (e.g. cores, speed, memory) and then  
> in a third place (s)he would set numbers for those properties (e.g.  
> 2 cores, 1.5GHz, etc). The same would then happen for storage, and  
> for network.
> Grouping is then handled by the WS-Agreement envelope, using "Term  
> Compositors". Arbitrary possible combinations of different resource  
> requirements would be a problem to express without this (seemingly
> redundant) 2nd rendering in the additional schema file.
>
> The schemas are still draft (read: a quick hack), so there may be  
> many/ big mistakes. Please let me know if you have comments.
>
> With regard to the cores data type, I am only puzzled by the
> (syntactical) correctness of the expression "occi.compute.cores =  
> 3.14159265" :) Nevertheless, the group has apparently had its  
> discussions on the topic already, so it is fine.
>
> Very best,
>
>  Costas
>
>
> On 8 Dec 2009, at 15:24, Gary Mazz wrote:
>
>> Costas,
>>
>> I'm working on  a mapping of occi attributes to xds data types as  
>> part
>> of rdfa support in XHTML. We should coordinate efforts where
>> possible. I'm tied up for most of this week, I'll make better
>> progress  over the weekend,,,,, it looks like I'll be snowed or  
>> frozen
>> in.
>>
>> Numerating data types is always an interesting topic on this
>> list :-)   This document is in the OGF pipeline for comment, if
>> there are sections of the document that are unclear, missing,
>> incompatibilities with other efforts, we'll be glad to address them.
>>
>> Vlans are a network artifact/feature supported by a few providers.
>> Consensus was reached there was sufficient provider support to  
>> warrant
>> an attribute in the networking resource.
>> cheers,
>> gary
>>
>>
>> Constantinos (Costas) Kotsokalis wrote:
>>> Hi Thijs,
>>>
>>> Not a problem. I have actually already created something but it's
>>> fairly simplistic as it doesn't capture links, and it also wouldn't
>>> help with WS-Agreement's concept of "service guarantees"
>>> on "service  properties" of "service descriptions". So I'll update,
>>> try to take  into account the concepts from the existing schema that
>>> are still  valid according to latest spec, and send to the list.
>>>
>>> BTW, two question regarding the spec -- apologies in advance if  
>>> these
>>> have been discussed before, as I just subscribed to the list. If so,
>>> then please just point me to the archived thread if possible.
>>>
>>> 1. occi.compute.cores -- why is this a float, instead of an integer?
>>> 2. Is there a use case for occi.network.vlan? I'm slightly confused
>>> by  its use in a cloud context.
>>>
>>> Thanks,
>>>
>>> Costas
>>>
>>>
>>> On 8 Dec 2009, at 14:41, Thijs Metsch wrote:
>>>
>>>
>>>> Hi Costas,
>>>>
>>>> Right now these are not synced...sorry - Probably time we a) update
>>>> it or b) remove it...:-) Can or do you wanna help with a)?
>>>>
>>>> Cheers,
>>>>
>>>> -Thijs
>>>>
>>>> On Dec 8, 2009, at 2:19 PM, Constantinos (Costas) Kotsokalis wrote:
>>>>
>>>>
>>>>> Dear All,
>>>>>
>>>>> I would like to have an XSD rendering of the OCCI model(s), to
>>>>> embed in WS-Agreement [1]. I have found some previous work in [2],
>>>>> but I am not sure if this is synchronized with the latest spec
>>>>> draft(s) [3].
>>>>> Could someone please confirm?
>>>>>
>>>>> Thank you in advance,
>>>>>
>>>>> Costas
>>>>>
>>>>> [1] http://www.ogf.org/documents/GFD.107.pdf
>>>>> [2]
>>>>> http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/ 
>>>>> wik
>>>>> i/NounsVerbsAndAttributes/occi.xsd
>>>>> [3] http://www.ogf.org/pipermail/occi-wg/2009-November/001517.html
>>>>>
>>>>> _______________________________________________
>>>>> occi-wg mailing list
>>>>> occi-wg at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>>>
>>>> -- 
>>>> Thijs Metsch                        Tel: +49 (0)941 3075-122
>>>> (x60122)
>>>> http://blogs.sun.com/intheclouds
>>>> http://www.twitter.com/befreax
>>>> Software Engineer Cloud, Grid and Virtualization Sun Microsystems
>>>> GmbH
>>>> Dr.-Leo-Ritter-Str. 7                     
>>>> mailto:thijs.metsch at sun.com
>>>> D-93049 Regensburg                http://www.sun.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>>
>>
>
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>