|
From: <mi...@st...> - 2002-05-30 11:46:26
|
je...@ne... wrote: > On Mon, May 27, 2002 at 08:36:11PM +0200, Michael Str=F6der wrote: >=20 >>BTW: Just fetching objectClass definition is the easy part of the=20 >>show. We have to think about how to implement and register known=20 >>LDAP syntaxes for displaying, matching and input handling. >=20 > What do you mean by 'matching'? Matching different values in reversed > polish notation according to their syntaxes and matching rules? Is that= > not supposed to be done by the LDAP server? Yes it's done by the LDAP server when processing search and=20 compare requests. But it's also handy for having it at the=20 client-side. E.g. in recent web2ldap I'm checking for=20 characteristic attributes (attributes used for forming RDN) and=20 disallow modifying it in the normal modify input form since weird=20 things can happen on various LDAP servers. Now I can only do case-insensitive string matching which is most=20 times right. But in a completely correct implementation the=20 matching should be done according to the matching rules defined=20 for these attributes used. > And what about 'input > handling' -- client-side classchecking? Syntax checking of attribute values in user's input. > I guess I'm totally wrong, but I > have no idea how schema parsing might be usefull except displaying > available classes and attributetypes... Think of displaying attribute values in a UI. It helps if you have=20 knowledge about the syntax used: normal UTF-8 strings vs. ASCII=20 strings, E-mail addresses as mailto:-link or URLs as active links=20 or... Ciao, Michael. |