dit content rules (Was: SUBCLASSING, again)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:11 PM 2/11/2004, Jim Sermersheim wrote:
>Well, as long as we're on the topic...
> 
>Models doesn't give state whether a DIT content rule applies only to the structural object class it names, or if it is inherited to subclasses of that object class (there may be some inferences, but nothing obvious).

My working copy includes a clarification for this:
  An entry is governed by (if present and active in the subschema)
  the DIT content rule which applies to the structural object class
  of the entry (see Section 2.4.2).  If no active rule is present for
  the entry's structural object class, the entry's content is governed
  by the structural object class (and possibly other aspects of user
  and system schema).  DIT content rules for superclasses of the
  structural object class of an entry are not applicable to that
  entry.

>>From memory, I think X.500 says DIT content rules only apply to the structural object class named in the DIT content rule (no inheritance). Whatever the case may be, It should probably be called out in Models to avoid confusion.
> 
>Jim
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 2/11/04 5:37:19 PM >>>
>At 01:54 PM 2/11/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>> For instance, it is quite clear in X.501 that which auxiliary
>>> classes an entry can belongs to is controlled solely by the
>>> DIT Content Rule. However, the entry's structural object
>>> class has a auxiliary super class, then the entry belong to
>>> that auxiliary class even when the DIT content rule disallows
>>> it from belong to that auxiliary class.
>>
>>I guess that would mean that an entry of that structural object class
>>cannot be created unless a DIT content rule allows the auxiliary class.
>
>Or one could argue that's not necessary because its controlled
>through the structural object class of the entry. That is,
>it can be argued that a DIT content rules only controls the
>optional set of auxiliary classes an entry may belong to.
>As any entry of this structural class must belong to this
>auxiliary class, it not subject to the DIT content rule.
>
>My point here is that someone would need to engineer how such
>subclassing should work. That's a tall order when you
>consider that not only did X.501 not explicitly disallow
>Structurals from subclassing Auxiliaries, it did not
>explicitly disallow Auxiliaries from subclassing Structurals.
>Even if we were to only allow the former category, sections
>8, 12, and 14 of X.501 would need to be significantly revised.
>
>That is, the alternative to stating these restrictions is
>not simple removal of the restrictions. The alternative
>is to revise the technical specification such that the model
>make sense in the face of such subclassing and that it is
>clear how implementations are to behave.
>
>The WG considered this alternative during the WG Last Call
>and rejected it.
>
>Hence, at this point, if there are those who believe strongly
>that this alternative should have been taken, that they
>(on an individual basis) write an I-D making sense of such
>subclassing. That is, I don't think the WG should revisit
>this issue in absence of a specific alternative text. That
>text should attempt to address the underlying problems with
>X.501 which caused the restrictions to be added in the first
>place.
>
>Kurt