Re: How to check whether or not an object is a leaf?

[Mark Smith <[e-mail]>]

>From:     Hallvard B Furuseth <[e-mail]>
>  To:     [e-mail]
> 
> I have a user interface which I do not want to present search/list
> options when it displays leaf objects (specifically, some organizations
> and organizationalUnits).  Now, quipuObjects are leaves if they are
> neither quipuNonLeafObject nor externalNonLeafObject.  But how do I
> recognize a X.500(1993) leaf object?
> 
> Or, if there is currently no way, *please* let's create a convention for
> how to mark leaf objects, even if the mark is only advisory.


Recently I wrote an Internet Draft that proposed using a couple of new
object classes to solve this problem.  It turns out that there is a
proposed draft amendement to the X.500 standards that defines an
operational attribute called "hasSubordinates" that seems to solve the
problem.  At the ASID meeting during last week's IETF meeting everyone
agreed we should use the "hasSubordinates" approach, and my draft will
be ignored.  I have attached a message from Colin Robbins that he sent
in response to the announcement about my original draft.

-Mark

--- Begin Message ---

I agree with this draft that being able to distinguish between leaf
and non-leaf is required, but wonder if this is the best way of
achieving the effect.

Firstly,  the proposed draft amendment to X.500 on "Minor extensions
to support user requirements" already has a similar mechanism defined.
It defines an operational attribute:

	hasSubordinates ::= {
		WITH SYNTAX BOOLEAN
		EQUALITY MATCHING RULE  booleanMatch
		SINGLE VALUE		TRUE
		NO USER MODIFICATION	TRUE
		USAGE			directoryOperation
		ID			id-oa-hasSubordinates }

This seems to overlap totally with the objectclass definition in the
ID.   However, the non-leaf object class in the ID does add some extra
attributes to non-leafs to describe data about them.

Instead of defining two new object classes, why not use the proposed
standard mechanism (it needs no software modification, so we could
use right now).  Then define numberOfChildren and numberOfDescendants
as new operational attributes to achieve the affect required in the ID?

This approach would be more in line with the X.500(93) way of adding
operation informations (using operational attributes), than using the
X.500(88) mechanism of adding artificial objectClasses.

Colin

--- End Message ---