Hello Kurt,
Kurt Zeilenga wrote:
On Jun 2, 2007, at 2:47 PM, marg@rz.tu-clausthal.de wrote:
[...]
posixGroup and groupOfURLs are both "structural" objectclasses so an entry is either a "groupofURL" or a "posixGroup", never both.
Yes, but an entry can belong to both. That is, an entry's structural class could inherit from both of these classes.
I didn't know that multiple inheritance existed in an LDAP schema. Or did you mean that there is an inheritance chain like: "top - person - organisationalPerson - inetOrgPerson"?
In the latter case - if dynlist honored inheritance - the rules should be made clear:
1st example: dynlist-attrset person personURL dynlist-attrset inetOrgPerson inetOrgPersonURL
No problem: An inetOrgPerson-Object is encountered and if both *URL-Attributes were defined, both would be expanded.
2nd example: dynlist-attrset person someURL dynlist-attrset inetOrgPerson someURL
In this case there would have to be rule for matching: Either first-match or most exact match.
And in this case the memberURL can have different meanings according to the Objectclass it is used in.
That's called bad schema design. If an attribute has is specified to have different meaning when used with X then when used with Y, it's not only unclear what meaning the attribute as when used with both X and Y, but also used without either X or Y.
Ok, I was beeing unclear: memberURL of course has no different meaning in two different group type OCs - it is the URL that lists the members of that group.
Only difference is that OC 'A' might not allow attribute 'S' returned by the LDAP URL used for expansion in OC 'B', while OC 'B' might not allow attribute 'T' returned by the LDAP URL used for expansion in OC 'A'. Still both LDAP URLs are values of the Attribute "memberURL". And no schema constraint I know of can control what an LDAP URL specifies.
I could add multiple Attribute-Descriptions (SUP labeledURI) like: uidexpansionURL - containing only LDAP URLS like ldap:///<base>?uid?<scope>?<filter> mailexpansionURL - containing only LDAP URLS like ldap:///<base>?mail?<scope>?<filter>
but now I've got two different objectclasses that should list a set of mail adresses - what should I do?
Should I really define two attributes
OCAmailexpansionURL
and
OCBmailexpansionURL
just to satisfy current(?) dynlist configuration rules? I think that would be bad schema design: Different attributes for values meaning the same.
Note that attributes may be added to an entry which are not allowed by any of the classes the entry belongs to... (see DIT content rules).
The addition of the "extensibleObject" OC is the closest thing I've seen to what I understand from that sentence. I just don't understand what this has to do with Pierangelo believing that expansion of the same URL attribute in different object classes should be forbidden.
bye Christian