[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Abstract object class
Paul,
At 10:52 98/11/05 -0800, Paul Leach wrote:
>I agree with the problem statement. I don't agree with the proposed
>solution.
>
>There is something fundamentally conceptually wrong with the picture that
>two objects with objClass=foo have different schema. What is the objClass
I think what we are talking about here is the same Structural Object Class,
but the required attributes may change between, say entries for employees,
customers, partners and consultants/contractors. The proper way to
implement this would be to define the appropriate Axiliary Object Classes
and by using Content Rules configure the appropriate combination of Object
Classes.
I think what Ed was pointing out (if I understood him corectly), is that
there is no formal way to publish Content Rules.
>good for if it doesn't identify the schema?
It does, but since you are likely to need a private schema for an
organization in addition to the standard schema, the current way to do this
is to define several Object Classes.
>
>There are a couple of ways to approach the problem that I think are better
>than having (potentially) different schema at each NC for the same class.
>
>1. Make the class be a DN. Then the engineering department and the sales
>department can create enmtries with
>objClass="CN=foo,OU=Eng,DC=SomeCorp,DC=com" and
>objClass="CN=foo,OU=Sales,DC=SomeCorp,DC=com" and they won't conflict.
I am not sure I see why the current OID scheme is any worse than what you
are proposing. In the Directory, we tend to have entries for "real"
objects and they have a directory name. Object Class definitions have OIDs
and they are also understood by the existing X.500 implementations.
I also do not like the name forms you are proposing. Tying DNs to DNS
names imposes some rather severe restrictions on the directory names. For
one, I do not necessarily want people to know which server I use, and my
mother does not use a server at all, but I would like to be able to find
her phone number in the Directory (since my memory has been known to be
tattered).
>
>2. Make schema immutable, but subclassing and auxiliary classing more
>flexible. Then the sales and engineering departments can have their own
>classes, while the fact that there is a class in common won't get lost.
I think that is the intent. Being able to understand a subset of the
information (as a client) even though the complete schema is not known is
certainly desirable to me. Using Inheritance and Auxiliary Object Classes
together with a prudent selection of standard Structural Object Classes
will ensure that.
Cheers, ....Erik.
-------------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP/X.500 Consulting and Training
http://www.geotrain.com
+1 604 244-9131
>
>Paul
>
>
>