Re: SUBCLASSING, again

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

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