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

[Alexis Richardson]

I would be very interested in seeing reference implementations of this
proposal, even if they were experimental.

alexis


2010/5/24 Csom Gyula <csom at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>