[occi-wg] Query uniqueness

Ralf Nyren ralf at nyren.net
Mon Apr 11 10:21:39 CDT 2011



Category.location (as found in the query interface) maps to an URI. The
term of the Category us unrelated to the location. 

The following is
valid: 

Category: compute;
scheme="http://schemas.ogf.org/occi/infrastructure#"; location=/my/vms/


The only rule is that two Categories cannot map to the same location. So
you cannot have two different Categories mapping to e.g. /compute/. 

This
means that with user-defined Mixins an OCCI service must refuse to create a
Mixin for which the specified location path already is taken. 

/Ralf 

On
Sun, 10 Apr 2011 14:34:12 -0600, Gary Mazz  wrote:  Ok,
 In this example:


RETRIEVING ALL RESOURCE INSTANCES BELONGING TO MIXIN OR KIND The HTTP verb
GET must be used to
 retrieve all resource instances. The service provider
MUST return a listing containing all resource
 instances which belong to
the requested Mixin or Kind:
 > GET /compute/ HTTP/1.1
 > [...]
 < HTTP/1.1
200 OK
 < [...]
 <
 < X-OCCI-Location: http://example.com/vms/user1/vm1
[1]
 < X-OCCI-Location: http://example.com/vms/user1/vm2 [2]
 <
X-OCCI-Location: http://example.com/vms/user2/vm1 [3]

 An OCCI
implementation MUST support a filtering mechanism. If a HTTP Category is
provided in the
 request the server MUST only return the resource instances
belonging to the provided Kind or Mixin.
 The provided HTTP category
definition SHOULD be different from the Kind or Mixin definition which

defined the location path used in the request.

 If an OCCI Entity
attribute (X-OCCI-Attribute) is provided in the request the server MUST
only return
 the resource instances which have a matching attribute
value.

 We see the the URI path '/compute/'. This name space confusion
comes into the picture.. Is the URI path, indicating the 'location'
specified by a category or is it the 'term' of the category? If it is the
"location" there is the possibility of returning back multiple categories
if the 'location' attribute is the same across multiple categories. If it
is the "term", there can be resources based on categories using the same
'term' but using differnt schemes.

 -gary

 On 4/10/2011 12:59 PM, Ralf
Nyren wrote: please see below: 

 On Sun, 10 Apr 2011 19:08:44 +0200, Gary
Mazz  [4] wrote: 

 Maybe I'm looking that the specifications too long, but
it seems you can 
 place more than one term in a query named space... for
example, a query 
 named space '/network/' could refer to both the occi
scheme and a 
 private scheme. 

 The namespace for different
Category/Kind/Mixin instances is defined by the scheme, e.g.
http://schemas.ogf.org/occi/core# [5]. In this case we talk about the
namespace for different types, i.e. Entity, Resource, Link, Compute,
Storage, etc. 

 We also talk about the namespace used for Entity IDs, i.e.
the IDs of resource instances in a system. In the case of the HTTP
Rendering this namespace is mapped to the URL namespace of HTTP. 

 To
further complicate things we have a mechanism of hooking a Kind/Mixin
instances into this HTTP URL namespace by use of the "location" parameter.
As you know a Kind or Mixin instance represents a collection of all
resource instances (Entity sub-type instances) associated with the Kind or
Mixin. This collection can be retrieved by querying the "location" URL. 


So to answer your question on the mapping of e.g. the "/network/" HTTP path
it depends if you have a Kind/Mixin hooked into that path or not. If there
is such a hook (i.e. you have a Category: ... location=/network/ somewhere
in the query interface) you will find the collection of the Kind/Mixin.
However if you do not have a Kind/Mixin location mapped at /network/ you
must follow the rules in section 3.4.2 "Operation on Paths in the
Name-space". 

 hmm... makes sense? :P 

 There is no requirement that
identical 'terms' used to describe a 
 resource category to have a similar
or the same functional 
 characteristics as terms defined in the occi
scheme. 

 You are free to define e.g. Category: compute;
scheme=http://provider.com/blah# [6] which is represents a coffee machine.
It might be slightly misleading but as long as you use your own scheme
namespace you can essentially do whatever you want. 

 There is a mention
of an "entity_type" to "Entity type uniquely 
 identi%0Cfied by the Kind
instance." However it doesn't say "entity_type" 
 uniquely "identifies" the
Kind Instance. The only way to uniquely 
 identify a Kind is by
scheme:term. And this leads back to the issue 
 with the query 

 The
Kind.entity_type is intended to contain a reference to the type (a class in
most OO langs) which is identified by the Kind. Example (python-ish): 

 #
Compute is a class which inherits Resource which inherits Entity. 

 # Thus
is the Kind instance which identifies the Compute type (class) defined: 

compute_kind = Kind() 
 compute_kind.term = "compute" 
 compute_kind.scheme
= "http://schemas.ogf.org/occi/core#" [7] 
 compute_kind.entity_type =
Compute 

 # If you want to create a new Compute instance you could do: 

class_ref = compute_kind.entity_type 
 my_compute = class_ref() 

 So
Kind.entity_type is a reference to the type which the Kind instance
identifies. This is of course not applicable to all programming languages
but the idea is that given an instance of Kind you should be able to find
out the Entity type it identifies. 

 /Ralf 

 

Links:
------
[1]
http://example.com/vms/user1/vm1
[2] http://example.com/vms/user1/vm2
[3]
http://example.com/vms/user2/vm1
[4] mailto:garymazzaferro at gmail.com
[5]
http://schemas.ogf.org/occi/core
[6] http://provider.com/blah
[7]
http://schemas.ogf.org/occi/core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20110411/ce751195/attachment-0001.html 


More information about the occi-wg mailing list