Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0
Note
titleWork in progress

This site is in the process of being reviewed and updated.

ApacheDS includes 3 new schema descriptions as held within schemaSubentries.
These new descriptions govern how syntax checking is performed and how
searches are conducted by defining the atomic elements composing matchingRules.

Comparator Description Syntax

Comparators determine ordering and hence govern matchingRules used for ordering
with greater than or equal to and less than or equal to filter assertions. The
description for these entities either reference an existing comparator or contain
bytecode for loading and creating a new comparator for use with matchingRules.

Comparators do not have an OID specific to them. Instead they reference the OID
(numeric identifier) of the matchingRule they will be used in conjunction with. So
before a novel matchingRule can be added to the system, a comparator and a normalizer
for that comparator must be added with it's OID.

Here's the description syntax of a comparator according to the ABNF:

No Format
    ComparatorDescription = LPAREN WSP
          numericoid                           ; object identifier
          [ SP "DESC" SP qdstring ]            ; description
          SP "FQCN" SP fqcn                    ; fully qualified class name
          [ SP "BYTECODE" SP base64 ]          ; optional base64 encoded bytecode
          extensions WSP RPAREN                ; extensions
    
    base64          = *(4base64-char)
    base64-char     = ALPHA / DIGIT / "+" / "/" / "="
    fqcn = fqcnComponent 1*( DOT fqcnComponent )
    fqcnComponent = ???
    where:
        <numericoid> is object identifier assigned to the matchingRule 
            associated with this comparator;
        DESC <qdstring> is a short descriptive string;
        FQCN <fqcn> is the fully qualified class name of the comparator's class;
        BYTECODE <base64> is the base64 encoded byte code for the comparator's class;
        <extensions> describe extensions.

Normalizer Description Syntax

Normalizers determine how to reduce values down to a canonical representation
which can then be used to compare them. Matching within the directory server
is driving through the combined operation of normalizers and comparators.
MatchingRules use these atomic components to control matching for filter
evalutation.

Like Comparators, Normalizers do not have their own assigned object identifiers (OIDs). Instead their descriptions use the OID of the matchingRule
they are defined for. When adding a matchingRule to the system both a
normalizer and a comparator with it's object identifier must be registered with
the directory server.

Here's the description syntax of a normalizer according to the ABNF:

No Format
    NormalizerDescription = LPAREN WSP
          numericId                           ; object identifier
          [ SP &quot;DESC&quot; SP qdstring ] ; description
          SP &quot;FQCN&quot; SP qdstring     ; fully qualified class name
          [ SP &quot;BYTECODE&quot; SP qdstring ] ; optional base64 encoded bytecode
          extensions WSP RPAREN               ; extensions
    where:
        [numericoid] is object identifier assigned to the matchingRule 
            associated with this normalizer;
        DESC [qdstring] is a short descriptive string;
        FQCN [qdstring] is the fully qualified class name of the normalizer's class;
        BYTECODE [base64] is the base64 encoded byte code for the normalizer's class;
        [extensions] describe extensions.

SyntaxChecker Description Syntax

The directory server must enforce the syntax of attribute values according to
the syntax associated with the attribute. This is done by associating a
syntaxChecker with the ldapSyntaxes defined within the system. One can view
the syntaxChecker as the functional description of a syntax.

In this respect a syntaxChecker does not have it's own object identifier but
rather uses the object identifier of the syntax it is associated with. The
directory server uses this syntaxChecker to validate values of attributes on
add, modify and modifyDn operations.

Here's the description syntax of a syntaxChecker according to the ABNF:

No Format
    SyntaxCheckerDescription = LPAREN WSP
          numericId                           ; object identifier
          [ SP &quot;DESC&quot; SP qdstring ] ; description
          SP &quot;FQCN&quot; SP qdstring     ; fully qualified class name
          [ SP &quot;BYTECODE&quot; SP qdstring ] ; optional base64 encoded bytecode
          extensions WSP RPAREN               ; extensions
    where:
        [numericoid] is object identifier assigned to the syntax 
            associated with this syntaxChecker;
        DESC [qdstring] is a short descriptive string;
        FQCN [qdstring] is the fully qualified class name of the syntaxChecker's class;
        BYTECODE [base64] is the base64 encoded byte code for the syntaxChecker's class;
        [extensions] describe extensions.

FQCN Grammar

Here http://www.antlr.org/grammar/1152141644268/java.g I found the Antlr grammar for FQCN:

No Format
packageOrTypeName
	:	Identifier ('.' Identifier)*
	;

Identifier 
    :   Letter (Letter|JavaIDDigit)*
    ;

/**I found this char range in JavaCC's grammar, but Letter and Digit overlap.
   Still works, but...
 */
fragment
Letter
    :  '\u0024' |
       '\u0041'..'\u005a' |
       '\u005f' |
       '\u0061'..'\u007a' |
       '\u00c0'..'\u00d6' |
       '\u00d8'..'\u00f6' |
       '\u00f8'..'\u00ff' |
       '\u0100'..'\u1fff' |
       '\u3040'..'\u318f' |
       '\u3300'..'\u337f' |
       '\u3400'..'\u3d2d' |
       '\u4e00'..'\u9fff' |
       '\uf900'..'\ufaff'
    ;

fragment
JavaIDDigit
    :  '\u0030'..'\u0039' |
       '\u0660'..'\u0669' |
       '\u06f0'..'\u06f9' |
       '\u0966'..'\u096f' |
       '\u09e6'..'\u09ef' |
       '\u0a66'..'\u0a6f' |
       '\u0ae6'..'\u0aef' |
       '\u0b66'..'\u0b6f' |
       '\u0be7'..'\u0bef' |
       '\u0c66'..'\u0c6f' |
       '\u0ce6'..'\u0cef' |
       '\u0d66'..'\u0d6f' |
       '\u0e50'..'\u0e59' |
       '\u0ed0'..'\u0ed9' |
       '\u1040'..'\u1049'
   ;

I modified the char range and removed the overlap in the parser implamentation. Should be checked again...