Note | ||
---|---|---|
| ||
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.
...
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 "DESC" SP qdstring ] ; description SP "FQCN" SP qdstring ; fully qualified class name [ SP "BYTECODE" 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 "DESC" SP qdstring ] ; description SP "FQCN" SP qdstring ; fully qualified class name [ SP "BYTECODE" SP qdstring ] ; optional base64 encoded bytecode extensions WSP RPAREN ; extensions where: [numericoid] is object identifier assigned to the syntax associated with this syntaxChecker comparator; DESC [qdstring] is a short descriptive string; FQCN [qdstring] is the fully qualified class name of the comparatorsyntaxChecker's class; BYTECODE [base64] is the base64 encoded byte code for the comparatorsyntaxChecker'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...