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
