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_am...) * 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.
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@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_am... ) * 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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@ogf.org [10]http://www.ogf.org/mailman/listinfo/occi-wg
References
1. mailto:csom@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_am... 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@ogf.org 10. http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.
On Thu, May 20, 2010 at 4:00 PM, Andre Merzky <andre@merzky.net> wrote:
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.
Sure you could. I could revive the Atom rendering and whip up a JSON rendering while I'm at it too. At Google we use protocol buffers extensively and a protocol buffer rendering would be great for talking to backend nodes. We do have to draw a line somewhere though... Sam
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@samj.net] Küldve: 2010. 05. 20., Cs 15:34 Címzett: Csom Gyula Másolatot kap: occi-wg@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@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_am... ) * 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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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
I would be very interested in seeing reference implementations of this proposal, even if they were experimental. alexis 2010/5/24 Csom Gyula <csom@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (4)
-
Alexis Richardson -
Andre Merzky -
Csom Gyula -
Sam Johnston