- occi-wg - lists.ogf.org

Cloud Demo call today
by Mark Carlson 07 Jul '10

07 Jul '10

What: Cloud Demo coordination planning When: Wednesdays: 8amPT/9amMT/11amET Where: Audio conference information: Toll Free: (866) 682-4770 International: +1 (408) 774-4073 Conference Code: 1212488 Security Code: 1212 Agenda: Planning for next demo - SNIA summer symposium: http://www.snia.org/events/summersymp2010 Other venues? SDC OGF 30 What do we want to add to the demo functionality? Google Group for Cloud Demo http://groups.google.com/group/cloud-demo

1 1

Reminder concall tomorrow: 10am EDT, 4pm CET, 3pm BST
by Thijs Metsch 07 Jul '10

07 Jul '10

Hi all, Just a quick reminder for tomorrow's concall - will take place at 10am EDT, 4pm CET, 3pm BST - I'll send out the conference bridge details tomorrow. Agenda for tomorrow's meeting: * Some administrational stuff (max 10min), collaborations, announcements etc. * Roadmap towards OGF30 * Gain an overview of open issues, stuff which needs to be done for a next revision of the Specification We'll use the gridforge wiki for this discussion - a skeleton has been created so we can smoothly walk through this stuff. Since this is an important meeting - especially regarding the Roadmap - it would be great if many people could join. Cheers, -Thijs -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax

2 2

OCCI Announcement
by Alexis Richardson 06 Jul '10

06 Jul '10

Hi all, The chairs are very pleased to announce that OCCI has a new Secretary. Please join me in welcoming Rick Clark from Rackspace. Previously with Canonical, Rick has a long track record of working with open communities. We are thrilled that he has come on board. Those of you going to OSCON this year will be able to meet Rick: http://www.oscon.com/oscon2010/public/schedule/speaker/14781 Best wishes alexis

1 0

Editorial tool
by Thijs Metsch 05 Jul '10

05 Jul '10

Hi @all, Since DocBook hasn't turned out to be the best tool for editing our specs I wanted to bring up the discussion on how the following revision should be edited. I guess we have several options - and feel free to add more: * Word/OpenOffice Pro: Ease of use (Templates available) Contra: Merging and version control * Latex Pro: Merging, version control easy (Andre could help with templates) Contra: Not so easy to use * Plain TXT files in Wiki --> then use a tool for formatting when finished... Pro: Easy editable Contra: Not so cool for graphics etc. (formatting) Feel free to add more and state you preference - It would be cool if in future a lot of people can help edit the specs. Cheers, -Thijs -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax

6 7

Re: [occi-wg] occi-wg Digest, Vol 16, Issue 1
by Eugene Luster 01 Jul '10

01 Jul '10

Here are my 2 cents on this subject of editing tools and version control. Microsoft Office/Open Office are commonly known tools and prevalent usage is apparent throughout our community. It is true version control can be weak for a group. If necessary, we can work out a version control process. Both Google document tools and Microsoft Office Live appear to perform well initially, though I have yet to use either of them in a professional collaborative fashion with a working group such as this. These tools are well worth considering. r, Eugene On Thu, Jul 1, 2010 at 10:00 AM, <occi-wg-request(a)ogf.org> wrote: > Send occi-wg mailing list submissions to > occi-wg(a)ogf.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ogf.org/mailman/listinfo/occi-wg > or, via email, send a message with subject or body 'help' to > occi-wg-request(a)ogf.org > > You can reach the person managing the list at > occi-wg-owner(a)ogf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of occi-wg digest..." > > > Today's Topics: > > 1. Editorial tool (Thijs Metsch) > 2. Re: Editorial tool (Andre Merzky) > 3. Re: Editorial tool (Edmonds, AndrewX) > 4. Re: Editorial tool (Alexis Richardson) > 5. Re: Editorial tool (Gary Mazz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 1 Jul 2010 03:37:22 -0400 > From: "Thijs Metsch" <tmetsch(a)platform.com> > Subject: [occi-wg] Editorial tool > To: <occi-wg(a)ogf.org> > Message-ID: > < > E2AC825D4FC7764DA86D9C8ECA27A2DE043EB077(a)catoexm05.noam.corp.platform.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi @all, > > Since DocBook hasn't turned out to be the best tool for editing our > specs I wanted to bring up the discussion on how the following revision > should be edited. I guess we have several options - and feel free to add > more: > > * Word/OpenOffice=20 > Pro: Ease of use (Templates available) > Contra: Merging and version control > > * Latex > Pro: Merging, version control easy (Andre could help with templates) > Contra: Not so easy to use > > * Plain TXT files in Wiki --> then use a tool for formatting when > finished... > Pro: Easy editable > Contra: Not so cool for graphics etc. (formatting) > > Feel free to add more and state you preference - It would be cool if in > future a lot of people can help edit the specs. > > Cheers, > > -Thijs > > -- > Thijs Metsch > Senior Software Engineer Grid and Cloud Technology > Platform Computing GmbH > Europaring 60 > D-40878 Ratingen > http://www.platform.com > > http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax > > > > > ------------------------------ > > Message: 2 > Date: Thu, 1 Jul 2010 10:41:04 +0200 > From: Andre Merzky <andre(a)merzky.net> > Subject: Re: [occi-wg] Editorial tool > To: Thijs Metsch <tmetsch(a)platform.com> > Cc: occi-wg(a)ogf.org > Message-ID: <20100701084104.GH68399@jonas> > Content-Type: text/plain; charset=us-ascii > > Quoting [Thijs Metsch] (Jul 01 2010): > > Date: Thu, 1 Jul 2010 03:37:22 -0400 > > From: "Thijs Metsch" <tmetsch(a)platform.com> > > To: <occi-wg(a)ogf.org> > > Subject: [occi-wg] Editorial tool > > > > Hi @all, > > > > Since DocBook hasn't turned out to be the best tool for editing our > > specs I wanted to bring up the discussion on how the following revision > > should be edited. I guess we have several options - and feel free to add > > more: > > > > * Word/OpenOffice > > Pro: Ease of use (Templates available) > > Contra: Merging and version control > > > > * Latex > > Pro: Merging, version control easy (Andre could help with templates) > > Contra: Not so easy to use > > > > * Plain TXT files in Wiki --> then use a tool for formatting when > > finished... > > Pro: Easy editable > > Contra: Not so cool for graphics etc. (formatting) > > Google docs is another option I guess, although you cannot use the > GF accounts that way. > > Best, Andre. > > > > Feel free to add more and state you preference - It would be cool if in > > future a lot of people can help edit the specs. > > > > Cheers, > > > > -Thijs > > -- > Nothing is ever easy. > > > ------------------------------ > > Message: 3 > Date: Thu, 1 Jul 2010 09:55:31 +0100 > From: "Edmonds, AndrewX" <andrewx.edmonds(a)intel.com> > Subject: Re: [occi-wg] Editorial tool > To: Andre Merzky <andre(a)merzky.net>, Thijs Metsch > <tmetsch(a)platform.com> > Cc: "occi-wg(a)ogf.org" <occi-wg(a)ogf.org> > Message-ID: > < > DAFA889EB3BE6243AEF55CFEE82D68A401B359E59B(a)irsmsx502.ger.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > - Text might be painful given we need to construct tables, markdown > doesn'= > t help out here. > - I like the idea of google docs; revision history, accessible, no merge > i= > ssues, collaborative > - Latex, great for those who value & know it, PITA for those who've to > lea= > rn it. > > -----Original Message----- > From: occi-wg-bounces(a)ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf > Of= > Andre Merzky > Sent: Thursday, July 01, 2010 9:41 AM > To: Thijs Metsch > Cc: occi-wg(a)ogf.org > Subject: Re: [occi-wg] Editorial tool > > Quoting [Thijs Metsch] (Jul 01 2010): > > Date: Thu, 1 Jul 2010 03:37:22 -0400 > > From: "Thijs Metsch" <tmetsch(a)platform.com> > > To: <occi-wg(a)ogf.org> > > Subject: [occi-wg] Editorial tool > >=20 > > Hi @all, > >=20 > > Since DocBook hasn't turned out to be the best tool for editing our > > specs I wanted to bring up the discussion on how the following revision > > should be edited. I guess we have several options - and feel free to add > > more: > >=20 > > * Word/OpenOffice=20 > > Pro: Ease of use (Templates available) > > Contra: Merging and version control > >=20 > > * Latex > > Pro: Merging, version control easy (Andre could help with templates) > > Contra: Not so easy to use > >=20 > > * Plain TXT files in Wiki --> then use a tool for formatting when > > finished... > > Pro: Easy editable > > Contra: Not so cool for graphics etc. (formatting) > > Google docs is another option I guess, although you cannot use the > GF accounts that way. > > Best, Andre. > > > > Feel free to add more and state you preference - It would be cool if in > > future a lot of people can help edit the specs. > >=20 > > Cheers, > >=20 > > -Thijs > > --=20 > Nothing is ever easy. > _______________________________________________ > occi-wg mailing list > occi-wg(a)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. > > > > ------------------------------ > > Message: 4 > Date: Thu, 1 Jul 2010 13:24:34 +0100 > From: Alexis Richardson <alexis(a)rabbitmq.com> > Subject: Re: [occi-wg] Editorial tool > To: Andre Merzky <andre(a)merzky.net> > Cc: occi-wg(a)ogf.org > Message-ID: > <AANLkTimzUr6qdqeErkG8yUP44h_Npfnn_ss9nGDtPvWh(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > +1 for google docs. > > On Thu, Jul 1, 2010 at 9:41 AM, Andre Merzky <andre(a)merzky.net> wrote: > > Quoting [Thijs Metsch] (Jul 01 2010): > >> Date: Thu, 1 Jul 2010 03:37:22 -0400 > >> From: "Thijs Metsch" <tmetsch(a)platform.com> > >> To: <occi-wg(a)ogf.org> > >> Subject: [occi-wg] Editorial tool > >> > >> Hi @all, > >> > >> Since DocBook hasn't turned out to be the best tool for editing our > >> specs I wanted to bring up the discussion on how the following revision > >> should be edited. I guess we have several options - and feel free to add > >> more: > >> > >> * Word/OpenOffice > >> Pro: Ease of use (Templates available) > >> Contra: Merging and version control > >> > >> * Latex > >> Pro: Merging, version control easy (Andre could help with templates) > >> Contra: Not so easy to use > >> > >> * Plain TXT files in Wiki --> then use a tool for formatting when > >> finished... > >> Pro: Easy editable > >> Contra: Not so cool for graphics etc. (formatting) > > > > Google docs is another option I guess, although you cannot use the > > GF accounts that way. > > > > Best, Andre. > > > > > >> Feel free to add more and state you preference - It would be cool if in > >> future a lot of people can help edit the specs. > >> > >> Cheers, > >> > >> -Thijs > > > > -- > > Nothing is ever easy. > > _______________________________________________ > > occi-wg mailing list > > occi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/occi-wg > > > > > ------------------------------ > > Message: 5 > Date: Thu, 01 Jul 2010 07:31:37 -0600 > From: Gary Mazz <garymazzaferro(a)gmail.com> > Subject: Re: [occi-wg] Editorial tool > To: Thijs Metsch <Thijs.Metsch(a)Sun.COM> > Cc: Alexis Richardson <alexis(a)rabbitmq.com>, occi-wg(a)ogf.org > Message-ID: <4C2C98B9.5030708(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > +1 OO > Documents can be saved in raw XML format, although the directory > structure is a little complicated. OO Writer does have a convenient > merge functions, versioning, comments and review. Diffs are done via > "Edit->Compare Document", I think compare works as a command line, > although I never needed to try it. The ODF (odt) document format is > just compressed xml. Mercurial has diff scripts for odt documents, > although hidden metadata is exposed and makes reviewing Mercurial diffs > challenging. It runs well on MAC, Vista/x64, OpenSolaris, FreeBSD and > most Linux distributions. Supports master documents, integrates with > spreadsheets and drawing tools. Outputs XML and there is third party > integration into wikis > OO Drawbacks, It can be slow in systems with low available memory, > another office framework to install, susceptible to JVM quirks. > > Google doc require to be connected, difficult in the air, anywhere else > you cannot be connected. > > Latex: We may as well stay with docbook > > Word, if M$ would donate licenses to all editors > > Plain text/Wiki: Collaboration and simultaneous editing could be dicey > depending on wiki and editor. Most wiki change tracking not intended for > collaborative and group review processes. > > Personally, I think google docs is not mature enough for a production > environment. > > cheers, > gary > > Alexis Richardson wrote: > > +1 for google docs. > > > > On Thu, Jul 1, 2010 at 9:41 AM, Andre Merzky <andre(a)merzky.net> wrote: > > > >> Quoting [Thijs Metsch] (Jul 01 2010): > >> > >>> Date: Thu, 1 Jul 2010 03:37:22 -0400 > >>> From: "Thijs Metsch" <tmetsch(a)platform.com> > >>> To: <occi-wg(a)ogf.org> > >>> Subject: [occi-wg] Editorial tool > >>> > >>> Hi @all, > >>> > >>> Since DocBook hasn't turned out to be the best tool for editing our > >>> specs I wanted to bring up the discussion on how the following revision > >>> should be edited. I guess we have several options - and feel free to > add > >>> more: > >>> > >>> * Word/OpenOffice > >>> Pro: Ease of use (Templates available) > >>> Contra: Merging and version control > >>> > >>> * Latex > >>> Pro: Merging, version control easy (Andre could help with templates) > >>> Contra: Not so easy to use > >>> > >>> * Plain TXT files in Wiki --> then use a tool for formatting when > >>> finished... > >>> Pro: Easy editable > >>> Contra: Not so cool for graphics etc. (formatting) > >>> > >> Google docs is another option I guess, although you cannot use the > >> GF accounts that way. > >> > >> Best, Andre. > >> > >> > >> > >>> Feel free to add more and state you preference - It would be cool if in > >>> future a lot of people can help edit the specs. > >>> > >>> Cheers, > >>> > >>> -Thijs > >>> > >> -- > >> Nothing is ever easy. > >> _______________________________________________ > >> occi-wg mailing list > >> occi-wg(a)ogf.org > >> http://www.ogf.org/mailman/listinfo/occi-wg > >> > >> > > _______________________________________________ > > occi-wg mailing list > > occi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/occi-wg > > > > > > > > ------------------------------ > > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg > > > End of occi-wg Digest, Vol 16, Issue 1 > ************************************** > -- v/r, Eugene Luster

1 0

Reminder: concall in one hour - 10am EDT, 4pm CET, 3pm BST
by Thijs Metsch 30 Jun '10

30 Jun '10

Hi, Just a quick reminder: our concall starts in one hour... Audio conference information: Toll Free: (866) 682-4770 <tel:(866)%20682-4770> International: +1 (408) 774-4073 <tel:+1%20(408)%20774-4073> Conference Code: 1212488 Security Code: 1212 Other international toll free numbers: http://www.intercall.com/oracle/access_numbers.htm Cheers, -Thijs

1 0

[occi] push by tmetsch - fixed issue 41 on 2010-06-01 10:26 GMT
by occi＠googlecode.com 30 Jun '10

30 Jun '10

Revision: e3d1f0d2c2 Author: tmetsch Date: Tue Jun 1 03:24:17 2010 Log: fixed issue 41 http://code.google.com/p/occi/source/detail?r=e3d1f0d2c2 Modified: /docs/occi-infrastructure.xml /docs/occi-infrastructure_book.xml /docs/ogf_template.xsl ======================================= --- /docs/occi-infrastructure.xml Tue Jan 12 01:29:18 2010 +++ /docs/occi-infrastructure.xml Tue Jun 1 03:24:17 2010 @@ -179,7 +179,7 @@ <entry>Float (10^9 bytes)</entry> - <entry>RAM in megabytes (e.g. 16, 0.512)</entry> + <entry>RAM in gigabytes (e.g. 1, 0.512)</entry> </row> <row> @@ -416,7 +416,14 @@ <title>Storage</title> <para>A storage resource is capable of mass storage of data (e.g. a - virtual hard drive).</para> + virtual hard drive). </para> + + <note> + <para>The actions defined here should trigger operations on e.g. + virtual images. The implementation of these operations is left to + Cloud Storage APIs and the corresponding Storage backend + solutions.</para> + </note> <section> <title>Attributes</title> ======================================= --- /docs/occi-infrastructure_book.xml Tue Jan 12 04:29:36 2010 +++ /docs/occi-infrastructure_book.xml Tue Jun 1 03:24:17 2010 @@ -46,11 +46,14 @@ </listitem> <listitem> - <para>OCCI XHTML5 rendering</para> + <para>OCCI HTTP Header rendering</para> </listitem> <listitem> - <para>OCCI HTTP Header rendering</para> + <para>(OCCI XHTML5 rendering)<footnote> + <para>The OCCI XHTML5 rendering will be released in near + future.</para> + </footnote></para> </listitem> </itemizedlist> @@ -74,10 +77,10 @@ <section> <title>Contributors</title> - <para>The following people have contributed to this document.</para> + <para>The following people edited this document.</para> <table> - <title>List of contributors</title> + <title>List of editors</title> <tgroup cols="3"> <thead> @@ -102,7 +105,7 @@ <row> <entry>Sam Johnston</entry> - <entry>Australian Online Solutions</entry> + <entry>Google</entry> <entry>samj(a)samj.net</entry> </row> @@ -110,11 +113,32 @@ <row> <entry>Thijs Metsch</entry> - <entry>Sun Microsystems - RESERVOIR project</entry> - - <entry>thijs.metsch(a)sun.com</entry> + <entry>Sun Microsystems - RESERVOIR project, Platform + Computing</entry> + + <entry>tmetsch(a)platform.com</entry> </row> - + </tbody> + </tgroup> + </table> + + <para>The editors would like to thank the following contributors:</para> + + <table> + <title>List of contributors</title> + + <tgroup cols="3"> + <thead> + <row> + <entry align="center">Name</entry> + + <entry align="center">Affiliation</entry> + + <entry align="center">Contact</entry> + </row> + </thead> + + <tbody> <row> <entry>Gary Mazzaferro</entry> @@ -122,6 +146,22 @@ <entry>garymazzaferro(a)gmail.com</entry> </row> + + <row> + <entry>Shlomo Swidler</entry> + + <entry>Orchestratus</entry> + + <entry>shlomo.swidler(a)orchestratus.com</entry> + </row> + + <row> + <entry>Michael Behrens</entry> + + <entry>R2AD</entry> + + <entry>michael.behrens(a)r2ad.com</entry> + </row> </tbody> </tgroup> </table> @@ -161,7 +201,8 @@ <section> <title>Full Copyright Notice</title> - <para>Copyright (C) Open Grid Forum (2009,2010). All Rights Reserved.</para> + <para>Copyright (C) Open Grid Forum (2009,2010). All Rights + Reserved.</para> <para>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or ======================================= --- /docs/ogf_template.xsl Thu Jan 14 05:30:01 2010 +++ /docs/ogf_template.xsl Tue Jun 1 03:24:17 2010 @@ -20,28 +20,34 @@ <xsl:param name="chapter.autolabel"> 1 </xsl:param> <xsl:param name="section.autolabel.max.depth"> 4 </xsl:param> - - <xsl:param name="shade.verbatim" select="1"></xsl:param> + + <xsl:param name="shade.verbatim" select="1" /> <xsl:attribute-set name="xref.properties"> <xsl:attribute name="font-family">serif</xsl:attribute> + <xsl:attribute name="font-size">8pt</xsl:attribute> + <xsl:attribute name="font-style">italic</xsl:attribute> </xsl:attribute-set> - +  + <xsl:attribute-set name="monospace.verbatim.properties"> <xsl:attribute name="wrap-option">wrap</xsl:attribute> + <xsl:attribute name="hyphenation-character">\</xsl:attribute> </xsl:attribute-set>  + <xsl:attribute-set name="admonition.properties"> <xsl:attribute name="border">0.5pt solid black</xsl:attribute> + <xsl:attribute name="padding">0.1in</xsl:attribute> </xsl:attribute-set> -  +  <xsl:attribute-set name="root.properties"> <xsl:attribute name="font-family">sans-serif</xsl:attribute> @@ -103,7 +109,8 @@ </xsl:attribute-set>  -<!-- + + <!-- <xsl:template match="para[parent::section or parent::chapter]"> <fo:block xsl:use-attribute-sets="normal.para.spacing"> <xsl:call-template name="anchor" /> @@ -147,7 +154,7 @@ </fo:block> <fo:block> - <xsl:text>Jan. 12, 2010</xsl:text> + <xsl:text>Jun. 1, 2010</xsl:text> </fo:block> </xsl:when> </xsl:choose>

7 8

RDF, RDFa and HTML
by Edmonds, AndrewX 25 Jun '10

25 Jun '10

Hi all, I've been looking into how OCCI can expose itself through a HTML serialization and to demarcate machine readable, semantic content. To demarcate that content we already decided that we would use RDFa [1]. In order to truly and correctly use RDFa we need to be able to point to the ontology (model) in which subject, predicate and object triplets are defined. Defining the ontology is somewhat easy, we have it already with the OCCI model; it's just a matter of expressing it in RDF. With an ontology in hand, we can define semantically marked-up HTML with the ontology's vocabulary using the facilities of RDFa. I've worked on 2 ways of expressing the OCCI model in RDF. 1. Using python [2]. 2. Using a modeling tool (Protégé) [3][4][5]. Note these owl files may need their imports modified in Protégé. The only difference in the two is that occi.owl (core spec), occi-infrastructure.owl (infrastructure spec) and occi-sla-at-soi.owl (SLA@SOI extensions) are defined in separate files with the Protégé approach. This should give folks an idea of how extensions for OCCI can be introduced. However in both examples, occi-core, occi-infrastructure and slasoi-infrastructure are separated by namespace. As RDFa does not explicitly define a rigorous structure for HTML documents, and it shouldn't, we need to be able to express 2 basics forms: 1. A concrete OCCI Kind instance (Compute, Storage, Network). I have an example here [6]. 2. A collection of OCCI Kind instances. I have an example here [7]. In this example values of objects are exposed using the 'content' RDFa attribute [8]. Each example may not be 100% perfect but what's most interesting is when you run the each HTML rendering through a RDFa parser [9] (examples here [10] [11]). The RDF extracted is quite along the lines of what some might expect an OCCI POX format to be. Note, I'm not advocating POX, just pointing to the flexibility of RDFa. There are still some aspects to be worked out but I will follow up on these in a separate mail (this one is long enough!). If you want to see how all of this visually looks then see here: ontology only [12], ontology and graph instance [13]. I'd really appreciate and love to hear people's comments, opinions on this! :-) Andy [1] http://www.w3.org/TR/rdfa-in-html/ [2] http://dl.dropbox.com/u/165239/occi-rdf.py [3] http://dl.dropbox.com/u/165239/occi.owl [4] http://dl.dropbox.com/u/165239/occi-infrastructure.owl [5] http://dl.dropbox.com/u/165239/occi-sla-at-soi.owl [6] http://home.edmonds.be/occi-html5-rdfa-one.html [7] http://home.edmonds.be/occi-html5-rdfa-list.html [8] http://www.w3.org/TR/2010/WD-rdfa-core-20100422/#s_syntax [9] http://www.w3.org/2007/08/pyRdfa [10] http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fhome.edmonds.be%2… [11] http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fhome.edmonds.be%2… [12] http://dl.dropbox.com/u/165239/occi-rdf-graph-rev2.png [13] http://dl.dropbox.com/u/165239/occi-rdf-graph-inst-rev2.png ------------------------------------------------------------- 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.

3 6

OCCI documents and IPR
by Joel Replogle 24 Jun '10

24 Jun '10

Dear OCCI Working Group, Following recent emails, I would like to assure the OCCI Working Group and all contributors that the documents that have been produced by OCCI in accordance with OGF policies do indeed retain the OGF IPR. OGF IPR Policy protects every contributor by ensuring that all contributions have been made in good faith in the spirit of open collaboration with up-front disclosure of any licensing encumbrances. It also protects implementors so that implementations may be made with confidence based on persistent specifications which will have neither content nor licensing changed retroactively. These protections are clearly identified in OGF's IPR Policy, and are explicitly agreed to whenever someone contributes to OGF work by opening a GridForge account, joining an OGF mailing list, or attending an OGF working group session by phone or in person. The full policy may be found here: http://www.ogf.org/merger_docs/OGFIPRPolicy.pdf If anyone has patent claims or other encumbrances to their individually contributed portions that were not disclosed at the time of contribution, please contact me, the OGF Executive Director. Note that I have received no such communications to date, nor were any objections raised during the open Public Comment period of the group's documents. Additionally, I would like to congratulate the OCCI-WG on the very well-received demo at OGF29 and look forward to your continued success in support of the OGF mission. Well done! Thanks, Joel -------------------------------------------------------------------- Joel Replogle Executive Director, OGF replogle(a)ogf.org http://www.ogf.org PO Box 1738 T: +1-765-228-9068 Muncie, IN 47308 USA F: +1-815-927-6284 Upcoming Events: OGF29 * June 20-22, 2010 * Chicago * www.ogf.org/OGF29 OGF30 * October 25-29, 2010 * Brussels * www.ogf.org/OGF30

1 0

OCCI-POX experiment a concept
by Csom Gyula 24 Jun '10

24 Jun '10

Hi! We've made some progress with our OCCI-POX experiment I'd like to share here. Please find attached an early draft that outlines the goals and detailed scope of our effort. Note also that we are pleased to see the progress of the XHTML/RDFa rendering format [1]. Though we understand that POX is not an accepted rendering solution we are very interested in the possible convergence of the 2 formats. We've found the RDF(a) direction so promising that we've decided to drop our original idea in favour of that. Instead of working on a 100% clean, domain-specific OCCI-POX schema, we will try to create a RDF/XML one that is compatible with the upcomming XHTML/RDFa format. See the attached document for more. Since the working draft is just an early version we will likely refine it. As always any feedback including critiques is more than welcome. Kind regards, Gyula Csom --- [1] RDF, RDFa and HTML by Edmonds, Andrew: http://www.ogf.org/pipermail/occi-wg/2010-June/003758.html ________________________________________ Feladó: Alexis Richardson [alexis.richardson(a)gmail.com] Küldve: 2010. május 24. 22:17 Címzett: Csom Gyula Másolatot kap: occi-wg(a)ogf.org Tárgy: Re: [occi-wg] Request for POX representation a refined proposal I would be very interested in seeing reference implementations of this proposal, even if they were experimental. alexis 2010/5/24 Csom Gyula <csom(a)interface.hu>: > Hi, > thank you for your response and especially thanks Gary for outlining the current RDFa directions. > > Based on your feedback we refined our request. First let me put some more details about our background and the > decision we made, then I'd like to introduce our refined proposal. > > > ## 1./ Background > As I've already outlined in my original email our customer's been interested in a long term solution. That has > basically meant reliability and maintanable development. Here I'd like to reveal some additional details on > our requirements. Though we will specify the detailed interface requirements at the next month, the basic > features are already outlined. > > * Users: The system should serve as a public cloud for the academic sector and as a private cloud for our > customer's own needs. The cloud interface should support both end users and administrators. > > * Functionality: The cloud management system's core should provide a programmatic interface that exposes > remote management functionality to the consuming client applications. We should deal with 2 types of > applications: one for the end users (which might mean Web GUI but others as well) and one for the system > administrators (which means CLI and administration scripts). > > * Architecture: In order to support both the above feature and ease of maintanance the core should provide > a solid server API and a layered client design that clearly separates presentation from logic, ie. the > client UI should be built on top of a clean client API. Besides ease of maintanance the latter should also > enable us to build different tpye of applications/UIs adhering to different type of end user needs and > should also provide us a scriptable interface for administration purposes. > > I attached a sample architecture diagram that illustrates the above concept [1]. > > > ## 2./ Decision > Basically we do not trust in XHTML + RDFa to serve as a general purpose remote management API in the above manner. > Especially we do not think that a general purpose robust and maintanable client driver could be built against > it. This is a general concern of us not specific to XHTML except for the fact that it is an UI format. Instead > we'd like to build our client-server architecture upon a clean and solid API. We consider the following as a > technical minimum in order to achieve our goals outlined above: > > * We are looking for an open client-server protocol that uses a common payload format, has no or little external > dependencies and especially is free from the UI. > > Note that though we prefer POX due to our platform selection this is not a strict requirement from us. The basic > point is not POX, but the clean programmatic interface outlined above. That is to say we prefer XML as the > payload format, but we could adapt to another reasonable format as well. > > > ## 3./ Proposal > Meanwhile we do understand that you're are bound to your working group charter and it might be impossible to > fulfill our request within the current specification session. Hence we refined our original concept and propose > the following: > > * Let's give our conservative approach a try. If accepted we would create a draft proposal and a reference > implementation around the POX format. Then OCCI could simply monitor our efforts and make its decision based > upon the results. > > We think it can be a win-win situation where OCCI has nothing to lose. If it turned out that our approach was a > niche then OCCI could simply ignore our efforts. Meanwhile if it turned out that there was a general community need > for such a format then OCCI backed by a draft proposal and working prototype would be in a good position to fulfill > this need. > > > I hope that here I could better expose our intentions and reasons and basically they are inline with your goals. I > also hope that our proposal meets your policies and will be accepted by the working group. > > Looking forward to your response, > > Kind regards, > Gyula Csom > > Ps.: Besides our general concern there's also a special issue related to XHTML that we do not want to deal with in > the core API. According to W3C XHTML has just entered a long term transitional period: XHTML v.1 [2] and v.2 [3] has > been recently dropped in favour of X/HTML5, meanwhile X/HTML5 is assumed to reach reccommendation stage only at 2022 > or later [4]. Generally we do not want to mix business logic with UI at all and especially not with an UI format that > is in the begining of such a long transitional period. > > --- > > [1] arch.png attached to this email is a simple diagram to illustrate the above architectural concept. > > [2] XHTML 1.x is dropped: "W3C does not at this time plan to allocate resources to the maintenance of XHTML 1.1, > XHTML 1.1 Basic, and XHTML Print beyond the current round of revisions. W3C does not plan to revise the XHTML 1.0 > Recommendation." http://www.w3.org/2009/06/xhtml-faq.html#deli > > [3] XHTML 2 is dropped: "Today the Director announces that when the XHTML 2 Working Group charter expires as > scheduled at the end of 2009, the charter will not be renewed. " http://www.w3.org/News/2009#item119 > > [4] When will HTML5 be finished? "It is estimated by the editor that HTML5 will reach the W3C Candidate > Recommendation stage during 2012. [..] It is estimated, again by the editor, that HTML5 will reach a W3C > recommendation in the year 2022 or later." http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F > > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg > >

1 0