Re: SUBCLASSING, again

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

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.

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?

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.

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.

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.

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

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

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.

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.

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

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.

Kurt