[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ListMatch Clarification
Daniel,
Daniel Henninger wrote:
> John McMeeking wrote:
As I understand it, matching applies to the entire address as a
concatinated string, excluding the $ separators, except that * --
<initial>, <any>, or <final> -- does not span lines in an attribute value.
That is, * matches a substring of a line or the entire line, but not parts
of two lines.
It is not the intention that the * separators in a Substring Assertion value
are part of the substrings that are matched, and which are required to match
entirely within a line. As Kurt points out, it isn't appropriate to think
of the *'s as wildcards either. I will try to rewrite the text about substring
matching to make this clearer in the next revision.
So if I'm understanding that correctly, one would have to do:
*Foo**NC* to match my example below? I'll get to that.
The substrings to be matched are "Foo" and "NC", so the correct assertion
is "*Foo*NC*". The position of the *'s tells us that "Foo" and "NC" are
both any substrings (as opposed to initial or final substrings).
Applying this to your later examples:
Hrm. Ok, let me see if I understand this correctly. The address query
is
matched on lines, not the string as a whole? Given address:
123 Foo Street
Raleigh, NC 12345
aka: 123 Foo Street $ Raleigh, NC 12345
Matching will be applied to the concatinated string "123 Foo Street
Raleigh, NC 12345" with a hidden separator replacing the $.
but the hidden seperator "stops dead" the *? is that correct?
No, because the * isn't part of a substring to be matched.
If I did a query of *Raleigh*, I would expect it to:
123 Foo Street no match
Raleigh, NC 12345 match
address matches
Matches:
Initial * matches "123 Foo Street", "Raleigh" matches Raleigh, final *
matches ", NC 12345"
And it only matches Raleigh because Raleigh is right at the beginning of
the line. Correct? If it were *NC*, it would -not- match?
"*NC*" would match because the any substring "NC" completely matches a string
of characters wholly contained within a line of the address (the second line).
If I did a query of *Foo*, I would expect it to:
123 Foo Street match
Raleigh, NC 12345 no match
address matches
No match:
Initial * matches either a) the entire first line or b) "123"
a) "Foo *" does not match second line
b) "Foo *" matches "Foo Street" but does not include the next line of the
address.
"*Foo*" would match because the any substring "Foo" completely matches a string
of characters wholly contained within a line of the address (the first line).
Ok, that makes sense based off my understanding from above. =)
But what if I did *Foo Street*Raleigh*, I would expect it to:
123 Foo Street no match
Raleigh, NC 12345 no match
address doesn't match
Matches:
Initial "*Foo Street" matches 1st line, 2nd "*" matches empty string,
"Raleigh*" matches 2nd line.
The address matches. The any substring "Foo Street" completely matches a
string of characters wholly contained within a line of the address (the
first line) and the any substring "Raleigh" completely matches a subsequent
string of characters wholly contained within a line of the address (the
the second line).
Personal observations:
- Since the middle * is matching an empty string, "*Foo Street Raleigh*"
should also match.
"*Foo Street Raleigh*" won't match because the any substring "Foo Street Raleigh"
does not match any string of characters which is wholly contained within any
one line of the address.
- "*Foo Street*Raleigh*" could also match addresses like:
123 Foo Street NW
Raleigh, NC 12345
Because the first line would match *Foo Street* and the second line
would match the Raleigh* portion.
It's the right answer, but the reasoning is that the any substring "Foo Street"
completely matches a string of characters wholly contained within a line of the
address (the first line) and the any substring "Raleigh" completely matches a
subsequent string of characters wholly contained within a line of the address
(the second line).
The examples have substrings matching strings of characters on separate lines
but there is nothing to stop the substrings matching disjoint strings of
characters on the same line.
Regards,
Steven
or
123 Foo Street
North Raleigh, NC 12345
And because the first line would match *Foo Street and the second line
would match *Raleigh*.
Is my interpretation any better?
Yes, that makes sense. Makes it a lot harder to parse, but hey. =)
Thanks!
Daniel
John McMeeking
owner-ietf-ldapbis@OpenLDAP.org wrote on 06/21/2004 06:55:08 AM:
I'm looking into implementing the ListMatch style matches and
submitting a
patch. I am having some trouble understanding part of the
specification.
I understand that $ is effectively a newline. The draft seems to
indicate
that you ignore $ (ie, pull it out) and escape (\). That said, the
part
I'm not clear on is the actual search string. Does the $ get handled
in
the search string as well? For example, lets say I want to find
someone
on Foo Street, in Raleigh, NC. Would I do a search along the lines
of:
postalAddress=*Foo Street $ Raleigh, NC*
or
postalAddress=*Foo Street * Raleigh, NC*
or both?
The second assertion value is the one that applies. The assertion
syntax for
caseIgnoreListSubstringsMatch is Substring Assertion, for which $ is an
ordinary character (only * and \ are special). The first assertion
value
would only match if there were an escaped $ (i.e. not a line separator)
in a line of the address (where only $ and \ are special).
The unescaped $ line separators in a Postal Address value are an
artefact
of the LDAP-specific encoding and are not matchable character data.
Hrm. Ok, let me see if I understand this correctly. The address query
is
matched on lines, not the string as a whole? Given address:
123 Foo Street
Raleigh, NC 12345
aka: 123 Foo Street $ Raleigh, NC 12345
If I did a query of *Raleigh*, I would expect it to:
123 Foo Street no match
Raleigh, NC 12345 match
address matches
If I did a query of *Foo*, I would expect it to:
123 Foo Street match
Raleigh, NC 12345 no match
address matches
But what if I did *Foo Street*Raleigh*, I would expect it to:
123 Foo Street no match
Raleigh, NC 12345 no match
address doesn't match
Is this a correct interpretation of how it should work? If you wanted to
make sure it was Foo Street in Raleigh, NC, how would you go about doing
that? (&(postalAddress=*Foo Street*)(postalAddress=*Raleigh*)) ?
Thanks!
Daniel
Also is there supposed to be a space on both sides of the $, similar
to
how $'s are used in schema, or would there be no spaces?
There is no requirement either way, and for caseIgnoreListMatch it
makes no
difference since each line of the address is matched according to
caseIgnoreMatch which ignores leading and trailing space on each line.
It makes no difference for caseIgnoreListSubstringsMatch as well
because of the interaction of stringprep and the requirement that
a substring in an assertion value for caseIgnoreListSubstringsMatch
does not match characters across multiple lines.
Regards,
Steven
Daniel
--
/\\\----------------------------------------------------------------------///\
\ \\\ Daniel Henninger http://www.vorpalcloud.org/
/// /
\_\\\ North Carolina State University - Systems Programmer
///_/
\\\ Information Technology <IT>
///
"""--------------------------------------------------------------"""