directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: Client API Schema support
Date Fri, 23 Jan 2015 20:55:19 GMT
On 01/23/2015 09:07 PM, Emmanuel L├ęcharny wrote:
> Thinking about it, as soon as the schema elements stored in the
> subschemaSubentries are supposed to be standardized by RFC 4512, there
> is no reason the existing code should not work with any server, except
> that we should remove the
> if ( isApacheDs( rootDse ) )
> check...

This is what I just wanted to write.

That should work, but in reality it doesn't because some LDAP servers
return incomplete or invalid information.

In Studio for the "LDAP Browser" we load the schema from
subschemaSubentry of the rootDSE when opening a connection (different
subschemaSubentries are not supported currently) and handle lot of
special cases:

* the "quirks" mode for the schema parsers is enabled which e.g. accepts
non-numeric OIDs and doesn't check references (SUP, SYNTAX) between
schema elements

* For missing schema elements (e.g. if the server doesn't provide any
ldapSyntaxes) we create "dummy" elements to make the schema model

This is implemented in class [1].

The aim of this implementation is to have a usable schema to assist the
user when creating and editing entries or to be able to browse the
schema via the schema browser.

For the "Schema Editor" there is a different implmentation
[2]. The aim of this implementation is to collect all error in the
schema and list them in the error view. But still we create dummy
syntaxes and matching rules if missing.

You see there are different use cases (strict validation vs. relaxed
validation + present problems vs. try of fix invalid schemas to make
them usable). I'm not sure if it is possible to refactor the code to
have a single implementation that supports all use cases.

Kind Regards,



View raw message