[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ListMatch Clarification

> 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.

> 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?

> > 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?

> > 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>                  ///
     """--------------------------------------------------------------"""