Mike Jackson wrote: > Dominic Ijichi wrote: > >> isn't structural integrity a subset or by-product of schema >> checking? as in >> isn't the correct hierarchical order of objectclass definition part >> of the >> schema just as the oid type of an attribute is? > > > You could say that anything which evaluates and constrains object > composition rules is "schema checking". What "schema checking" had > meant in practice, in the case of both OL and NDS/FDS, was something > that 1) did not include structural integrity checking, and 2) could be > disabled by the administrator. FDS still works like this. OL changed > their interface forcibly, and it had 2 results: 1) people just didn't > upgrade past 2.0.x, or 2) people couldn't figure out why their > 3rd-party apps suddently stopped working. > > It would be fine, IMO, to also add structural integrity checking to > FDS. I am not against the idea at all. What is not fine is when you > introduce a new constraint, and at the same time provide no option to > disable that new constraint. You can not force a random array of > 3rd-party LDAP enabled apps to become "structurally compliant" > overnight or even in a year or two. 1) FDS should have the option to enforce structural object classes, off by default (at least for 1 or 2 releases). 2) Most objectclasses should be AUXILIARY, not structural, unless they subclass an existing structural object class. Unfortunately, there are a lot of structural object classes out there already. > > Yes, there is a workaround for this in OL. It involves creating new > schema and doing tricks with subclasses... Certainly not something the > newbie admin would understand. > > -- > mike > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20051108/330687ec/attachment.bin
