Hi Al Agreed, but the spec doesn't say that. We've been looking at the specs and have a severe bias, at least in terms of implied meaning, that other readers don't have. The policy for managing the name space is critical to ensure interoperability across providers. We need a reference for the start of the user name space. For example, the provider may organize consumer facing name spaces by [authority, user name space, location] while others may use [authority, location] and other may offer [authority, [user defined name spaces], location] . Each scheme has its own merits and proprietary value, we just need to way to reconcile the start of the user's name space so transposition works the same way across providers. Having said all that and a personal preference, I strongly endorse the idea the OCCI HTTP specification mandating a fixed name space. Right now we don't. I just have a tough time believing that a fixed scheme fits all grid, private cloud and other provider naming conventions and feel obligated to support them. -g On 4/7/2011 2:22 AM, alexander.papaspyrou@tu-dortmund.de wrote:
Hi Gary,
even for multi-tenant systems, this shouldn't be a problem: GETting the location path should only give back those resources that are supposed to be visible to the customer. Even more: from the specs perspective, noone prevents an implementor from giving back different locations, depending on the principal of the GET request (at least that's how I would interpret it).
-Alexander
Am 07.04.2011 um 06:32 schrieb Gary Mazz:
Hi,
The location is defined :
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 language poses a problem in multi-tenant and where Kind/Mixins are placed in hierarchically managed name spaces. Stating the location is reference at the user's (consumer's) top level name space may be a clearer way of defining its role.
cheers, gary _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg