[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ListMatch Clarification
> I think you've got it right, assuming someone else doesn't correct me.
>
> Would it help to have some examples in the ldapbis syntaxes draft
> illustrating some of these cases?
=) I always think examples are a good thing!
Daniel
>
>
> Daniel Henninger <daniel@unity.ncsu.edu> wrote on 06/21/2004 10:12:00 AM:
>
> > > 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.
> >
> > So if I'm understanding that correctly, one would have to do:
> > *Foo**NC* to match my example below? I'll get to that.
>
> That's how I understand it.
>
> >
> > > 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?
>
> I believe so. Both X.520 and ldapbis [SYNTAXES] say:
>
> ... none of the <initial>, <any>, or <final> substrings of the
> assertion value are considered to match a substring of the
> concatenated string which spans more than one of the original strings
> of the attribute value.
>
> >
> > > > 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?
>
> Correct, (postaladdress=*NC*) would not match this address.
>
> >
> > > > 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.
> >
> > 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.
> > >
> > > Personal observations:
> > > - Since the middle * is matching an empty string, "*Foo Street
> Raleigh*"
> > > should also match.
> > > - "*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.
> >
> >
> > > 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>
> > > ///
> > > >
> """--------------------------------------------------------------"""
> > >
> > >
> >
> > --
> >
> /\\\----------------------------------------------------------------------///\
>
> > \ \\\ Daniel Henninger http://www.vorpalcloud.org/
> /// /
> > \_\\\ North Carolina State University - Systems Programmer
> ///_/
> > \\\ Information Technology <IT>
> ///
> > """--------------------------------------------------------------"""
>
>
--
/\\\----------------------------------------------------------------------///\
\ \\\ Daniel Henninger http://www.vorpalcloud.org/ /// /
\_\\\ North Carolina State University - Systems Programmer ///_/
\\\ Information Technology <IT> ///
"""--------------------------------------------------------------"""