Hi all, While writing the dCache GLUE2 info-provider, I came across a problem with the current GLUE2 LDAP binding. The problem is that inherited associations are represented twice. The schema uses three kinds of LDAP class: ABSTRACT, AUXILIARY and STRUCTURAL. ABSTRACT is only used for the LDAP class for Entity (GLUE2Entity), all objects that are a directly derived from Entity are STRUCTURAL, everything else is AUXILIARY. So: LDAP classes for Service and Share (GLUE2Service and GLUE2Share respectively) are STRUCTURAL, LDAP classes for StorageService and StorageShare (GLUE2StorageService and GLUE2StorageShare) are AUXILIARY. Any published object must have at least one STRUCTURAL class and zero or more AUXILIARY classes. To publish a StorageService, the LDAP object must have GLUE2StorageService and GLUE2Service object-classes. To publish a StorageShare, the LDAP object must have GLUE2StorageShare and GLUE2Share object-classes. In GLUE v2.0, the Share object has a required (i.e., multiplicity of '1') association with a Service. This is represented in the LDAP Schema as a required attribute in the GLUE2Share class: the GLUE2ShareServiceForeignKey attribute. The StorageShare object inherits this required association, only it is against a StorageService now. This association is represented as a required attribute in the GLUE2StorageShare class: the GLUE2StorageShareStorageServiceForeignKey attribute. Since a StorageShare object must be published as both GLUE2StorageShare and GLUE2Share object-classes, this object must publish the same association twice: once once as GLUE2ShareServiceForeignKey and again as GLUE2StorageShareStorageServiceForeignKey. The same problem exists for very many (perhaps all) ForeignKey attributes in AUXILIARY classes but is hidden since those foreign-key attributes are optional. I've talked to Laurence about this problem and our preferred solution is to delete GLUE2StorageShareStorageServiceForeignKey and have all a StorageShare publish their association with StorageService using a GLUE2ShareServiceForeignKey. I believe this approach will work for the other "inherited" foreign-key attributes. This solution has the disadvantage that the association between a StorageService cannot be restricted to a StorageService (and not, for example, to a ComputingService object). However, since LDAP doesn't support foreign- key constraints, such consistency may only be enforced by manual checking (gstat2, glue-validation suite, etc). So, I believe removing GLUE2StorageShareStorageServiceForeignKey doesn't loose us anything. Does this make sense? Are people in favour of this approach? Cheers, Paul.