|
Home > Archive > Apache Directory Project > October 2005 > DnParser
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Gianmaria Clerici 2005-10-19, 5:46 pm |
| NormalizationService will use org.apache.ldap.common.name.DnParser to
normalize a Name.
For instance, if my Name looks like this:
ou=Sub Production V,bsiViewName=Direct Report View
It will return this:
ou=sub production v,bsiViewName=direct report view
As you can see it will replace the 2 spaces before the V with one space.
Is this the correct behavior ?
I will need to look up an object using the normalized value (down in my
partition code), but it's a bit more challenging if the spaces have
been, partially, removed.
Thanks
| |
| Emmanuel Lecharny 2005-10-19, 5:46 pm |
| On Tue, 2005-10-18 at 15:52 -0700, Gianmaria Clerici wrote:
> NormalizationService will use org.apache.ldap.common.name.DnParser to
> normalize a Name.
>
>
>
> For instance, if my Name looks like this:
>
> ou=Sub Production V,bsiViewName=Direct Report View
>
>
>
> It will return this:
> ou=sub production v,bsiViewName=direct report view
>
>
>
> As you can see it will replace the 2 spaces before the V with one
> space.
>
>
>
> Is this the correct behavior ?
Even if stange, this is plain normal. The reason is that 'ou' (OID
2.5.4.11) inherits from attribute 'name' (OID 2.5.4.41) which syntax
is :
name ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {MAX}
EQUALITY MATCH RULE caseIgnoreMatch
SUBSTRINGS MATCHING RULE caseignoreSubstringsMatch
ID {id-at-name}
}
Its EQUALITY MATCH RULE is caseIgnore Match, and the RFC 2252 says :
8.1 :
....
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
> I will need to look up an object using the normalized value (down in
> my partition code), but it’s a bit more challenging if the spaces have
> been, partially, removed.
Yes, it's challenging ;) And it's *not* funny at all to implement
either !
-- Emmanuel
| |
| Alex Karasulu 2005-10-19, 5:46 pm |
| Emmanuel Lecharny wrote:
> On Tue, 2005-10-18 at 15:52 -0700, Gianmaria Clerici wrote:
>
>
>
> Even if stange, this is plain normal. The reason is that 'ou' (OID
> *2.5.4.11*) inherits from attribute 'name' (OID *2.5.4.41) which
> syntax is :*
>
>
> name ATTRIBUTE ::= {
>
> WITH SYNTAX DirectoryString {MAX}
> EQUALITY MATCH RULE caseIgnoreMatch
> SUBSTRINGS MATCHING RULE caseignoreSubstringsMatch
> ID {id-at-name}
>}
>
>Its EQUALITY MATCH RULE is caseIgnore Match, and the RFC 2252 says :
>
>8.1 :
>...
>When performing the caseIgnoreMatch, caseIgnoreListMatch,
> telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
> *multiple adjoining whitespace characters are treated the same as an*
>* individual space*, and leading and trailing whitespace is ignored.
>
>
That was a good description of why this is the case.
Alex
| |
| Emmanuel Lecharny 2005-10-19, 5:46 pm |
| <snip/>
> That was a good description of why this is the case.
>
> Alex
At a point, we may want to have a DnParser, and a DnNormalizer. The
DnParser will just check that the DN is correct, and the DnNormalizer
will use the Schema to transform the NameComponents.
It's not obvious that the normalization should occur during the parsing.
I don't know if just a question of separation of concern, or of
performance is improved by this three phases process (I don't think so),
but the fact is that we should go through those three phases :
1) String -> nameComponents
2) nameComponents -> normalized nameComponents
3) normalized nameComponents -> normalized String
What is the best solution?
wdyt ?
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
| |
| Ersin Er 2005-10-19, 5:46 pm |
| SSB0aGluayBpdCdzIGJldHRlciB0byByZWRlZmlu
ZSBMZGFwTmFtZSBhcyBTdW4gZGlkIGluIDUu
MCBhbmQKbm9ybWFsaXphdGlvbiBzaG91bGQgYmUg
YSBzZXBlcmF0ZSBwcm9jZXNzLiAoRW1tYW51
ZWwsIEkgZmF2b3IgbXkKcHJldmlvdXMgcHJvcG9z
YWwuKSBUaGlzIHdpbGwgYWxzbyBwcm92aWRl
IGNvbXBhdGl0aWJpbGl0eSB3aXRoIEphdmEKU0Ug
Zm9yIGZ1dHVyZSB2ZXJzaW9ucyBvZiBBcGFj
aGVEUy4KClNlZTogaHR0cDovL2phdmEuc3VuLmNv
bS9qMnNlLzEuNS4wL2RvY3MvYXBpL2phdmF4
L25hbWluZy9sZGFwL0xkYXBOYW1lLmh0bWwKCk9u
IDEwLzE5LzA1LCBFbW1hbnVlbCBMZWNoYXJu
eSA8ZWxlY2hhcm55QGFwYWNoZS5vcmc+IHdyb3Rl
Ogo+IDxzbmlwLz4KPiA+ID44LjEgOgo+ID4g
Pi4uLgo+ID4gPldoZW4gcGVyZm9ybWluZyB0aGUg
Y2FzZUlnbm9yZU1hdGNoLCBjYXNlSWdub3Jl
TGlzdE1hdGNoLAo+ID4gPiAgIHRlbGVwaG9uZU51
bWJlck1hdGNoLCBjYXNlRXhhY3RJQTVNYXRj
aCBhbmQgY2FzZUlnbm9yZUlBNU1hdGNoLAo+ID4g
PiAgICptdWx0aXBsZSBhZGpvaW5pbmcgd2hp
dGVzcGFjZSBjaGFyYWN0ZXJzIGFyZSB0cmVhdGVk
IHRoZSBzYW1lIGFzIGFuKgo+ID4gPiogICBp
bmRpdmlkdWFsIHNwYWNlKiwgYW5kIGxlYWRpbmcg
YW5kIHRyYWlsaW5nIHdoaXRlc3BhY2UgaXMg
aWdub3JlZC4KPiA+ID4KPiA+ID4KPiA+IFRoYXQg
d2FzIGEgZ29vZCBkZXNjcmlwdGlvbiBvZiB3
aHkgdGhpcyBpcyB0aGUgY2FzZS4KPiA+Cj4gPiBB
bGV4Cj4KPiBBdCBhIHBvaW50LCB3ZSBtYXkg
d2FudCB0byBoYXZlIGEgRG5QYXJzZXIsIGFuZCBh
IERuTm9ybWFsaXplci4gVGhlCj4gRG5QYXJz
ZXIgd2lsbCBqdXN0IGNoZWNrIHRoYXQgdGhlIERO
IGlzIGNvcnJlY3QsIGFuZCB0aGUgRG5Ob3Jt
YWxpemVyCj4gd2lsbCB1c2UgdGhlIFNjaGVtYSB0
byB0cmFuc2Zvcm0gdGhlIE5hbWVDb21wb25l
bnRzLgo+Cj4gSXQncyBub3Qgb2J2aW91cyB0aGF0
IHRoZSBub3JtYWxpemF0aW9uIHNob3VsZCBv
Y2N1ciBkdXJpbmcgdGhlIHBhcnNpbmcuCj4gSSBk
b24ndCBrbm93IGlmIGp1c3QgYSBxdWVzdGlv
biBvZiBzZXBhcmF0aW9uIG9mIGNvbmNlcm4sIG9y
IG9mCj4gcGVyZm9ybWFuY2UgaXMgaW1wcm92
ZWQgYnkgdGhpcyB0aHJlZSBwaGFzZXMgcHJvY2Vz
cyAoSSBkb24ndCB0aGluayBzbyksCj4gYnV0
IHRoZSBmYWN0IGlzIHRoYXQgd2Ugc2hvdWxkIGdv
IHRocm91Z2ggdGhvc2UgdGhyZWUgcGhhc2Vz
IDoKPgo+IDEpIFN0cmluZyAtPiBuYW1lQ29tcG9u
ZW50cwo+IDIpIG5hbWVDb21wb25lbnRzIC0+
IG5vcm1hbGl6ZWQgbmFtZUNvbXBvbmVudHMKPiAz
KSBub3JtYWxpemVkIG5hbWVDb21wb25lbnRz
IC0+IG5vcm1hbGl6ZWQgU3RyaW5nCj4KPiBXaGF0
IGlzIHRoZSBiZXN0IHNvbHV0aW9uPwo+Cj4g
d2R5dCA/ Cj4KPiA+Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KPiA+IFdhbmFk
b28gdm91cyBpbmZvcm1lIHF1ZSBjZXQgIGUtbWFp
bCBhIGV0ZSBjb250cm9sZSBwYXIgbCdhbnRp
LXZpcnVzIG1haWwuCj4gPiBBdWN1biB2aXJ1cyBj
b25udSBhIGNlIGpvdXIgcGFyIG5vcyBzZXJ2
aWNlcyBuJ2EgZXRlIGRldGVjdGUuCj4gPgo+ID4K
PiA+Cj4KPgo+Cj4KCgotLQpFcnNpbgo=
| |
| Alex Karasulu 2005-10-19, 5:46 pm |
| Ersin Er wrote:
>I think it's better to redefine LdapName as Sun did in 5.0 and
>normalization should be a seperate process. (Emmanuel, I favor my
>previous proposal.) This will also provide compatitibility with Java
>SE for future versions of ApacheDS.
>
>
Does your proposal differ from Emmanuel's idea of separating
normalization from parsing. Could you restate it? I might have missed
it sorry.
Also Emmanuel I guess your 3 passes to parse and normalize makes sense
for optimization. We do need to solve the DN bottleneck in the server
so I'm eager to optimize.
Cheers,
Alex
|
|
|
|
|