Hi Alexander,
Actually, I still don't see a problem here.
If we have an abstract rendering, which formally specifies the semantics of the data, and normative renderings which formally define the mapping to concrete formats (JSON, CSV, etc.), then it is trivial to put a converter (say, XSLT in the XML case) between them to map the data.
The approach taken by Exhibit to modeling [1] is interesting, and IMO, the noun-attribute-verb approach taken by OCCI so far, is about right (although yet to be convinced on the verb part). So, identify the resources. Then for each resource there are simple properties and properties which link to other resources. That's the basis of the class model. Give every resource a HTTP URI. A rendering is always flat data structure, as it only ever describes the *current* resource. In key-value terms: the key is the name of the property and the value is either the string, float, etc, or a http uri to another resource. How this looks in json or xml too, is clear (?), and it is simple too, and could also be specified (?). However, we decide on only *1*. Key-value (i.e. www-form-urlencoded) is interesting as a rendering as its fits nicely with HTML forms. ([2] is somehow relevant to the above.) Roger [1] http://simile.mit.edu/wiki/Exhibit/Understanding_Exhibit_Database [2] http://www.tbray.org/ongoing/When/200x/2009/01/29/Name-Value-Pairs
The same thing can be done for all other renderings as well, provided that the semantics of the data and renderings are fixed.
-Alexander
Am 12.05.2009 um 15:31 schrieb Alexis Richardson:
On Tue, May 12, 2009 at 2:30 PM, Chris Webb <chris.webb@elastichosts.com
wrote: Alexis Richardson <alexis.richardson@gmail.com> writes:
I still think there can be only one interop format - I think Chris put it very well.
I didn't make quite that strong a statement! It's fine to have multiple interop formats but you can't have *optional* interop formats. Clients can't rely on anything optional: they have to use one of the compulsory renderings if they want their code to be portable across cloud providers.
Maybe we are talking about different things.
I am talking about the format for the data exchanged between client and cloud.
Cheers,
Chris.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
<Alexander Papaspyrou.vcf>
Roger Menday (PhD) <roger.menday@uk.fujitsu.com> Senior Researcher, Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K. Tel: +44 (0) 208 606 4534 ______________________________________________________________________ Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469 This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does not guarantee that it has not been intercepted or amended nor that it is virus-free.