I have added information about two proposed schema extensions:
* X-SCHEMA-NAME for all schema element descriptions which is like Netscape X-ORIGIN
* X-IS-HUMAN-READABLE for syntax descriptions
I have added information about the defaultDestinationSchema attribute and clarified the state of destinationSchema attribute wrt it.
http://cwiki.apache.org/DIRxSRVx11/schema-subsystem-redesign.html--On 11/29/06, Ersin Er <firstname.lastname@example.org > wrote:On 11/29/06, Alex Karasulu < email@example.com > wrote:
> Hi guys,
> We have the design in mind and it looks good. Now it's time to start
> the work. I cannot see the whole path to get this done but here's what
> I see into the next few weeks.
> 1a). We need to implement a meta schema to represent schema entities as
> entries in the server under ou=schema area. Emmanuel already started on
> 1b). We need parsers for interchanging LDAP description formats for
> schema entities into Schema objects. Ersin already started working on
> these parsers.
> 1a and 1b are concurrent.
> 2). Need to write the special partition for ou=schema which uses a
> subset of schema information to bootstrap itself and initialize the
> schema subsystem.
> 3). Write the schema subsystem facade and initialization code to load
> all entities into their respective registries. Also need to figure out
> how to maintain and access registries for specific SAAs. Basically we
> need a method to lookup a registry based on DN. This will find the SAA
> associated with the DN, and lookup the associated registries with that SAA.
> 4a). Start writing code to inject subschemaSubentry attributes into
> entries falling under SAAs defined by the subtree specifications of
> schema subentries.
FYI, this has already been implemented in the SubentryService (by Alex
mostly). I may add a few tests to make it sure it works correctly.
> 4b). Need to start working on virtualization code that injects schema
> description attributes into schema subentries.
> 4a and 4b are concurrent.
> 5) Rewrite schema checking code to properly apply schema information to
> changes to DIT and respond accordingly. We will use the full LDAP
> schema capabilities to contrain and manage the DIT.
> Right now this is as far as I can foresee in terms of general steps.