[occi-wg] Request for POX representation

Thu May 20 09:00:21 CDT 2010

Hi, 

Quoting [Sam Johnston] (May 20 2010):
> 
> 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.

One could always submit a new rendering as new document.  I am not
at all saying the group should create a POX rendering (Sam gave
several other arguments against that) - just that a POX rendering
does not need to interfere with the current documents.

My $0.02, Andre.

> Sam
> 2010/5/20 Csom Gyula <[1]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
> ([2]http://www.opennebula.org/documentation:rel1.4:occiug)
> * Amazon EC2 API: SOAP
> * ElasticHosts API: REST + Plain text, or JSON
> ([3]http://www.elastichosts.com/cloud-hosting/api)
> * IBM WebSphere CloudBurst API: REST + JSON
> 
> ([4]http://www.ibm.com/developerworks/websphere/techjournal/0911_amr
> hein/0911_amrhein.html)
> * Sun Cloud API: REST + JSON
> ([5]http://kenai.com/projects/suncloudapis/pages/Home)
> * RedHat delta cloud API: REST + POX, and custom formats
> ([6]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
> ([7]http://github.com/gkellogg/rdf_context).
> [4] About our project:
> Our customer, the National Information Infrustructure Institute
> ([8]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
> [9]occi-wg at ogf.org
> [10]http://www.ogf.org/mailman/listinfo/occi-wg
> 
> References
> 
> 1. mailto:csom at interface.hu
> 2. http://www.opennebula.org/documentation:rel1.4:occiug
> 3. http://www.elastichosts.com/cloud-hosting/api
> 4. http://www.ibm.com/developerworks/websphere/techjournal/0911_amrhein/0911_amrhein.html
> 5. http://kenai.com/projects/suncloudapis/pages/Home
> 6. http://deltacloud.org/api.html
> 7. http://github.com/gkellogg/rdf_context
> 8. http://www.niif.hu/en
> 9. mailto:occi-wg at ogf.org
> 10. http://www.ogf.org/mailman/listinfo/occi-wg

> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg

-- 
Nothing is ever easy.