Hi, 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. 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. There is a mention of an "entity_type" to "Entity type uniquely identi fied 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 It looks like the query name is the category's "term" but we do not have a way to filter in specific schemes. cheers, gary
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
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 defi nition which de fined 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
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@gmail.com [5] http://schemas.ogf.org/occi/core [6] http://provider.com/blah [7] http://schemas.ogf.org/occi/core
On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren <ralf@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- So much time, so little to do... [Garfield]
On Mon, 11 Apr 2011 18:51:04 +0300, Andre Merzky <andre@merzky.net> wrote:
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?
You need a registry of all Mixins visible to a particular user, yes. Not sure if that is what you meant. A simple registry could be a hash-map with "location" as the key and the Mixin object as value. When a user attempts to add a Mixin check the hash-map, if location is already there, return a Bad Request. Which Mixins are valid or not in terms of scheme + term is up to the provider to decide (afaik). /Ralf
Ralf, Leaving architectural components as simply "not implemented" may be considered 'inoperable' and defeats the purpose of interoperability, at least in some circles. :) A provider may implement a protected feature making their occi mixin unique to their infrastructure enforcing vendor lock-in. Its probably not desirable to go down that path. We need to address that issue sometime soon. cheers gary On 4/11/2011 9:59 AM, Ralf Nyren wrote:
On Mon, 11 Apr 2011 18:51:04 +0300, Andre Merzky<andre@merzky.net> wrote:
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? You need a registry of all Mixins visible to a particular user, yes. Not sure if that is what you meant.
A simple registry could be a hash-map with "location" as the key and the Mixin object as value. When a user attempts to add a Mixin check the hash-map, if location is already there, return a Bad Request.
Which Mixins are valid or not in terms of scheme + term is up to the provider to decide (afaik).
/Ralf
From my POV, there shouldn't be any doubts about what must, should or could be implemented. The specs respect RFC2119.
In regards to interoperability, it is for this aspect why we have the query interface. Here's an example that might highlight it's use. We have provider A, provider B and C. Customer X has a deployment on provider A but because provider A insulted X's mother, X is leaving that provider! He's scripted a fancy client that does the following to ensure his insult-driven migration can take place: 1. get a list of all known providers [A, B, C] 2. iterate through each provider's query interface comparing available features to required features - only C in this case. We can think of this as ensuring the current "SLA" offered by A. 3. C is found to have all required features (virtual hardware, OSes), including mandatory OCCI features. 4. Given that X's architecture is one based on non-persistent application VMs, X's client can now provision the required resources with C, execute their deployment scripts and then use other facilitates to move redirect data location (e.g. CDMI). Incidentally it is not the reprovisioning of resources that's the challenge but rather the relocation of application data. 5. X is now free to repoint DNS records to the new services and tear down the old services on provider A while simultaneously giving A the bird :p What OCCI guarantees here is a basic service "quality", where that quality is a set of features and functions (IaaS ones are defined in the IaaS spec). Anything outside of that document is of course vendor specific however the more useful and demand-of such a specificity the more it will become common place, at which time would indicate to this group (us) the warrantying of its standardisation. The scenario is basic, however this type of scenario will be further investigated not only here within OCCI but also in the forming DCI-Fed/IaaSICP OGF group. .2c Andy andy.edmonds.be On Mon, Apr 11, 2011 at 17:30, Gary Mazz <garymazzaferro@gmail.com> wrote:
Ralf,
Leaving architectural components as simply "not implemented" may be considered 'inoperable' and defeats the purpose of interoperability, at least in some circles. :)
A provider may implement a protected feature making their occi mixin unique to their infrastructure enforcing vendor lock-in. Its probably not desirable to go down that path. We need to address that issue sometime soon.
cheers gary
On 4/11/2011 9:59 AM, Ralf Nyren wrote:
On Mon, 11 Apr 2011 18:51:04 +0300, Andre Merzky<andre@merzky.net> wrote:
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? You need a registry of all Mixins visible to a particular user, yes. Not sure if that is what you meant.
A simple registry could be a hash-map with "location" as the key and the Mixin object as value. When a user attempts to add a Mixin check the hash-map, if location is already there, return a Bad Request.
Which Mixins are valid or not in terms of scheme + term is up to the provider to decide (afaik).
/Ralf
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi, This started as a discussion on the application of the location attribute for resources categories and mixins.. And, which policies should be implemented where. How the location named spaces are applied is somewhat unclear to a casual reader. Which leads to poor location naming practices. There is an addition issue of which naming practices should be restricted at the provider by enforcement technology. Obviously, this impacts the provider's occi implementations. The issue of a registry was brought up by Andre, I was assuming he was considering a centralized registry for mixins to prevent location named space aliasing.. But reconciliation can easily be handled at the provider. Providers simply rejecting named space collision and foreign mixins do little for interoperability and is currently out of scope. However, it does not mean we cannot suggest best practices to address issues not in scope of the specification. BTW, did you get to see what kind of bird that was ? a magpie? -g On 4/11/2011 11:06 AM, Andy Edmonds wrote:
From my POV, there shouldn't be any doubts about what must, should or could be implemented. The specs respect RFC2119.
In regards to interoperability, it is for this aspect why we have the query interface. Here's an example that might highlight it's use.
We have provider A, provider B and C. Customer X has a deployment on provider A but because provider A insulted X's mother, X is leaving that provider! He's scripted a fancy client that does the following to ensure his insult-driven migration can take place:
1. get a list of all known providers [A, B, C] 2. iterate through each provider's query interface comparing available features to required features - only C in this case. We can think of this as ensuring the current "SLA" offered by A. 3. C is found to have all required features (virtual hardware, OSes), including mandatory OCCI features. 4. Given that X's architecture is one based on non-persistent application VMs, X's client can now provision the required resources with C, execute their deployment scripts and then use other facilitates to move redirect data location (e.g. CDMI). Incidentally it is not the reprovisioning of resources that's the challenge but rather the relocation of application data. 5. X is now free to repoint DNS records to the new services and tear down the old services on provider A while simultaneously giving A the bird :p
What OCCI guarantees here is a basic service "quality", where that quality is a set of features and functions (IaaS ones are defined in the IaaS spec). Anything outside of that document is of course vendor specific however the more useful and demand-of such a specificity the more it will become common place, at which time would indicate to this group (us) the warrantying of its standardisation.
The scenario is basic, however this type of scenario will be further investigated not only here within OCCI but also in the forming DCI-Fed/IaaSICP OGF group.
.2c
Andy andy.edmonds.be <http://andy.edmonds.be>
On Mon, Apr 11, 2011 at 17:30, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
Ralf,
Leaving architectural components as simply "not implemented" may be considered 'inoperable' and defeats the purpose of interoperability, at least in some circles. :)
A provider may implement a protected feature making their occi mixin unique to their infrastructure enforcing vendor lock-in. Its probably not desirable to go down that path. We need to address that issue sometime soon.
cheers gary
On 4/11/2011 9:59 AM, Ralf Nyren wrote: > On Mon, 11 Apr 2011 18:51:04 +0300, Andre Merzky<andre@merzky.net <mailto:andre@merzky.net>> wrote: > >>> 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? > You need a registry of all Mixins visible to a particular user, yes. Not > sure if that is what you meant. > > A simple registry could be a hash-map with "location" as the key and the > Mixin object as value. When a user attempts to add a Mixin check the > hash-map, if location is already there, return a Bad Request. > > Which Mixins are valid or not in terms of scheme + term is up to the > provider to decide (afaik). > > /Ralf > > >
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
BTW: HTTP spec also says on user-defined mix-in creation: The service might reject this request if it does not allow user-defined \hl{Mixin}s to be created. Also on name collisions of the defined location path the service provider MAY reject this operation. -Thijs -----Original Message----- From: occi-wg-bounces@ogf.org on behalf of Ralf Nyren Sent: Mon 11.04.2011 17:59 To: Andre Merzky Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Query uniqueness On Mon, 11 Apr 2011 18:51:04 +0300, Andre Merzky <andre@merzky.net> wrote:
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?
You need a registry of all Mixins visible to a particular user, yes. Not sure if that is what you meant. A simple registry could be a hash-map with "location" as the key and the Mixin object as value. When a user attempts to add a Mixin check the hash-map, if location is already there, return a Bad Request. Which Mixins are valid or not in terms of scheme + term is up to the provider to decide (afaik). /Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi Thijs, Thanks for the pointer to the guidelines.. I think we need to be a little more rigid than generic web technologies. We just need to identify issues and develop practices to resolve them. Once technology and practices are defined they can be made testable for certification by independent services or govt agencies. -gary On 4/11/2011 10:45 AM, Thijs Metsch wrote:
BTW: HTTP spec also says on user-defined mix-in creation:
The service might reject this request if it does not allow user-defined \hl{Mixin}s to be created. Also on name collisions of the defined location path the service provider MAY reject this operation.
-Thijs
-----Original Message----- From: occi-wg-bounces@ogf.org on behalf of Ralf Nyren Sent: Mon 11.04.2011 17:59 To: Andre Merzky Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Query uniqueness
On Mon, 11 Apr 2011 18:51:04 +0300, Andre Merzky <andre@merzky.net> wrote:
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?
You need a registry of all Mixins visible to a particular user, yes. Not sure if that is what you meant.
A simple registry could be a hash-map with "location" as the key and the Mixin object as value. When a user attempts to add a Mixin check the hash-map, if location is already there, return a Bad Request.
Which Mixins are valid or not in terms of scheme + term is up to the provider to decide (afaik).
/Ralf
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi Gary, Ralf, On Mon, Apr 11, 2011 at 7:20 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Hi Andre,
You need to keep a registry of all Categories and Mixins on a per provider basis. ie a running occi interface.
Thanks for clarifying to both of you!
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.
Yeah, that is what I wondered about, really... It remains to be seen if that turns out to be a real problem I guess.
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.
I think there are quite a number of places in OCCI where not all details are fully specified. OTOH, I don't think it is a weakness of OCCI, at all, as it helps to maintain OCCI's flexibility to cater to different usage domains. But I certainly agree that it is important to understand those issues, and to document them - otherwise interop will be difficult. So, I'd very much encourage you to publish best practices - as wiki, or as OGF informational document, or in any other forms. For example, it might be worth to propose a naming scheme as best practice which avoids collisions, like to encourage to use '/provider-mixin/' as name (e.g. /gary-network/). Or whatever you guys consider appropriate :-) Cheers, Andre.
-gary
On 4/11/2011 9:51 AM, Andre Merzky wrote:
On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- So much time, so little to do... [Garfield]
Not sure whether I really understand the problem. Am 11.04.2011 um 14:05 schrieb Andre Merzky:
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.
Yeah, that is what I wondered about, really... It remains to be seen if that turns out to be a real problem I guess.
So what exactly do you mean by "if a provider shares named spaces between consumers"? If it's about a certain location path, the provider is free to (depending on the authorization decision in the backend) to show "a, b, and c" to consumer X, while showing "d, e, and f" to the consumer Y for a given location path -- I don't see what would be against that. If this really would be forbidden, we should clarify. Considering the aliasing named space between providers, I feel that I don't fully understand the use case.
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.
I think there are quite a number of places in OCCI where not all details are fully specified. OTOH, I don't think it is a weakness of OCCI, at all, as it helps to maintain OCCI's flexibility to cater to different usage domains. But I certainly agree that it is important to understand those issues, and to document them - otherwise interop will be difficult. So, I'd very much encourage you to publish best practices - as wiki, or as OGF informational document, or in any other forms.
I guess that we are all agreeing on the fact that some kind of OCCI 101 is necessary. Andre and I discussed that in Taipeh already, and maybe Thijs and I could start with something... I'd be very happy to do some "tutorial" style work there.
For example, it might be worth to propose a naming scheme as best practice which avoids collisions, like to encourage to use '/provider-mixin/' as name (e.g. /gary-network/). Or whatever you guys consider appropriate :-)
Hm, I don't know. As long as the namespaces of the scheme/term stuff does not collide, everything should be fine. Maybe this is really the part missing, but I might be misunderstanding the issue... Best, Alexander
On 4/11/2011 9:51 AM, Andre Merzky wrote:
On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- So much time, so little to do... [Garfield] _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi In Line On 4/11/2011 10:08 PM, alexander.papaspyrou@tu-dortmund.de wrote:
Not sure whether I really understand the problem.
Am 11.04.2011 um 14:05 schrieb Andre Merzky:
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. Yeah, that is what I wondered about, really... It remains to be seen if that turns out to be a real problem I guess. So what exactly do you mean by "if a provider shares named spaces between consumers"? If it's about a certain location path, the provider is free to (depending on the authorization decision in the backend) to show "a, b, and c" to consumer X, while showing "d, e, and f" to the consumer Y for a given location path -- I don't see what would be against that. If this really would be forbidden, we should clarify.
Considering the aliasing named space between providers, I feel that I don't fully understand the use case.
Name space collisions can occur between provider and consumers and between providers and providers. Maintaining the uniqueness of a consumer name space is not a requirement for occi., so collisions can occur. We need practices to handle those conditions consistently across consumers and providers. .
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. I think there are quite a number of places in OCCI where not all details are fully specified. OTOH, I don't think it is a weakness of OCCI, at all, as it helps to maintain OCCI's flexibility to cater to different usage domains. But I certainly agree that it is important to understand those issues, and to document them - otherwise interop will be difficult. So, I'd very much encourage you to publish best practices - as wiki, or as OGF informational document, or in any other forms. I guess that we are all agreeing on the fact that some kind of OCCI 101 is necessary. Andre and I discussed that in Taipeh already, and maybe Thijs and I could start with something... I'd be very happy to do some "tutorial" style work there.
For example, it might be worth to propose a naming scheme as best practice which avoids collisions, like to encourage to use '/provider-mixin/' as name (e.g. /gary-network/). Or whatever you guys consider appropriate :-) Hm, I don't know. As long as the namespaces of the scheme/term stuff does not collide, everything should be fine. Maybe this is really the part missing, but I might be misunderstanding the issue... We need to ponder this thought.. Best, Alexander
On 4/11/2011 9:51 AM, Andre Merzky wrote:
On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- So much time, so little to do... [Garfield] _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
RIght, maybe we should just add a sentence that a namespace SHOULD be within a DNS domain name managed by the corresponding provider (as, for example, Sun recommended for Java package names). I think this is what also the XML namespace people recommend. -Al. Am 11.04.2011 um 23:48 schrieb Gary Mazz:
Hi
In Line
On 4/11/2011 10:08 PM, alexander.papaspyrou@tu-dortmund.de wrote:
Not sure whether I really understand the problem.
Am 11.04.2011 um 14:05 schrieb Andre Merzky:
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. Yeah, that is what I wondered about, really... It remains to be seen if that turns out to be a real problem I guess. So what exactly do you mean by "if a provider shares named spaces between consumers"? If it's about a certain location path, the provider is free to (depending on the authorization decision in the backend) to show "a, b, and c" to consumer X, while showing "d, e, and f" to the consumer Y for a given location path -- I don't see what would be against that. If this really would be forbidden, we should clarify.
Considering the aliasing named space between providers, I feel that I don't fully understand the use case.
Name space collisions can occur between provider and consumers and between providers and providers. Maintaining the uniqueness of a consumer name space is not a requirement for occi., so collisions can occur. We need practices to handle those conditions consistently across consumers and providers. .
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. I think there are quite a number of places in OCCI where not all details are fully specified. OTOH, I don't think it is a weakness of OCCI, at all, as it helps to maintain OCCI's flexibility to cater to different usage domains. But I certainly agree that it is important to understand those issues, and to document them - otherwise interop will be difficult. So, I'd very much encourage you to publish best practices - as wiki, or as OGF informational document, or in any other forms. I guess that we are all agreeing on the fact that some kind of OCCI 101 is necessary. Andre and I discussed that in Taipeh already, and maybe Thijs and I could start with something... I'd be very happy to do some "tutorial" style work there.
For example, it might be worth to propose a naming scheme as best practice which avoids collisions, like to encourage to use '/provider-mixin/' as name (e.g. /gary-network/). Or whatever you guys consider appropriate :-) Hm, I don't know. As long as the namespaces of the scheme/term stuff does not collide, everything should be fine. Maybe this is really the part missing, but I might be misunderstanding the issue... We need to ponder this thought.. Best, Alexander
On 4/11/2011 9:51 AM, Andre Merzky wrote:
On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- So much time, so little to do... [Garfield] _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
We need a practices guide.. On 4/12/2011 8:39 AM, alexander.papaspyrou@tu-dortmund.de wrote:
RIght, maybe we should just add a sentence that a namespace SHOULD be within a DNS domain name managed by the corresponding provider (as, for example, Sun recommended for Java package names). I think this is what also the XML namespace people recommend.
-Al.
Am 11.04.2011 um 23:48 schrieb Gary Mazz:
Hi
In Line
On 4/11/2011 10:08 PM, alexander.papaspyrou@tu-dortmund.de wrote:
Not sure whether I really understand the problem.
Am 11.04.2011 um 14:05 schrieb Andre Merzky:
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. Yeah, that is what I wondered about, really... It remains to be seen if that turns out to be a real problem I guess. So what exactly do you mean by "if a provider shares named spaces between consumers"? If it's about a certain location path, the provider is free to (depending on the authorization decision in the backend) to show "a, b, and c" to consumer X, while showing "d, e, and f" to the consumer Y for a given location path -- I don't see what would be against that. If this really would be forbidden, we should clarify.
Considering the aliasing named space between providers, I feel that I don't fully understand the use case.
Name space collisions can occur between provider and consumers and between providers and providers. Maintaining the uniqueness of a consumer name space is not a requirement for occi., so collisions can occur. We need practices to handle those conditions consistently across consumers and providers. .
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. I think there are quite a number of places in OCCI where not all details are fully specified. OTOH, I don't think it is a weakness of OCCI, at all, as it helps to maintain OCCI's flexibility to cater to different usage domains. But I certainly agree that it is important to understand those issues, and to document them - otherwise interop will be difficult. So, I'd very much encourage you to publish best practices - as wiki, or as OGF informational document, or in any other forms. I guess that we are all agreeing on the fact that some kind of OCCI 101 is necessary. Andre and I discussed that in Taipeh already, and maybe Thijs and I could start with something... I'd be very happy to do some "tutorial" style work there.
For example, it might be worth to propose a naming scheme as best practice which avoids collisions, like to encourage to use '/provider-mixin/' as name (e.g. /gary-network/). Or whatever you guys consider appropriate :-) Hm, I don't know. As long as the namespaces of the scheme/term stuff does not collide, everything should be fine. Maybe this is really the part missing, but I might be misunderstanding the issue... We need to ponder this thought.. Best, Alexander
On 4/11/2011 9:51 AM, Andre Merzky wrote:
On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf@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@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@ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg > >
-- So much time, so little to do... [Garfield] _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Yes, I agree. The question is whether the statement below should move into future revisions of OCCI core as well... -Al. Am 12.04.2011 um 09:50 schrieb Gary Mazz:
We need a practices guide..
On 4/12/2011 8:39 AM, alexander.papaspyrou@tu-dortmund.de wrote:
RIght, maybe we should just add a sentence that a namespace SHOULD be within a DNS domain name managed by the corresponding provider (as, for example, Sun recommended for Java package names). I think this is what also the XML namespace people recommend.
-Al.
Am 11.04.2011 um 23:48 schrieb Gary Mazz:
Hi
In Line
On 4/11/2011 10:08 PM, alexander.papaspyrou@tu-dortmund.de wrote:
Not sure whether I really understand the problem.
Am 11.04.2011 um 14:05 schrieb Andre Merzky:
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. Yeah, that is what I wondered about, really... It remains to be seen if that turns out to be a real problem I guess. So what exactly do you mean by "if a provider shares named spaces between consumers"? If it's about a certain location path, the provider is free to (depending on the authorization decision in the backend) to show "a, b, and c" to consumer X, while showing "d, e, and f" to the consumer Y for a given location path -- I don't see what would be against that. If this really would be forbidden, we should clarify.
Considering the aliasing named space between providers, I feel that I don't fully understand the use case.
Name space collisions can occur between provider and consumers and between providers and providers. Maintaining the uniqueness of a consumer name space is not a requirement for occi., so collisions can occur. We need practices to handle those conditions consistently across consumers and providers. .
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. I think there are quite a number of places in OCCI where not all details are fully specified. OTOH, I don't think it is a weakness of OCCI, at all, as it helps to maintain OCCI's flexibility to cater to different usage domains. But I certainly agree that it is important to understand those issues, and to document them - otherwise interop will be difficult. So, I'd very much encourage you to publish best practices - as wiki, or as OGF informational document, or in any other forms. I guess that we are all agreeing on the fact that some kind of OCCI 101 is necessary. Andre and I discussed that in Taipeh already, and maybe Thijs and I could start with something... I'd be very happy to do some "tutorial" style work there.
For example, it might be worth to propose a naming scheme as best practice which avoids collisions, like to encourage to use '/provider-mixin/' as name (e.g. /gary-network/). Or whatever you guys consider appropriate :-) Hm, I don't know. As long as the namespaces of the scheme/term stuff does not collide, everything should be fine. Maybe this is really the part missing, but I might be misunderstanding the issue... We need to ponder this thought.. Best, Alexander
On 4/11/2011 9:51 AM, Andre Merzky wrote: > On Mon, Apr 11, 2011 at 6:21 PM, Ralf Nyren<ralf@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@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@ogf.org >> http://www.ogf.org/mailman/listinfo/occi-wg >> >>
-- So much time, so little to do... [Garfield] _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- So much time, so little to do... [Garfield] _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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
participants (6)
-
alexander.papaspyrou＠tu-dortmund.de -
Andre Merzky -
Andy Edmonds -
Gary Mazz -
Ralf Nyren -
Thijs Metsch