[occi-wg] Query uniqueness
Gary Mazz
garymazzaferro at gmail.com
Mon Apr 11 10:57:14 CDT 2011
Hi Ralf,
I think the rule is on page 5 of the http document in section 3.3.1:
/Location paths tell the client where all resource instance *of one
Kind or Mixin *(in case
the Mixin is used as a tag) can be found regardless of the hierarchy
the service provider de fines./
This should be made clearer..
Other stuff inline
I think your explanation needs to go in section 3.3.1
-gary
On 4/11/2011 9:21 AM, Ralf Nyren wrote:
>
> 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/
>
ok ---good. We can have a unique Kind/Mixin instance, each with a unique
named space. If one or more are of same Kind/Mixin specification, they
can share a named space
>
> 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/.
>
But, Kind/Mixin instances with different specifications cannot resolve
to the same named space.
>
> 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.
>
Ok, I guess this would pertain to other 'locationed" objects.
> /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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20110411/1e1e4204/attachment.html
More information about the occi-wg
mailing list