Re: SUBCLASSING, again

[Kathleen Dally <kdally@mitre.org>]

Hi Kurt!

Responses in-line.

Regards,
Kathy


"Kurt D. Zeilenga" wrote:

> At 07:30 PM 2/11/2004, Kathleen Dally wrote:
> >"Kurt D. Zeilenga" wrote:
> >
> >> 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?
> >
> >kd:  I agree that this seems nonsensical.  I haven't seen any use made of
> >such a subclassing.
>
> So, it's okay to disallow this, even though X.501 didn't
> explicitly do so, because they are nonsensical.
>
> One can, and the WG did, apply the same argument to Structural
> Classes which subclass Auxiliaries.  That is, that this is
> nonsensical and hence should be disallowed, as implied by the
> "more generic" statement as well as other aspects of the
> specification.
>

> kd:  By definition of multiple inheritance, a (new) object class can have
> more than one direct superclass.  Nothing is said in the multiple
> inheritance definition about the type of  the superclasses.  In the
> definition of structural, it indicates that only one of the superclasses is
> a structural object class.  Therefore, the other direct superclasses must be
> auxiliary or abstract.  An ENTRY has exactly one structural object class,
> which is in the case of the new object class derived from one structural
> object class and, possibly, auxiliary object classes.

>
> As I noted then (and recently), the alternative is to try to
> make sense of it.  However, that's a tall order (see below).
>
> >> >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?
> >
> >kd:  The intent that I am speaking about is the nature of Auxiliary
> >Object Classes being a means of augmenting other classes and entries with
> >groups of attributes.
>
> Where in X.501 does it describe Auxiliary object classes as a
> mechanism for extending other classes, in particular, any
> structural class?  In reading 8.3.3, it seems clear the nature
> of Auxiliary object classes is to allow optional augmentation
> of entries.

> Do you see any language anywhere which specifically mentions
> that those constructs are allowed, and, more importantly, any
> text which addresses the special cases which would naturally
> arise from allowance of such constructs?
>

kd:  Could you please give an example of one of the special cases?

> My concern is that there are many statements which, when taken
> together, make little sense if structural classes are allowed
> to subclass auxiliary classes.  Below I elaborate on a few
> instances.
>
> 8.3.3 says:
>   Therefore, besides being a member of the structural object class,
>   an entry may be optionally a member of one or more auxiliary object
>   classes.
> This would have to reworded:
>   Therefore, besides being a member of the structural object class
>   and any auxiliary classes which are superclasses of this
>   structural object class, an entry may be optionally a member of
>   one or more auxiliary object classes.
> to clarify that membership in structural class's superclass
> auxiliary class is not always optional as implied by current text.

kd:  No, the rewording would have to be:
        "Therefore, besides being a member of the structural object class and
any structural, auxiliary, and abstract
         classes which are superclasses of this structural object class, and
entry maybe optional a member of one or
         more auxiliary object classes."
I don't think we need to elaborate the definition of subclassing here.

>
> 8.3.3 continues:
>   An entry?s auxiliary object classes may change over time.
> This would have to reworded:
>   An entry's auxiliary object classes, except those which are
>   superclasses of the entry's structural object class, may
>   change over time.
> as not all the entry's object classes may change over time as
> implied by the current text.

kd:  No, because the statement is about the nature of ENTRIES, not OBJECT
CLASSES.

>
> Before I go on, I note that it's starting to sounding like an
> auxiliary class which is a superclass of the structural object
> class of an entry is to be treated as if it were structural
> in this situation.  But, I note that is counter to 8.3:
>   Each object class is of precisely one of these kinds,
>   and remains of this kind in whatever situation it is
>   encountered within the Directory.
> This section, I think, was intended that special cases were
> not intended.  But we'd have to treat auxiliary classes in this
> situation quite differently from those not in this situation.
>

kd:  No, the nature of the auxiliary class is not changed by being a
superclass.  However, the attributes included in the auxiliary class are
inherited in the new class in the same way as those from any other
superclasses.  (For example, top does not become structural.)

>
> 12.3 says,
>    There shall be one value of the objectClass attribute for
>    the entry?s structural object class and a value for each
>    of its superclasses.
> So, in this situation, the auxiliary superclasses of the
> structural class of the entry are required to be listed as
> objectClass values.

kd:  Yes.

> 12.3 then says:
>       Where auxiliary object classes are used, an entry may
>    contain values of the objectClass attribute for the
>    auxiliary object classes and their superclasses allowed
>    by a DIT content rule.
> which means that in this situation, these auxiliary
> superclasses of the structural class of the entry must in
> listed in the controlling DIT content rule.  And, unsaid,
> this requires there to be a controlling DIT content rule
> in this situation.

kd:  No.  The statement is about ENTRY.  Any auxiliary superclasses of the
structural object classes are not required to be cited in a Content Rule,
because they are already part of the entry under the definition of the
structural object class.

>
>
> 12.7 says:
>   A DIT content rule specifies the permissible content of
>   entries of a particular structural object class via the
>   identification of an optional set of auxiliary object
>   classes, mandatory, optional and precluded attributes.
> That is, only those auxiliary classes in this optional set are
> permissible.

kd:  No.  This statement is discussing the significance of the Content Rule,
which controls auxiliary object classes and attributes beyond the
specification of the structural object class.

>

> 12.7 continues:
>   A DIT content rule definition includes:
>       optionally, an indication of the auxiliary object
>       classes allowed for entries governed by the rule
> That is, if they are listed, the class is "allowed", not
> "required". But from 12.3 we get that auxiliary superclasses
> of the structural class of the entry are actually required
> to be listed and this set is not optional in this situation.
>

kd:  This is a discussion of the Content Rule, not the requirements on the
entry specified by the structural object class.

>
> 12.7 says:
>   An entry governed by a DIT content rule may, in addition
>   to the structural object class of the DIT structure rule,
>   be associated with a subset of the auxiliary object
>   classes identified by the DIT content rule. This
>   association is reflected in the entry?s objectClass
>   attribute.
> If we consider a DIT content rule which lists as allowed
> only the auxiliary superclasses of the structural class of
> the entry, then the only subset which an entry can be
> associated with is the complete set, not any subset.
>

kd:  Same as above.

>
> There are likely other areas where that would need to
> be revised if such constructs were to be allowed.
>
> In response to your comment:
>
> >For many years, I have been told by implementors that
> >the products do not support Content Rules!
>
> Some do, some don't.  In LDAP, it's viewed as optional.
>
> >Given this fact, if Auxiliary Object Classes could not be
> >superclasses, no Auxiliary Object Classes could never
> >be used.
> kd:  But, the use of auxiliary object classes as superclasses is not
> precluded in X.500.  LDAP is being overly restrictive.

>
> In absence of some extension, as previously discussed
> during WG Last Call, yes.
>
> Many LDAP implementations have extensions in this area.
> However, I'm now aware of any formal specification which
> details how the set of permissible auxiliary classes is
> controlled in absence of DIT content rules.  However, I
> am aware of implementations which, while supporting
> such extensions, do not allow such subclassing constructs.
> This because the constructs are nonsensical even when
> one uses other mechanisms to control which auxiliaries
> may be present (for instance, section 8 concerns above).
>

kd:  I disagree that structural object classes derived from another structural
class and one or more auxiliary or abstract classes is nonsense.  A perfectly
good, useful, structural object class is one, such as, "namedPerson" which
would be defined as:

( x.x.x.x NAME 'namedPerson'
   SUP person, individualName)

( x.x.x.x NAME 'individualName'
   SUP top
   AUXILIARY
   MUST ( givenName $ initials $ generationQualifier ) )

The advantage of using the auxiliary object class in namedPerson (instead of a
MUST list of attributes), is that the individualName object class can be
searched for in the objectClass attribute.

> The question for us is whether implementations which
> claim to support DIT content rules in a manner consistent
> with the existing specification and, if so, how to address
> interoperability and other known technical issues.  It is
> clear that that there are multiple independently developed
> implementations of DIT content rules as described in this
> X.500 and that the clarifications in [Models] go a long way
> towards addressing the known technical issues.
>

kd:  I am NOT disagreeing with the definition of CONTENT RULES or ENTRIES,
only the Models restriction on OBJECT CLASSES.



>
> Kurt