Re: SUBCLASSING, again

[Kathleen Dally <kdally@mitre.org>]

Hi Jim!

The statement in X.501, which you are looking for, is in clause 12.7.1:
        "The DIT content rules of superclasses of the structural object
class for an entry do not apply to that entry."

Regards,
Kathy


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). 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
>