[
https://issues.apache.org/jira/browse/DIRSERVER-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu closed DIRSERVER-573.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.5.0
Fixed a long time ago.
> Create Schema Checking and Presentation IBS
> -------------------------------------------
>
> Key: DIRSERVER-573
> URL: https://issues.apache.org/jira/browse/DIRSERVER-573
> Project: Directory ApacheDS
> Issue Type: Task
> Components: core
> Reporter: Alex Karasulu
> Assignee: Alex Karasulu
> Fix For: 1.5.0
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
