Re: [occi-wg] HTTP rendering doc out of public comment
@Ralf: Can you handle 4, 6?
np, will do.
6. For consistency OCCI Core attributes should be rendered with "occi.core." prepended. For example 'summary' would be rendered as 'occi.core.summary'.
The attributes in question would be: occi.core.title (defined by Entity) occi.core.summary (defined by Resource) occi.core.source (defined by Link) occi.core.target (defined by Link) Any attrib I missed? Using occi.core. prefix for Link.source/target doesn't feel perfect but I guess it could be okay.
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. regards, Ralf
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
On Wed, 30 Mar 2011 15:16:33 +0200, Thijs Metsch <tmetsch@platform.com>
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...
Sounds good to me, then we need to figure out a format to express this. Proposal ======== ABNF update (see section 3.5.1 in draft HTTP Rendering doc): ---- attribute-list = attribute-def | attribute-def *( 1*SP attribute-def) attribute-def = attribute-name | attribute-name "{" attribute-property *( 1*SP attribute-property) "}" attribute-property = "immutable" | "required" ---- The logic would be as follows: If no attribute properties are defined the attribute is _mutable_ and non-required (i.e. multiplicity 0..x). If the "immutable" property is set the attribute is immutable. If the "required" property is set the attribute has a multiplicity of 1..x, i.e. must be specified. /Ralf
+1 much better :-) Thanks Ralf! -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wed 30.03.2011 15:58 To: Thijs Metsch Cc: occi-wg@ogf.org Subject: Re: HTTP rendering doc out of public comment On Wed, 30 Mar 2011 15:16:33 +0200, Thijs Metsch <tmetsch@platform.com>
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...
Sounds good to me, then we need to figure out a format to express this. Proposal ======== ABNF update (see section 3.5.1 in draft HTTP Rendering doc): ---- attribute-list = attribute-def | attribute-def *( 1*SP attribute-def) attribute-def = attribute-name | attribute-name "{" attribute-property *( 1*SP attribute-property) "}" attribute-property = "immutable" | "required" ---- The logic would be as follows: If no attribute properties are defined the attribute is _mutable_ and non-required (i.e. multiplicity 0..x). If the "immutable" property is set the attribute is immutable. If the "required" property is set the attribute has a multiplicity of 1..x, i.e. must be specified. /Ralf
Hi Ralf, On Wed, Mar 30, 2011 at 2:55 PM, Ralf Nyren <ralf@nyren.net> wrote:
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.
I am not sure I understand that argument. Assume an OCCI backend has the speed attribute unmutable. Does your above argument mean that the client will not find that attribute listed, and would thus not be able to query for the (fixed) value of the speed attribute? Thanks, Andre.
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.
regards, Ralf
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- So much time, so little to do... [Garfield]
I am not sure I understand that argument. Assume an OCCI backend has the speed attribute unmutable. Does your above argument mean that the client will not find that attribute listed, and would thus not be able to query for the (fixed) value of the speed attribute?
The attribute would not be listed (or have an immutable property set) in the _query_ interface. Please note that the attributes presented in the query interface really only are interesting when _first_ creating a resource, i.e. a POST request. When you query an existing resource (i.e. GET) you would see all attributes, no matter whether they are mutable or immutable. regards, Ralf
occi.core.id (defined by Entity) -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Wednesday, March 30, 2011 3:55 PM To: tmetsch@platform.com; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP rendering doc out of public comment
@Ralf: Can you handle 4, 6?
np, will do.
6. For consistency OCCI Core attributes should be rendered with "occi.core." prepended. For example 'summary' would be rendered as 'occi.core.summary'.
The attributes in question would be: occi.core.title (defined by Entity) occi.core.summary (defined by Resource) occi.core.source (defined by Link) occi.core.target (defined by Link) Any attrib I missed? ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
participants (4)
-
Andre Merzky -
Edmonds, AndrewX -
Ralf Nyren -
Thijs Metsch