glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of David Horat said:
I just commited my first draft, which does not include any foreign keys. You can check it at our SVN: http://forge.ogf.org/svn/repos/glue/LDAP2/
I'm just getting back to this after CHEP and Easter ... I'll reply to some of the individual mails, but I want to start with the question of how you've dealt with inheritance, because looking at your draft it seems to me that what you have is the worst of both worlds. As I understand it what you've done is not to use LDAP inheritance, i.e. the objects don't carry the parent objectclass(es), you just explicitly put the inherited attributes into the derived objectclass definitions. I can basically see two downsides to that, which go in opposite directions. One is that because the objectclasses aren't inherited you can't do a generic search for all objects of a given type - for example, doing objectclass=Service won't get the derived ComputingService and StorageService objects. On the other hand, keeping the inherited attribute names is potentially confusing. For example, in ComputingShare you have attributes called EntityName, ShareDescription and ComputingShareMappingQueue, so if people are just working with the ComputingService attributes, e.g. in the JDL, they will have to remember that some attributes are inherited and hence have different name formats. Another point maybe relates particularly to the ID, which is that if the ID of every object is called EntityID you can't tell what kind of object it refers to, and we need a globally unique ID space. I'm not immediately sure if that's a plus or a minus but it's certainly a change from current practice, where the UniqueID of each object type has its own name and where the IDs of objects of different types can be and often are identical. It seems to me that we should go one way or the other, either do it properly using inherited objectclasses or redefine and rename the attributes for each derived type. In principle it could be done differently for each case but that might well be even more confusing and I'm not sure what the argument would be for that - except perhaps for Entity where I could see a case for not explicitly inheriting it even if everything else were done with inheritance. I think my inclination is to use "real" inheritance because it will help in writing general tools, e.g. to query for the endpoints for all services - the alternative will be to always have to remember to add extra filter clauses for the special types, and to add more extra clauses if we ever introduce any more derived types. Stephen -- Scanned by iCritical.