+1 from me too - sorry for getting to this late.
AFAIR, those grammars are also different because they create different
On Sun, Jun 1, 2008 at 12:11 AM, Stefan Seelmann <firstname.lastname@example.org> wrote:
> Hi all,
> I investigated a bit deeper:
> Currently we have two grammars to parse schemas in shared-ldap:
> schema.g: schema parser for schema entities; used by syntax checkers,
> the schema core and the browser in studio.
> openldap.g: parser for OpenLDAP schema files; used by the schema editor
> in studio
kind of object (to be double checked). Anyway, this is not a reason to
not merge those two grammars.
> Here are the changes I would like to do:
> Move the functionality of openldap.g to schema.g because we could reuse
> the grammar. The only difference is that an objectClass or attributeType
> in an OpenLDAP schema file is prefixed by "objectclass" or
> "attributetype", the remaining grammer is the same as in schema
> entities. That would avoid duplicate grammar code.
I would like to add some more features, like accepting a name for
> Relax the grammar of schema.g:
> - allowing tabs instead of spaces,
> - allowing more than one space
> - allowing missing spaces before or after '(' and ')'
> - allowing unordered parameters.
> - case insentivitity for keywords like attributetype, NAME, DESC, MAY,
> MUST, ...
> The aim is to be able to parse schema entities in OpenLDAP schema files,
> syntax checkers and the schema subsystem, as long as the intention is clear.
syntaxes. Nothing is less painfull than to have an OID to express that
an AttributeType is a IA5String !
>IMHO, the grammar parser should not be strict by default, but relaxed.
> Add an "isStrict" flag to schema.g which is true by default.
If you set it to strict, many users will ask 'why is my schema not
Thanks Stefan. You have my +1.
> the following additional relaxions are activated:
> - allow alphanumeric values for the numeric oid of an schema entity
> - allow quoted oids, e.g. for NAME, MUST, MAY, etc.
> - to be continued...
> The aim is to be able to parse invalid schema entities. This feature is
> needed by the LDAP browser because it should be able to work with all
> kind of directory servers, even if they have an RFC-invalid schema.
> Adding additional tests ;-)