Adding extensions to schema element : how do we store them in the meta-schema ?

[Emmanuel Lecharny <el...@gmail.com>]

  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.

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) ?





-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Adding extensions to schema element : how do we store them in the meta-schema ?

[Alex Karasulu <ak...@apache.org>]

On Mon, Oct 18, 2010 at 3:03 PM, Emmanuel Lecharny <el...@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

Re: Adding extensions to schema element : how do we store them in the meta-schema ?

[Stefan Seelmann <se...@apache.org>]

Hi Emmanuel,

On Mon, Oct 18, 2010 at 2:03 PM, Emmanuel Lecharny <el...@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