Hello all, after having read the specification in its most current version, I would like to request a number of clarifications regarding not only the attributes given at the end of the document. Some of these requests for clarifications that follow may not be possible to answer yet (or at least not in time for OGF27). - Page 2 states that it is trivial to translate between wire formats. It then gives an example in the "text" format. Could the translation to e.g. XML (Atom) be shown as well? This would clear up how one would go about posting e.g. a Create request using something else than the HTTP Form encoding, as show on Page 3. - Page 3 states that there are both global and local IDs, and that resources should also have a UUID attribute. Is the local ID the same as the UUID, and the global one simply the URL (which includes the UUID)? Clarifications may be in order here, perhaps with an example. - Page 3 also states that the resource may be moved by an implementation to some other implementation. If so, it is according to the text permissible to not know the new URL for the resource. How will the user find out about this new URL, if she is given a HTTP 410 Gone message by the site she submitted the resource to? - On Page 4, given the presence of "Requests", it is not clear to me what should be considered an "Update" or a "Request". Is there a semantic difference between the two, and if so, what is it? - Page 6, at the "DELETE" operation, there is a note that everything "under" a resource is deleted. What does this mean, specifically? - On Page 6, Collections are mentioned, and that they will be rendered as Atom feeds. Are collections (as Atom feeds) to be accepted as input to some/all operations? Could examples of this be presented in that case? Please note that collections as input, and the related collections as output will require some special handling, since the Atom specification does not consider the Entries in a Feed to be ordered. Thus, the mapping from the output Entries to the input Entries must be made clear in the output. - Page 6 has an overfull hbox (in LaTeX terms, in English "text too long to fit on the paper") in the example, which makes reading the example impossible. Please fix! - On Pages 8 -- 10, it is unclear how most of the attributes will be mapped to Atom (starting with Section 4.4.4 "Status" and onward). What should be elements, and what should be attributes? The information needs to be represented somehow, and mappings to Atom Entry elements is not defined. Thus, they must be defined by the OCCI. - Monitoring is supposed to be supplied as an OCCI extension, but there is a set of attributes for reporting status on Page 8. How does the client get such status reports, and is monitoring intended to work in the same way? - Page 10 mentions the State machine, without presenting it. Perhaps it would be clearer to the reader if the state machine is included, given that the document describes how to alter the state of a (compute) resource? On that note, what are the state machines for the other types of resources? Best regards, -- Lars On Fri, 14 Aug 2009, Thijs Metsch wrote:
Hi @all,
The current version of the OCCI specification can be found here:
http://forge.ogf.org/sf/go/doc15731?nav=1
Please have a look with a special look on the attributes defined in the document? Are any missing? Are there to much? What about the naming?
We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome!
All the best,
-Thijs
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg