RE: Families of Entries

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

	Dear all, just a few comments on the family of entries issues
and compund attributes.

	The requirement is very real having collection of entries and
parent/child concepts. In addition compound attributes have wide
utility.

	some points:
	a) Building Parent/Child Definitions
	The way in which parent/child entries are built are related to
operational functionality desired from the directory service in line
with business models. Eg a person entry may have many roles, and  roles
may be supported by many people. Also people report to many managers and
managers may be a person (a leaf entry) that is responsible for many
organisations/units (as represented higher in the directory).

	In creating families of logically dispersed but related
directory entries we need to understand the distributed and operational
management and requirements behind that. As it is easy to create a
single instance of a mechanism and define it in ASN.1 and apply that in
a single server, but slightly more difficult to engineer that into
distributed environment that scales well - as well as understand the
operational resource that will be needed to run the system.

	In fact the operational resource will be the same style to
manage that of other directory relational/name based attributes such as
URLs, DNs-Role Occupant, See Also, Group of Names...., etc. So we could
just be adding a mechanism that may already be supported with normal
entry attributes.
	And all that needs to be developed is the searching and matching
rule processes around these "relational" attributes (as per the F.510
service model).

	b) Total Scope of Directory Searching and Information Management
	With Family of entries mechanisms we now have a directory model
that is distributed and related by name containment (the DIT), grouped
by schema definitions, access controls, collective attributes
(subentries), accessed through contexts (time of day, language, etc)
grouped by replication requirements, organised operationally by logical
hierachy- family definitions and from a business/user information
(value) perspective entries are related through See Also, Role
Occupants, Group of Names, Mail Lists, etc. In addition subtyping of
attributes may be used - so all in all directory searching and
information management can become complex.

	I tend to think that X.500 object - hierarchy approach has a
great deal to offer at the all levels of the tree. But at the lower
levels, a relational model approach may required. Both in terms of
information definition and directory engineering. So comments are
invited here.
	Note the issues re Multiple Service Providers and split entries
and how relational search processes can solve that.


	c) Multiplexed Family Relationships
	The mechanism currently defined seems to be a single value
operational attribute for each entry for the Hierarchy Info. This in the
ideal world, should be multi-valued as a child entry may have many
parents and parents may want logical groups of children.


	d) Cross-Subordinate DSA management.
	The way in which cross DSA boundaries are managed in terms of
subentries (collective attributes, schema, service/search definitions,
etc) adding entries, etc in a set of distributed-subordinate DSAs is via
DOP. It follows that in theory that if a DSA sibling is added as another
DSA. Then the parent and sibling entries in other DSAs will require
updating. How this is done is a distribution - management issue that
needs to be looked at.

	In closing, the requirement for family entries and compound
attributes is real.
	However, the mechanisms proposed are logical but should we
debate the compound attribute area and relational /matching rule areas
to see if these requirements can be met in a different way.


	regards alan

>