[occi-wg] Query uniqueness

[Gary Mazz]

Hi Andre,

You need to keep a registry of all Categories and Mixins on a per 
provider basis. ie a running occi interface.

Where we get into trouble is cross provider portability if a provider 
shares named spaces between consumers or if there is named space 
aliasing between provider named spaces.

Mixin and named space reconciliation between consumers and provider as 
well as reconciliation between providers will be an ongoing issue that 
occi does not address. That is why I'm posting these emails picking out 
details of inferred practices so a best practices guide can be compiled 
from the emails. Hopefully the guide will alert implementers to 
interoperability areas not solved with technologies.

-gary


On 4/11/2011 9:51 AM, Andre Merzky wrote:
> On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf at nyren.net>  wrote:
>> 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.
> which basically means that you need a registry of valid mixins?
>
> A.
>
>
>
>> /Ralf
>>
>> On Sun, 10 Apr 2011 14:34:12 -0600, Gary Mazz<garymazzaferro at gmail.com>
>> 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
>> <  X-OCCI-Location: http://example.com/vms/user1/vm2
>> <  X-OCCI-Location: http://example.com/vms/user2/vm1
>>
>> 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 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#. 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#  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#"
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>
>