[occi-wg] Request for POX representation

Thu May 20 10:40:42 CDT 2010

Dear Sam,

thank you for your response! 

We previously analyized your technical decision: I've actually read 
thru some of your earlier discussions regarding multiple formats, even 
agree that in some cases a single or primary format would be more useful 
then "dozen different ones"... well if it suited most of the real needs. 
Our request simply mirrors that your technical selection doesn't suite 
our needs. 

According to your mail the current specification session is at its final 
stage, so please consider my request in your future plan/roadmap. For 
now I'd just like to know whether you think it will be possible to support 
POX later? 

---

While the above were semi-formal things, please consider the following as 
initial, informal thougts on the topic. 

To my understanding there are natural mappings between the X/HTML-RDFa 
format and the different RDF representations. To put it simply: all of 
these representations are built around the RDF concept, the RDF data model. 
So maybe there's is no need to maintain a separate OCCI specification for 
POX. The problem could be kept off by outsourcing the maintanance to W3C. 

For instance RDFa spec explicitely states that: "A conforming RDFa Processor 
MUST make available to a consuming application a single RDF graph containing 
all possible triples generated by using the rules in the Processing Model 
section" [1]. Put this together with the already existing RDF/XML spec [2] 
and you might gain a POX representation for free.

But again I might be wrong. Any opinion? 

Cheers,
Gyula

---

[1] http://www.w3.org/TR/rdfa-syntax/#processorconf
[2] http://www.w3.org/TR/rdf-syntax-grammar/

-----Eredeti üzenet-----
Feladó: Sam Johnston [mailto:samj at samj.net]
Küldve: 2010. 05. 20., Cs 15:34
Címzett: Csom Gyula
Másolatot kap: occi-wg at ogf.org
Tárgy: Re: [occi-wg] Request for POX representation

Csom,

We did consider (at length) a POX representation but decided against it on
the basis that the main driver was to allow enterprise users to use XML
parsers; slightly more complex path expressions were deemed a reasonable
tradeoff for providing a human and machine friendly interface. XHTML also
natively supports semantic web (RDFa) which is a direction we plan to
explore for future versions. We specifically don't want to support a dozen
different renderings - for this less is definitely more.

The HTTP rendering uses the "universal interface" in the way it was intended
- that is, using entity headers to carry metadata rather than building
another envelope layer on top ala SOAP. It makes the resources available via
"clean" channel that requires no parsing whatsoever.

Also note that it is *very* late in the day to be requesting fundamental
changes - the bulk of the specification has already passed through public
comment and feedback is being incorporated.

Sam

2010/5/20 Csom Gyula <csom at interface.hu>

> Hi!
>
> After analyzing the issue I kindly ask you to consider POX as an official
> OCCI representation
> format. Namely in order to have a programmatic interface that is easy to
> implement and maintain we
> (as a potential OCCI user) request a domain specific and extensible XML
> representation format.
>
> ## 1./ Features
> ---
> We request a POX representation format that 1. is domain specific, strongly
> typed, and free
> from other domains, and 2. is extensible, supports user defined elements
> and/or attributes.
>
> 1. The scheme has its own XML namespace and
> 2. is free from XML elements of orthogonal domains (like GUI, eg. XHTML)
> 3. Different kind of OCCI entities (compute, network, storage) are mapped
> to individual XML
>   schema elements.
> 4. Different entity attributes are mapped to either individual XML
> (sub)elements or attributes
>   (though we prefer the former, eg. attributes as XML subelements).
> 5. This also applies to links, and
> 6. actions eg. just as attributes they are handled in a strongly typed
> manner rather than in a
>   generic way.
> 7. The scheme is extensibe (depending on the design decision under 4, it
> supports either the
>   XSD any element or the anyAttribute or both).
>
>
> ## 2./ Intentions
> ---
> We need a programmatic interface that is easy to implement and maintain:
>
> 1. It builds upon technologies that are in common practice. We do not
> consider HTTP Header
>   format to meet this criteria. XML, REST seem to be the common hypermedia
> format in the
>   REST world and especially within the Cloud API space [2].
>   Bottom line: REST itself seems to support/encourage multiple formats.
> Thus I do not say
>   that using HTTP Header is not RESTful, I just say that it doesn't seem to
> be a common
>   REST format.
> 2. It supports separation of concerns. Being a programmatic interface, it
> at least separates
>   "busines" logic (eg. data and methods) from UI (eg. user interaction). We
> do not consider
>   the upcoming X/HTML+RDFa format to meet this criteria. We've found 2
> issues with the format
>   -  one is trivial, the second is less trivial:
>   1. X/HTML intends to be a user interaction language, and RDFa to be a
> data annotion
>      language for foreign markups (typically? for UI markups). Thus the
> upcoming format
>      intermixes UI and data in its roots.
>   2. X/HTML elements and RDFa attributes are strongly coupled. Depending on
> the host (eg.
>      X/HTML) structure the same RDFa sequence can result in different data
> structures. Thus
>      an agent must be aware of the UI structure in order to build the data
> structure it is
>      interested in. According to my preliminary examination this primarily
> effects recursive
>      data structures [3] but may effect other data structures, too.
> Meanwhile OCCI seems to
>      already have such structures, since categories might have child
> categories. Also OCCI
>      may want to support more complex entities later (like services, and
> service groups which
>      are again recursive in their nature).
>
> One more thing. XML and JSON seems to be equally prefered by cloud
> providers [2]. We simply made
> our decision based upon the selected CMS platform: OpenNebula. It currently
> supports POX.
>
> We will likely refine our request based upon feedbacks, so
> comments and criticism are welcome!
>
> Kind regards,
> Gyula Csom
>
> ---
>
> [1] Scheme samples: request.xml, response.xml illustrate the scheme
> (strongly typed elements, with
> user defined extensions). It tries to model a new compute request.
>
> [2] Existing Cloud APIs and formats
>
>  * OpenNebula OCCI API: REST + POX (
> http://www.opennebula.org/documentation:rel1.4:occiug)
>  * Amazon EC2 API: SOAP
>  * ElasticHosts API: REST + Plain text, or JSON (
> http://www.elastichosts.com/cloud-hosting/api)
>  * IBM WebSphere CloudBurst API: REST + JSON
>    (
> http://www.ibm.com/developerworks/websphere/techjournal/0911_amrhein/0911_amrhein.html
> )
>  * Sun Cloud API: REST + JSON (
> http://kenai.com/projects/suncloudapis/pages/Home)
>  * RedHat delta cloud API: REST + POX, and custom formats (
> http://deltacloud.org/api.html)
>
> [3] RDFa samples: foaf.html, extract.rb illustrate strong coupling between
> X/HTML and RDFa, eg.
> the same RDFa sequence can result in different data structures. The
> foaf.html is the sample file,
> extract.rb is a simple Ruby script that extracts data into turtle, NT and
> XML formats. Builds
> upon the rdf_context lib (http://github.com/gkellogg/rdf_context).
>
> [4] About our project:
> Our customer, the National Information Infrustructure Institute
> (http://www.niif.hu/en) wants to provide public cloud services for the
> Hungarian academic sector, and
> use a private cloud for its own purposes. The project is the initial step
> in this direction.
> At the technical side generally we are interested in an open, future-proof
> solution, especially
> OpenNebula as the cloud platform, and OCCI as the cloud interface.
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>