[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SUBCLASSING, again



I note that this topic was discussed early last year in this
thread:
  http://www.openldap.org/lists/ietf-ldapbis/200301/msg00057.html

which was summarized (post WG Last Call) in item 5 of this post:
  http://www.openldap.org/lists/ietf-ldapbis/200302/msg00017.html

as follows:
  It was noted that Section 2.4.2 and 2.4.3 includes restrictions
  up subclassing not explicitly stated in X.501.  The author
  considers the lack of such statements in X.501 as a technical
  omission as such subclassing makes little sense.  No action.

It's my opinion (as Editor, not chair) that, in absence of a new
significant issue, we should consider this item closed.

However, to try to answer your "What am I missing?" question,
here is a little more detail.

While X.501 did not explicitly stated these restrictions, it
did imply them.  For instance, by the text:
  An object class (a subclass) may be derived from an object
  class (its direct superclass) which is itself derived from
  an even more generic object class.

(consider what "more generic" implies here).  However,
more directly implied because, without them, the specification
object class model and DIT content rules would make little sense.

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.

Kurt