[Date Prev][Date Next]
Re: (ITS#4989) Quirk in Dynlist overlay configuration
Kurt Zeilenga wrote:
> On Jun 2, 2007, at 2:47 PM, email@example.com 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:
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.
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
mailexpansionURL - containing only LDAP URLS like
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
just to satisfy current(?) dynlist configuration rules? I think that
would be bad schema design: Different attributes for values meaning the
> 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
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.
Christian Marg mail: mailto:firstname.lastname@example.org
Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de
D-38678 Clausthal-Zellerfeld fon : 05323/72-2043
Germany ICQ : <on request>