Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <1533509138.1124902692650.JavaMail.jira@ajax.apache.org>
Date: Wed, 24 Aug 2005 18:58:12 +0200 (CEST)
From: "Alex Karasulu (JIRA)" <directory-dev@incubator.apache.org>
To: dev@directory.apache.org
Subject: [jira] Updated: (DIREVE-52) Create Schema Checking and Presentation
 IBS
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DIREVE-52?page=all ]

Alex Karasulu updated DIREVE-52:
--------------------------------

    Fix Version: 0.9.3
      Assign To:     (was: Alex Karasulu)

> Create Schema Checking and Presentation IBS
> -------------------------------------------
>
>          Key: DIREVE-52
>          URL: http://issues.apache.org/jira/browse/DIREVE-52
>      Project: Directory Server
>         Type: Task
>   Components: interceptors
>     Reporter: Alex Karasulu
>      Fix For: 0.9.3

>
> Ok there is soooo much that can and needs to be done here.  However this IBS needs to be taken step by step.  First off the initial goal for a base line is to just check attribute value syntax compliance and entry objectClass compliance using what we currently have as the schema subsystem.
> Basically we ignore things like subschemaSubentry information which we do not yet have modeled.  We do not use the ou=system partion yet because the schema sub subsystem has not matured to that point yet.  We can use mock wrappers around the BootstrapRegistries for accessing schema inforamtion right now as if the schema subsystem is fully operational.
> However let's talk about what can and will be some day ...
> First all the goodies will be there where subschemas will be used to selectively constrain subtrees within the DIT as administrator intend with a high degree of granularity.  This all comes out of nice stuff in X.500 which is making its way back into LDAP thanks to that guy Kurt from OpenLDAP.   Anyhow we'll have all the usual schema suspects we can use like DitContentRules, NameForms et. cetera. including subtree refinements to really really control schema the way it needs to be controled.
> Now we can go further obviously and have talked about how we can do this.  First off we want administrative maintenance of schema information within the ou=system area.  Using this area we store the core schema objects and their associations in logical schema categories like the nis, java and core schemas et. cetera.  We enable the presentation and manipulation of this region by server admins.  Also we present this content in the usual manner at cn=schema for example as one fat entry with lots of attributes using the usual syntaxes for the schema types.
> An neat thing that can be done is to use a subtree specification to describe the entries to which certain types of schema checks can be applied.  This thought came to me when I realized that full blown schema checking is not always needed everywhere in the DIT.  In fact at times full blow schema checks will get in the way and slow down the server.  If we can find a way to specify controls for schema checking this would be a good place to implement them. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira