[glue-wg] Question about ssociation end and inherited association end

[David Horat]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/glue-wg/attachments/20090330/b9553adb/attachment.html