regexMatch examples

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Example A

User wants to return all entries which contain
uid values shorter than 5 characters.

  (uid:regexMatch:=^.{,5}$)

Example B

User wants to find all entries which contain name
attributes with start or end with trailing white
space or contain duplicate spaces.
  (name:regexMatch:=\28^[:space:]|[:space:]{2,}|[:space:]$\29)

Note required escaping.

Example C

User wants to match all names which contain
a common immediately after the first word (such as
"Smith, John" but not "John Smith, Jr.".   That is,
match the the regex "^ *[^ ]*," or the filter:
is (name:regexMatch:=^ \2a[^ ]\2a,).

Example D

User wants to match all values which start with A or B
and end with C or D.  That is: should match the regex
	^(A|B).*(C|D)$

This should match as follows:
	#	value		match
	1	A X		false
	2	A X C		true
	3	A X D		true
	4	B X		false
	5	B X C		true
	6	B X D		true
	7	X C		false
	8	X D		false

Now, lets say in within scope entries with attribute 'attr'
each of which contains a subset of the following values
and we want to return just those which contain a matching
value, that is: (attr:regexMatch:=^\28A|B\29.\2a\28C|D\29$).

This rather simple regex cannot be decomposed into a single
substrings assertion, but could be decomposed into a complex
filter:
	(|(attr=A*C)(attr=A*D)(attr=B*C)(attr=B*D))


Remarks:

I do believe that most assertions made by Joe User can be
(and should be) expressed without the need for extensible
matching and, in particular, regexMatch.  However, regular
expressions offer immense amount of power which can be applied
to any string value and, as demonstrated above, can be used
to make assertions which are not supported by existing
rules.  Of course, as Mark pointed out, such power comes at
a price.