[occi-wg] Query uniqueness

Mon Apr 11 22:58:22 CDT 2011

Not really, as long as things are unique within the URL namespace your service governs.

-Al.

Am 11.04.2011 um 10:51 schrieb Andre Merzky:

> 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
>> 
>> 
> 
> 
> 
> -- 
> So much time, so little to do...
> [Garfield]
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg