On May 15, 2007, at 4:40 PM, ando@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
Modified Files: aci.c 1.19 -> 1.20 at.c 1.96 -> 1.97 schema_init.c 1.397 -> 1.398 schemaparse.c 1.83 -> 1.84 slap.h 1.815 -> 1.816 syntax.c 1.45 -> 1.46
Log Message: allow attribute inheritance with syntax restriction (please review)
CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/aci.c http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/at.c http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ schema_init.c http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ schemaparse.c http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/slap.h http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/syntax.c
Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
Kind of in right vein, but a bit off.
An attribute of syntax X can only be a subtype of an attribute of syntax Y if Y is a more generic syntax. In particular, all abstract values representable in X must be representable in Y.
While both printable string and directory string syntaxes are more generic than country string, directory string is not more generic than printable string. This is because printable string can represent zero length character strings and directory string cannot.
So, what needed, for each syntax, is a list of more generic syntaxes.
-- Kurt
Kurt Zeilenga wrote:
Kind of in right vein, but a bit off.
An attribute of syntax X can only be a subtype of an attribute of syntax Y if Y is a more generic syntax. In particular, all abstract values representable in X must be representable in Y.
While both printable string and directory string syntaxes are more generic than country string, directory string is not more generic than printable string. This is because printable string can represent zero length character strings and directory string cannot.
So, what needed, for each syntax, is a list of more generic syntaxes.
Sure. I'm a bit rusty with details of syntaxes, and I got misled by some "printable" 'round which probably referred to "generically being printable" rather than "based on Printable Syntax". I'll rework that.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Kurt Zeilenga wrote:
Kind of in right vein, but a bit off.
An attribute of syntax X can only be a subtype of an attribute of syntax Y if Y is a more generic syntax. In particular, all abstract values representable in X must be representable in Y.
While both printable string and directory string syntaxes are more generic than country string, directory string is not more generic than printable string. This is because printable string can represent zero length character strings and directory string cannot.
So, what needed, for each syntax, is a list of more generic syntaxes.
BWT, syntax affinity should be somehow related to compatible syntaxes in matchingRules. In that case, things are sort of reversed:
a matchingRule defined for a syntax X can apply to a value of syntax Y only if syntax Y is a more specific syntax. So, for example, caseExactMatch should apply to Country.
This is no longer true after the recent change to support the Country syntax: a filter like
(c:caseExactMatch:=IT)
appears as undefined since Country does not result in the syntaxes compatible with caseExactMatch.
Besides explicitly setting compatible syntaxes like it occurs now in schema_init.c, further compatibility rules should be automatically generated by checking what syntaxes are derived by the matchingRule's syntax (and, possibly, by its compatible syntaxes).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------