Public comments are a very important part of the OGF document approval process. Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful. Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document. The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.
Thank you for making public comments on this document!
Comments for Document: Open Cloud Computing Interface - Core and Models
|Author(s):||A. Edmonds, S. Johnston, T. Metsch, G. Mazzaferro|
|Public Comment End:||22 Mar, 2010|
This later documentation is much improved and I found it to be clearer in regards to when and how different interfaces can be used. The example requests and responses, combined with the added "Tips" sections, provided a solid set of instructions for implementers/app developers.
My only recommendation for improvement would be to add diagrams and/or example screen shots (of human interfaces). For example, UML sequence and/or activity diagrams, for both a human and machine interface, we provide added clarity and differentiation.
I think this current document provides a strong foundation for implementers/app developers.
Page1: in abstract section: extensbible has a spelling error.
RDF/RDFa can representation a collection "content model" for occi properties and attributes either by explicate predicate relationships, predicate chaining or the definition of a collection element with explicate predicates as relationships. RDF/RDFa though chaining representations also "can" permit the definition of implicate relationships though element chaining.
XML has similar capabilities to organize occi information. Relationships including collections can be represented explicitly though the use of an explicate collection element, other elements and attributes or implicitly thought the definition of a hierarchical occi scheme.
The current definition of a collection does not imply or impose a specific scheme. Neither does it define elements and attribute to support a scheme. This specification does provide a definition for a link to a scheme definition. However, without definition of a scheme or a scheme definition specification interoperability of collection will be difficult to achieve and more difficult to administer.
This specification should include a recommendation, if not a definition, of three collection schemes, 1) an unordered list, 2) an ordered list, and 3) a directed graph. Each should define optional relationships to be considered for implementations.
The Collection has an attribute call "label". Reusing the common attributes' "title" attribute instead of the new "label" attribute should be considered.
Each Collection should contain the common attributes' "id" attribute to aid with the provider based unique identifier for the collection, the practice used for occi resources.
I note that RFC 2119 words seem to be used, would it not be better to use them in the "standard" format and to refer to RFC 2119.
Is not the "Link:" header field deprecated, being defined in RFC 2068 but not RFC 2616.
1.2.2 is slightly confusing in that it refers to a GET on /, yet the example shows a GET on /-/ which is not explained till 1.4. It would be helpful to show the result of the category search first (one result of which presumably would be "compute" and the second search is then performed - see Example 3)
Section 1.3.2 mentions that there is a peer review process for adding new standard actions, but provides no reference to it.
The Tips are quite useful, although they aren't always tips but more like explanatory notes. Maybe the tips that are notes should be called notes.
In example 3 (p. 9), how is the URL /-/compute/us-west to be understood - the previous query returned "compute" and "us-west" (but in different schemes) - are the categories combined, and if so, what happens to the scheme.
canada goose jackets can be cognizant of find out a new keep that will carries these people along with actually effort a number of varieties in initial, employing detect through the rating along with items that will operate specially most appropriate, and then employ that will material to get your variations excellent throughout comfortable different
canada goose outlet versions on-line. However it seems like sophisticated, your demanding element merely have to be accomplished while. It can be necessary to reveal the on-line sneaker shop that will will allow for pertaining to absolutely for no extra charge dividends.
canada goose jacket after which it hunt for cool, popular sneakers on the inside those people restrictions. This will likely be certain your incredibly more effective go with and quite a few convenience every single along with whenever.