[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Abstract object class
Paul,
See below.
At 10:01 98/11/06 -0800, Paul Leach wrote:
>
>
>> -----Original Message-----
>> From: Erik Skovgaard [mailto:eskovgaard@geotrain.com]
>> Sent: Thursday, November 05, 1998 2:54 PM
>> To: Paul Leach; 'Ed Reed'; senthil_k1@catsglobal.com;
>> ietf-ldapext@netscape.com
>> Cc: osidirectory@az05.bull.com
>> Subject: 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.
>
>That isn't what I understood Ed to be saying. If I understood Him, he was
>proposing that the same Object Class with the same OID refer to different
>schema in different NCs.
I guess we are trying to speak for Ed here :-) It *is* possible to do
that. The Object Class remains the same (which is key), but it can be
combined with different Axiliary classes to form the valid schema in
different Naming Contexts.
>
>> >
>> >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.
>
>How would I have the same OID refer to different schema? If an OID only
>refers
>
The OID in discussion refers to an Object Class definition. Now, if we
identified Content Rules with an OID, we could define a completely
different schema in different administrative areas of the Directory by
simply combining different Object Classes.
>>
>> 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.
>
>Any DN would work; I just used the DC= forms as an example. Both forms are
>legal. You may have objections to the DC= form, but it's orthogonal to this
>issue. Let's not muddy the waters.
True. I just jump on poor practices when I see them. It's my job :-)
>> >
>> >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.
>
>That's not what I understood Ed to be proposing. If it was, then there's no
>problem. I agree with your summary. And I prefer solution #2 to #1 anyway.
We may even converge here.
Cheers, ....Erik.
--------------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP & X.500 Training and Consulting
http://www.geotrain.com
>
>Paul
>
>