[occi-wg] OCCI-POX experiment a concept

Thu Jun 24 10:59:51 CDT 2010

Hi!

We've made some progress with our OCCI-POX experiment I'd like to share here. Please find attached  
an early draft that outlines the goals and detailed scope of our effort.

Note also that we are pleased to see the progress of the XHTML/RDFa rendering format [1]. Though  
we understand that POX is not an accepted rendering solution we are very interested in the  possible  
convergence of the 2 formats. We've found the RDF(a) direction so promising that we've decided to  
drop our original idea in favour of that. Instead of working on a 100% clean, domain-specific OCCI-POX  
schema, we will try to create a RDF/XML one that is compatible with the upcomming XHTML/RDFa  
format. See the attached document for more.

Since the working draft is just an early version we will likely refine it. As always any feedback including  
critiques is more than welcome.

Kind regards,
Gyula Csom

---

[1] RDF, RDFa and HTML by Edmonds, Andrew: 
http://www.ogf.org/pipermail/occi-wg/2010-June/003758.html

________________________________________
Feladó: Alexis Richardson [alexis.richardson at gmail.com]
Küldve: 2010. május 24. 22:17
Címzett: Csom Gyula
Másolatot kap: occi-wg at ogf.org
Tárgy: Re: [occi-wg] Request for POX representation a refined proposal

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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: occi_pox_experiment_v.0.1.pdf
Type: application/unknown
Size: 222186 bytes
Desc: occi_pox_experiment_v.0.1.pdf
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100624/f1a782f6/attachment.bin 