Re: Change of name forms and DIT structure rules when renaming an entry

Steven,

I really appreciate your comment.

Steven Legg wrote:
>=20
> Michael Str=F6der wrote:
>> when displaying an input form for renaming an entry I'd like to let=20
>> the user search for possible new superior DNs. If applicable I'd like=20
>> to construct the search filter derived from applicable DIT structure=20
>> rules.
>> So the question is how to find the structural object classes which are=
=20
>> allowed for superior entries.
>>
>> X.501 (1993) section 12.6.5 says:
>> "Each object and alias entry is governed by a single DIT structure rul=
e."
>>
>> Currently I determine the governing structure rule by looking up the=20
>> best matching name form for 1. the structural object class and 2. the=20
>> current old RDN.
>=20
> In general, you also need the governingStructureRule of the current
> superior entry,

You mean I could derive the possible structural object class from the=20
governingStructureRule of the superior entry? Hmm, there could be more=20
possible structural object classes of superior entries.

> but it is easier to just look at the governingStructureRule
> of the entry to be moved.

That's how I currently implemented it.

> Ultimately though, the governingStructureRule
> of the entry to be moved doesn't matter.

...because the RDN could also change...

>  > Then I can derive the possible superior structure rules
>> and lookup the superior structural object classes via the accompanying=
=20
>> name forms.
>>
>> But now I wonder what to do in case the user wants to change the RDN=20
>> together with a new superior DN in one rename operation? From my=20
>> understanding changing the RDN could lead to another governing=20
>> structure rule. Is that right?
>=20
> Yes, it could. In the general case the structural object class of the
> entry being renamed/moved would permit a number of candidate name
> forms, each with its own set of mandatory and optional naming
> attributes. For each name form, the structure rules specify the
> permitted governingStructureRule values for the new superior entry of
> the entry being renamed/moved. The structuralObjectClass of the
> superior entries doesn't come into it directly, but can be determined
>  from the name form associated with the structure rule corresponding
> to each of the permitted values for the governingStructureRule of the
> new superior.

I could sort this out since I already have working code for determining=20
the current name form of an entry and for determining the=20
governingStructureRule. Not sure how to come up with a good user=20
interface for that though.

Thinking about this a little bit more I came up with another difficulty:=20
The new superior DN might reside in a part of the DIT where another=20
subschema is defined. So this is a real blocker.

> If you allow the user to select the new superior first, then that will
> constrain which name forms are available to rename the entry. If you al=
low
> the user to rename the entry first (explicitly or implicitly selecting =
one
> of the applicable name forms), then that will constrain which new super=
ior
> entries are available.

Yes. But the problem is that it might be necessary for the user to=20
change both in one rename operation. From my understanding changing the=20
name form could lead to the situation where the old superior is not=20
valid anymore.

This all gets very hairy. At the moment I can't imagine a user interface=20
which really helps the user to do the right thing without the user=20
knowing a lot about how DIT structure rules and name forms work.

I will take a simpler approach with client-side configuration. Probably=20
I will display a pre-configured select list of named LDAP URLs for=20
searching the new superior entries. This would also work with servers=20
which don't support DIT structure rules and name forms.

Ciao, Michael.