Daniel Pluta wrote:
Please forget the additional syntaxes for now. In the meantime I've
learned that there is no possibility to support binary searching by
using an attribute of generalizedTime syntax within extensibleMatch
filters because ordering rules cannot be handled in extensibleMatching
rules because the specification does not say anything about ":<=" or
I'm afraid you're under a misapprehension. Although the string
of an extensible match contains a equals sign, it is just meaningless
fluff. The extensible match applies a matching rule, which is a boolean
predicate that may or may not represent a relational operator like "=".
So that the extensible match had the same expressive power as the other
filter items, the X.500 working group defined matching rules for each of
the syntaxes that has an obvious equality or ordering relationship
values. For each syntax with an ordering relationship they defined two
predicates; an equality or "=" matching rule (e.g., generalizedTimeMatch)
and an ordering or "<" matching rule (e.g.,
This is sufficient to construct the other relational operators through an
expression of extensible match filter items. That is,
"type=value" is (type:generalizedTimeMatch:=value)
"type<value" is (type:generalizedTimeOrdering:=value)
"type>=value" is (!(type:generalizedTimeOrdering:=value))
There is nothing magic about the choice of "=" and "<". The X.500 working
group could have chosen any other pair of the relational operators, or
than two, but this is the convention that has been followed since.
also lies the reason why I suggested that currentTimeMatch and
currentTimeOrderingMatch were sufficient. It's not wrong to define more
rules as you have done, just unconventional and excess to requirements.
So it is possible to perform binary search on a syntax using
given an ordering matching rule for that syntax, and it is meaningless
about ":<=" or ":>=" with respect to the extensible match filter item.