[glue-wg] Finalizing the LDAP implementation of GLUE 2.0

[David Horat]

Hello to everyone!

I am trying finalizing the initial draft of the LDAP implementation and have
a few questions that need to be resolved before I can finish.

Question 1:

In the Entity class on page 8 of the GLUE Specification, the Association.End
has just one field, Extension.Key, but in the Extension class its unique
identifier is LocalId.
The Extension.Key should probably not be used as its description is "This
identifier is not required to be unique; several instances of this class MAY
hold the same value of this attribute". So in the Entity class, should
Extension.LocalId be specified instead of Extension.Key?

Question 2:

The relations  in the association end list are always specified with the
attribute they have to link with. (E.g. Service.ID). There are several
reasons why this may not be a good idea.

a) In the Entity-Relationship models, relationships between
entities/classes/objects are generally specified without any knowledge of
each of the attributes in them.

b) To know which attribute you wish to link to from a related object, you
will need to to take a look at its definition to get the key field.

c) There could be more than one key field and sometimes the key of an entity
could be a combination of several fields, which would not work with the
current approach

As a solution I would suggest just taking out every attribute in all the
Association End lists.

Question 3:

>From the theoretical definition of inheritance, just by pointing to a class
we cannot be sure to have access to its subclasses, only to its
superclasses. As a solution I would propose to choice one of the following
depending on what we are trying to describe:

a) Add ComputingService, StorageService, AdminDomain and UserDomain to the
Association End list if we really would like to access attributes
exclusively from those in the Location class, which results in more Foreign
Key attributes.

b) Remove them from the Inherited Association End list if we just want to
have access to the attributes of the Service and Domain classes in the
Location class.

c) Just take out the Inherited Association End list and put in the
Association End list all the concrete classes we want to point out. I would
personally prefer this last option.


In addition to the questions above, I have three proposals on how to
implement the relationships and would appreciate some feedback on each of
them and which one is prefered.
1) Use an 'EntityFK' attribute (same as GlueForeignKey used in GLUE 1.3) in
every entity that has a relationship
2) Differentiate each final object in the relationship from its superclass
point of view. E.g. LocationFKService
3) Differentiate each final object in the relationship to the very concrete
classes we would like. E.g. LocationFKComputingService. I would personally
prefer this last option.

Also should we use 'FK' or 'ForeignKey'?.

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