see below...
I'm not sure about the following: * Only show mutable attributes in the query interface
This I feel to be very important indeed. Without this change an OCCI client _cannot_ use the query interface to determine the requirements for a successful POST request!
To understand the issue you must think from a OCCI client perspective. The "attributes" listed for each Category is used by a client to determine which attributes to submit when doing a POST of a new resource instance. A well-behaved OCCI service impl will return a Bad Request error if a client tries to change an immutable attribute. Therefore the "attributes" list must only include mutable attributes.
Example: - Client queries /-/ and finds the "compute" resource. - The "attributes" parameter includes occi.compute.state, occi.compute.speed, etc - Client presents the attributes found for "compute" to (in this example) an end-user - The end-user sets desired values for all attributes and asks the OCCI client to create a new compute resource instance. - The dutiful OCCI client then sends occi.compute.state in the POST request to the OCCI service implementation. - Since occi.compute.state is immutable the well-behaved OCCI service will return a Bad Request. - The spec does not define how to interpret the cause of a particular Bad Request error so now the OCCI client doesn't know why the POST request failed.
The best solution would be to somehow include the mutability of all attributes in the query interface. The quick and dirty solution is to only include mutable attributes in the query interface.
well indeed quick and dirty :-) I see you're point and would suggest we express the mutability in the query interface but for all attributes... Cheers, -Thijs