directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Adding extensions to schema element : how do we store them in the meta-schema ?
Date Mon, 18 Oct 2010 14:22:59 GMT
On Mon, Oct 18, 2010 at 3: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
>
>
I like this approach.


> which is probably better, but as we don't currently support AT's option,
> this is not possible.
>
> 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

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message