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 theschema 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
