directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: Adding extensions to schema element : how do we store them in the meta-schema ?
Date Mon, 18 Oct 2010 12:32:23 GMT
Hi Emmanuel,

On Mon, Oct 18, 2010 at 2:03 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>  Hi guys,
>
> I'm a little annoyed atm trying to get the schema element extensions handled
> by the server. Let me explain what is my problem :
>
> - all the schema elements (AT, OC, MR, S, ...) can have some extensions, as
> explicited by RFC 4512.
> - a schema element may have more than one element
> - an extension has a key and at least one value (but may have many)
> - we store the schema elements as LDIF
> - we also allow the server to parse those schema elements when provided as
> specified by the RFC
> - when parsing them, the extensions are correctly stored into the
> corresponding Java instances, as manipulated by the schemaManager
>
> So the problem is how do we express those extensions in a LDIF format?
> Currently, we don't...
>
> Let me give you some example. The following OC (using the RFC syntax) is
> correctly parsed :
>
> objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top
> STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $
> description ) X-extension 'test' X-otherExtension ( 'test1' 'test2' ) )
>
> The 2 extensions are stored into  Map<String, List<String>> into the
> corresponding instance of ObjectClass.java.
>
> The corresponding LDIF file for this instance would be :
> version: 1
> version: 1
> dn: m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema
> objectclass: metaObjectClass
> objectclass: metaTop
> objectclass: top
> m-name: person
> m-oid: 2.5.6.6
> m-description: RFC2256: a person
> m-supobjectclass: top
> m-typeobjectclass: STRUCTURAL
> m-must: cn
> m-must: sn
> m-may: userPassword
> m-may: telephoneNumber
> m-may: seeAlso
> m-may: description
>
> but I have no idea on how to express the extensions...
>
> Should it be something like :
> m-extension: X-extension 'test'
> m-extension: X-otherExtension ( 'test1' 'test2' )
>
> if so, that means we will have to parse those extensions when reading them.
> Not convenient.
>
> Another proposal would be to use AT's options :
> m-extension;X-extension: test
> m-extension;X-otherExtension: test1
> m-extension;X-otherExtension: test2
>
> which is probably better, but as we don't currently support AT's option,
> this is not possible.

I'd vote for that proposal, it is a good way to persist a Map<String,
Collection<String>>.

> So, what about starting to think about how to handle AT's options right now,
> assuming it's a part of the spec, that we need it to handle languages, and
> it's also mandatory for binary attributes (certificate;bianry, for instance)
> ?

+1


A third solution would be to store each extension into its own
subordinate entry. This is a more generic approach to persist a Map,
but probably oversized for this case.

dn: m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema

dn: m-name=X-extension,m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema
objectclass: metaExtension
objectclass: metaTop
objectclass: top
m-name: X-extension
m-value: test

dn: m-name=X-otherExtension,m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema
objectclass: metaExtension
objectclass: metaTop
objectclass: top
m-name: X-otherExtension
m-value: test1
m-value: test2

OC metaExtension and AT m-value are just proposals and don't exist yet.

Kind Regards,
Stefan

Mime
View raw message