On Friday 17 April 2009 12:23:21 Burke, S (Stephen) wrote:
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: Option 2) would allow publishing both Storage- and Computing- Service.ID values as LocationServiceID attributes; i.e., the following would be valid
LocationServiceID=<StorageService.ID> LocationServiceID=<ComputingService.ID> LocationDomainID=<UserDomain.ID> LocationDomainID=<AdminDomain.ID>
If this is all correct, I'd go for option 2) here.
Note that this interacts with the way inheritance is done and the question of whether IDs are globally unique.
Sure.
If there were separate attributes called ComputingServiceID and StorageServiceID and they were allowed to be identical then this scheme wouldn't work, but if every object has a globally unique EntityID then it's OK.
Quite true. I believe we defined IDs as being globally unique. This leaves unspecified how this is to be achieved in practise.
There is also an issue of whether you would want to know what kind of object is being referred to - i.e. with this scheme you can't tell from the Location object what kind of service/domain it relates to.
True, but I would take this as a natural consequence of inheritance. If one specifically want to know, one can always query the object at the end of the link explicitly.
On the other hand I suspect that you would normally follow the reference the other way round.
Yup, I'd imagine most uses will be to discover where something is as the reverse lookup ("which Services or Domains have this Location?") is not guaranteed to be complete. There could be multiple Location objects published describing the same physical location. Cheers, Paul.