Question about ssociation end and inherited association end
In the GLUE Specification v. 2.0, page 9, there is the Location class, which has: Association.End: Service.ID Domain.ID Inherited association end: Extension.Key ComputingService.ID StorageService.ID AdminDomain.ID UserDomain.ID This seems to try to represent the fact that making a relationship with a class, you are also making it with all its subclasses. From the theoretical point of view, you can not imply that pointing to a class you have access to its subclasses, but just to its superclasses because of the definition of inheritance in the object oriente programming. Moreover, this is misleading because it depends on the implementation language whether you can cast a subclass of the current class without knowing exactly the current class. So I would propose two solutions here depending on what you wanted to describe: 1) Add ComputingService, StorageService, AdminDomain and UserDomain to the Association End list if you really want to access attributes exclusively from those in the Location class, which will add more Foreign Key attributes. 2) Just taking them out from the Inherited Association End list if in the Location class you just want to have access to the attributes of the Service and Domain classes. Regards, David -- David Horat Software Engineer specialized in Grid and Web technologies IT Department – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Phone +41 22 76 77996 http://davidhorat.com/ http://cern.ch/horat http://www.linkedin.com/in/davidhorat
On Friday 27 March 2009 09:51:51 David Horat wrote:
In the GLUE Specification v. 2.0, page 9, there is the Location class, which has:
Association.End: Service.ID Domain.ID
Inherited association end: Extension.Key ComputingService.ID StorageService.ID AdminDomain.ID UserDomain.ID
This seems to try to represent the fact that making a relationship with a class, you are also making it with all its subclasses.
True.
From the theoretical point of view, you can not imply that pointing to a class you have access to its subclasses, but just to its superclasses because of the definition of inheritance in the object oriente programming.
Sure, but I don't think that's what is being represented here.
Moreover, this is misleading because it depends on the implementation language whether you can cast a subclass of the current class without knowing exactly the current class.
Actually, I think this is a documentation "error" resulting from a conflation of two different types of inheritance: the two ends of the association may suffer inheritance. Using Location as an example, we have the (primary) associations Location: ----> Service.ID ----> Domain.ID We also have the inherited association ends from _super_classes of Location Location (is-a Entity): ----> Extension.LocalID and we have the inherited association end from the _sub_classes of the remote end classes Location: ----> ComputingService.ID (ComputingService is-a Service) ----> StorageService.ID (StorageService is-a Service) ----> AdminDomain.ID (AdminDomain is-a Domain) ----> UserDomain.ID (UserDomain " " ) What is perhaps confusing is these two types of inherited association ends are documented together.
So I would propose two solutions here depending on what you wanted to describe:
1) Add ComputingService, StorageService, AdminDomain and UserDomain to the Association End list if you really want to access attributes exclusively from those in the Location class, which will add more Foreign Key attributes.
2) Just taking them out from the Inherited Association End list if in the Location class you just want to have access to the attributes of the Service and Domain classes.
I'm not completely sure what you're proposing here .. and the current SVN doesn't seem to contain any links. Currently, in Glue 1.3, these links are published as GlueForeignKey (iirc), with syntax like: GlueForeignKey = RDN GlueForeignKey = <KEY>=<ID> (e.g. "GlueForeignKey=GlueSE=srm.example.org") This is somewhat ugly as any attribute can link to any other attribute and the client needs to process binding-specific values (i.e., the RDN above). Reading between the lines, it sounds like what you're proposing is attributes like the following: LocationServiceID=<Service.ID> LocationExtensionLocalID=<Extension.LocalID> for the Service.ID, Domain.ID and Extension.LocalID association ends respectively. Option 1) would add to the above list: LocationComputingServiceID=<ComputingService.ID>, LocationStorageServiceID=<StorageService.ID>, LocationUserDomainID=<UserDomain.ID> LocationAdminDomainID=<AdminDomain.ID> 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. Cheers, Paul. PS. Perhaps this is another erratum: improve the documentation, perhaps by separating the "locally" and "remotely" inherited association end (e.g., Extension.LocalID in Location and ComputingService.ID respectively).
Thank you for your feedback Paul. Yes, that is exactly what I meant. I would also go for Option 2 because it reflects clearly the relations stated in the specifications. I also agree that perhaps there is another erratum in the Inherited Association End list because there are two different kind of associations contained in this list: - The ones inherited from the super classes of the actual class - The ones "inherited" from the sub classes of the classes related to the actual class I used the quotes in "inherited" here because inheritance "always goes up".
From a definition of inheritance: "Inheritance is a way to form new classes using classes that have already been defined.". Thus, we may only talk of inherited relations from super classes.
Here, I see several possible solutions: a) Separate them into two parts of the table. A few examples: locally/remotely (as suggested by Paul) Inherited Association Ends from superclasses / Association Ends from subclasses of the relations b) Erase the ones "inherited" from the sub classes of the classes related to the actual class. This are already clear reviewing the specifications. Personally, I like this option because it is duplicated information. Regards, David On Mon, Mar 30, 2009 at 5:59 PM, Paul Millar <paul.millar@desy.de> wrote:
On Friday 27 March 2009 09:51:51 David Horat wrote:
In the GLUE Specification v. 2.0, page 9, there is the Location class, which has:
Association.End: Service.ID Domain.ID
Inherited association end: Extension.Key ComputingService.ID StorageService.ID AdminDomain.ID UserDomain.ID
This seems to try to represent the fact that making a relationship with a class, you are also making it with all its subclasses.
True.
From the theoretical point of view, you can not imply that pointing to a class you have access to its subclasses, but just to its superclasses because of the definition of inheritance in the object oriente programming.
Sure, but I don't think that's what is being represented here.
Moreover, this is misleading because it depends on the implementation language whether you can cast a subclass of the current class without knowing exactly the current class.
Actually, I think this is a documentation "error" resulting from a conflation of two different types of inheritance: the two ends of the association may suffer inheritance.
Using Location as an example, we have the (primary) associations
Location: ----> Service.ID ----> Domain.ID
We also have the inherited association ends from _super_classes of Location
Location (is-a Entity): ----> Extension.LocalID
and we have the inherited association end from the _sub_classes of the remote end classes
Location: ----> ComputingService.ID (ComputingService is-a Service) ----> StorageService.ID (StorageService is-a Service) ----> AdminDomain.ID (AdminDomain is-a Domain) ----> UserDomain.ID (UserDomain " " )
What is perhaps confusing is these two types of inherited association ends are documented together.
So I would propose two solutions here depending on what you wanted to describe:
1) Add ComputingService, StorageService, AdminDomain and UserDomain to the Association End list if you really want to access attributes exclusively from those in the Location class, which will add more Foreign Key attributes.
2) Just taking them out from the Inherited Association End list if in the Location class you just want to have access to the attributes of the Service and Domain classes.
I'm not completely sure what you're proposing here .. and the current SVN doesn't seem to contain any links.
Currently, in Glue 1.3, these links are published as GlueForeignKey (iirc), with syntax like:
GlueForeignKey = RDN GlueForeignKey = <KEY>=<ID>
(e.g. "GlueForeignKey=GlueSE=srm.example.org")
This is somewhat ugly as any attribute can link to any other attribute and the client needs to process binding-specific values (i.e., the RDN above).
Reading between the lines, it sounds like what you're proposing is attributes like the following:
LocationServiceID=<Service.ID> LocationExtensionLocalID=<Extension.LocalID>
for the Service.ID, Domain.ID and Extension.LocalID association ends respectively.
Option 1) would add to the above list: LocationComputingServiceID=<ComputingService.ID>, LocationStorageServiceID=<StorageService.ID>, LocationUserDomainID=<UserDomain.ID> LocationAdminDomainID=<AdminDomain.ID>
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.
Cheers,
Paul.
PS. Perhaps this is another erratum: improve the documentation, perhaps by separating the "locally" and "remotely" inherited association end (e.g., Extension.LocalID in Location and ComputingService.ID respectively).
-- David Horat Software Engineer specialized in Grid and Web technologies IT Department – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Phone +41 22 76 77996 http://davidhorat.com/ http://cern.ch/horat http://www.linkedin.com/in/davidhorat
glue-wg-bounces@ogf.org
[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. 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. 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. On the other hand I suspect that you would normally follow the reference the other way round. Stephen -- Scanned by iCritical.
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.
participants (3)
-
Burke, S (Stephen) -
David Horat -
Paul Millar