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).