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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users