Subject: Re: SUBCLASSING, again

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 11 Feb 2004 19:11:35 -0700

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" <[email-masked]> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Feb 2004 18:50:17 -0800

At 06:11 PM 2/11/2004, Jim Sermersheim wrote:
>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
>
>>cannot be created unless a DIT content rule allows the auxiliary class.
>