Subject: Re: SUBCLASSING, again

From: Kathleen Dally <[email-masked]>
Date: Wed, 11 Feb 2004 22:23:38 -0500

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" <[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: John Strassner <[email-masked]>
Date: Thu, 12 Feb 2004 08:58:27 -0700

How can you make an abstract subclass from something that was concrete?
Subclassing means refinement or specialization.

This defies Logic, Object-Oriented Programming, and Common Sense.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.719.785.0648
  fax:     +1.719.785.0644
email:    [email-masked]

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2004 8:04 PM
> To: Kathleen Dally
> Cc: [email-masked]
> Subject: Re: SUBCLASSING, again
> 
> 
> At 06:56 PM 2/11/2004, Kathleen Dally wrote:
> >I would have no trouble deleting the sentence from Models, section
> >2.4.3:
> >        " Auxiliary object classes cannot subclass structural object 
> >classes."
> 
> Even though the model makes no sense in face of such constructions?
> 
> >However, I do not believe that the intent to permit Auxiliary object 
> >classes to subclass Structural object classes is as clear in X.501.
> 
> Why?  Since X.501 didn't explicitly disallow this, why do
> you think it clear that the intent was to disallow this?
> 
> Kurt 
>