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