[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Change of name forms and DIT structure rules when renaming an entry
Steven,
I really appreciate your comment.
Steven Legg wrote:
Michael Ströder wrote:
when displaying an input form for renaming an entry I'd like to let
the user search for possible new superior DNs. If applicable I'd like
to construct the search filter derived from applicable DIT structure
rules.
So the question is how to find the structural object classes which are
allowed for superior entries.
X.501 (1993) section 12.6.5 says:
"Each object and alias entry is governed by a single DIT structure rule."
Currently I determine the governing structure rule by looking up the
best matching name form for 1. the structural object class and 2. the
current old RDN.
In general, you also need the governingStructureRule of the current
superior entry,
You mean I could derive the possible structural object class from the
governingStructureRule of the superior entry? Hmm, there could be more
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
name forms.
But now I wonder what to do in case the user wants to change the RDN
together with a new superior DN in one rename operation? From my
understanding changing the RDN could lead to another governing
structure rule. Is that right?
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
the current name form of an entry and for determining the
governingStructureRule. Not sure how to come up with a good user
interface for that though.
Thinking about this a little bit more I came up with another difficulty:
The new superior DN might reside in a part of the DIT where another
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 allow
the user to rename the entry first (explicitly or implicitly selecting one
of the applicable name forms), then that will constrain which new superior
entries are available.
Yes. But the problem is that it might be necessary for the user to
change both in one rename operation. From my understanding changing the
name form could lead to the situation where the old superior is not
valid anymore.
This all gets very hairy. At the moment I can't imagine a user interface
which really helps the user to do the right thing without the user
knowing a lot about how DIT structure rules and name forms work.
I will take a simpler approach with client-side configuration. Probably
I will display a pre-configured select list of named LDAP URLs for
searching the new superior entries. This would also work with servers
which don't support DIT structure rules and name forms.
Ciao, Michael.