Re: (ITS#4989) Quirk in Dynlist overlay configuration

[marg@rz.tu-clausthal.de]

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
-- 
Christian Marg                    mail: mailto:marg@rz.tu-clausthal.de
Rechenzentrum TU Clausthal        web : http://www.rz.tu-clausthal.de
D-38678 Clausthal-Zellerfeld      fon : 05323/72-2043
Germany                           ICQ : <on request>