directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] Extension attributes in metaschema
Date Sun, 17 Dec 2006 11:16:13 GMT
Alex Karasulu a écrit :

> Hi,
> I was looking at the apachemeta.schema file and saw a bunch of 
> extensions attributes almost for each entity like:
> m-extensionSyntax
> m-extensionMatchingRule
> m-extensionObjectClass
> (1) Do we need all of these or can we just use m-extensions for 
> describing all extensions?

Hmmmm. When I created those N entries, I did it because I didn't want to 
hit a wall if those extensions were to be different for each object. 
Now, I think this is overkilling. Only one m-extension should do the trick.

> (2) Secondly as I understand it extensions can have multiple values 
> but each extension has it's own key.  So this raises the question of 
> how to represent this in the DIT within a single entry.  I don't think 
> using a single attribute is a good means to represent all extensions 
> in this case. Any ideas here?

You may have N extensions each one having N values like :
x-ext1 ( 'val1' 'val2' 'val3')
x-ext2 ( 'val1' 'val2' 'val3')

obviously, there is a problem to represent that as an entry in 
metaSchema. I have currently no idea other than keeping the initial 
string into the entry... Not very good, indeed :(

> Since extensions are server specific we can create an attribute for 
> each extension we support in ADS.  To automatically recognize these 
> special attributes we can x- prefix the attribute instead of using 
> m-.  So for example we can have the attributes:
> x-binary
> If our extension does not support values we can have just the 
> attribute with an empty (null) value.  If the extension supports one 
> value we can make it single valued.  If it supports many values we can 
> then make it multivalued and have more than one value for that extension.

This is an option.

> (3) Now there is another big issue.  From my understanding extension 
> value order may be significant.  If this is then the above 
> recommendation in #2 will not work because this will not preserve order.

I haven't see anywhere in the RFC a place where it's said that order is 
important. Can you give us some pointers ?

> We first have to determine if order is preserved.  If so then we must 
> encode extension values as a list of values into custom extension 
> attributes with the x- prefix.  The question is how do we do this?

No idea atm.

> Thanks,
> Alex

View raw message