[occi-wg] Request for POX representation a refined proposal

[Csom Gyula]

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  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arch.png
Type: image/png
Size: 22776 bytes
Desc: arch.png
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100524/151bd96f/attachment.png