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
<garymazzaferro@gmail.com> 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