1. Each class in the specifications will have its own schema file, which is much better for development purposes.
2. One bash/python script will compile them all to create a single schema file, which is much better for production purposes.
3. I will create one ldif file per object as an example and to use them as unit tests.
4. All LDAP objects and attributes will be prefixed with the string 'Glue' to ensure some backwards compatibility and make it easier to change the current applications. This can be changed in the future.
   • Stephen Burke: I'm not sure about this. Backward-compatibility isn't relevant, and to some extent it may be better to have attributes which look different to make it clear that this is new. Also I'm concerned about your comment that it can be changed in the future, it really can't! In the past we decided not to have a prefix; I think the only possible reason to do it is if we think that someone may want to merge glue with some other schema in the same LDAP tree. I don't know if that's likely in practice. If we do have a prefix I think I'd suggest "Glue2". At any rate we should think about it and make a definite decision.
   • David Horat: No prefix seems the best solution for me if we are not going to have more things in the LDAP server.
5. I will represent the specification in the schemas as closer as possible to be much easier if changes want to be made or questions arise (as they will).
6. Thus, I will follow the exact inheritance done in the specifications. This inheritances will be done at the object level, so we don't need to provide several objectClass when we create a new object. I read somewhere that this was better because we ensure inheritance from the specifications, although it can be changed in future versions.
   • Stephen Burke: I'm not sure if this is a good idea, and again I think we need to consider the implications before we make a decision. For example it will affect the syntax needed to query for various things.
7. Since our specifications is relational and LDAP is NOT relational, I am still unsure how to implement this properly in LDAP. I am used to implement this in SQL but not in LDAP. I have read that, simply, you shouldn't try to make something relational into LDAP. So if any one have suggestions here, I will be glad to hear them.
   • Stephen Burke: The specification isn't relational, it's UML, and is in fact closer to LDAP than SQL (notably the presence of multivalued attributes). We do of course have to implement relations between objects; the way it's done at the moment with the GlueForeignKey works pretty well but we may want to consider the details, probably there are some alternatives.
   • David Horat: An entity-relationship model, which is the UML model you are using, is, indeed, relational. So all what I say applies. Multivalued attributes are just represented as another relationship and can be easily implemented in SQL as a relationship. I would love to hear all the alternatives that we have for representing relationships in LDAP as I am not used to it.
8. Very few attribute types of the specification can be mapped directly to LDAP types, so I will just follow the ones used in the last schema definitions. LDAP is just not prepared for all the types that we use in the specifications and other integrity mechanisms should be used.
   • Stephen Burke: Yes, basically just string and integer. Note that we specified that strings should be case-sensitive in glue 2 and I think we should enforce that in LDAP.
   • David Horat: And how do we ensure concrete type checks, such as URL, URI, concrete datatypes, etc.?
9. The only mandatory attribute that I will specify is the GlueEntityId (aka the 'key') and all the others will be optional as it is implemented in the last schemas. This can be changed in future versions.
   • Stephen Burke: I would prefer that mandatory attributes in the schema are mandatory in LDAP, I think it would be better to enforce it from the start. However, in this case we could change it later.
   • David Horat: Ok

Info regarding the use of LDAP as a relational database:

• LDAP is not relational
• LDAP is not a relational database
• LDAP vs RDBMS