[Date Prev][Date Next]
Re: JDNI allows non-schema changes (ITS#2151)
At 11:02 AM 2002-10-25, firstname.lastname@example.org wrote:
>--On Friday, October 25, 2002 10:51 AM -0700 "Kurt D. Zeilenga"
>> At 10:29 AM 2002-10-25, email@example.com wrote:
>>> Ah, hm, I think I see what you are saying. Currently, suPerson does
>>> not have the following objectclasses as MUSTS (although they really are
>>> required for it to be a valid suPerson entry):
>> The language you use above I find a bit confusing. An objectClass
>> cannot MUST another objectClass, it can only inherit properties
>> of another objectClass (or "subclass") using the SUP (superior)
>> I assume you mean that suPerson subclasses directly or indirectly
>> from the following classes.
>>> So, we should have those as MUSTS in the suPerson entry for the add I
>>> showed you to fail, correct?
>> Rewording this "So, we should list SUPeriors of suPerson
>> as values of the entry's objectClass attribute, correct?"
>> No, it is not necessary to list SUPeriors of objectClass
>> values as any unlisted SUPerior of suPerson is implicit.
>> That is, listing only 'suPerson' as a value of objectClass
>> is semantically equivalent to listing 'suPerson' and its
>> SUPeriors as values of objectClass.
>Hm, okie. So, then from what you are saying, if I have this right:
>We want suRegid to have to contain these 3 objectclasses:
>(cutting out the ones prior to suPerson based on what you note above about
>Since the add we are doing is only putting in entries from the suPerson
>object class, suPerson is the only one being put in place when we do the
>add. What we want, is when an suRegID is created by our person creation
>object, is that all those above objectclasses MUST be a part of the suRegID
>entry, or it will fail. And I see your point about the MUST on suPerson
>being incorrect. Is there anyway to enforce that an add must include those
>3 objectclasses for the suRegID?
I don't believe there is any mechanism to require explicit listing
of objectClass values which are implicitly present.