[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: A tricky matched values problem
I don't much care for the matched values control, but I'd prefer a third
(looser) interpretation.
3) If the attribute is mentioned in the filter then return it. If the
client weren't interested in the attribute-value, then it wouldn't have
included it in the filter. I think that this interpretation will be
substantially simpler to implement, especially given the fact the complex
filter evaluation can normally be short circuited in certain scenarios.
Either of the two interpretations below may have a substantial performance
impact...
Bruce
At 03:22 PM 9/29/99 +0200, Erik Andersen wrote:
>A tricky question. I believe the problem comes from the ambiguity of the
word "contribute".
>
>We can either understand "contribute" to mean
>
>1) that a non-negated filter item matches a value of the attribute and
therefore only the matched value should be returned.
>
>2) that for an attribute value to contribute, it is not only required that
a non-negated filter item matches the value, but this filter item shall
also be a part of a subfilter that evaluates to TRUE (for definition of
subfilter, see the current X.500 extension work to fulfil ITU-T F.510
requirements).
>
>If we take the first interpretation, the value sean.mullan@sun.com will
contribute.
>
>Taking the second interpretation and by looking at the filter, we easily
see that it consists of two subfilters:
>
>AND(mail=sean.mullan@sun.com)(telephoneNumber=47)
>AND(cn=Sean*)
>
>and the value sean.mullan@sun.com will not contribute.
>
>The question is what the user expect when setting this search control (a
user would not or should not be required to understand the tricky
difference between the two interpretation). I have a feeling that an
ignorant user will assume the first interpretation and will not understand
the fine point about subfilters.
>
>Whatever we do, we have to be precise. It will also affect our text for
family of entries.
>
>Kind regards, Erik Andersen
>
>-----Oprindelig meddelelse-----
>Fra: David Chadwick <d.w.chadwick@salford.ac.uk>
>Til: osidirectory@az05.bull.com <osidirectory@az05.bull.com>;
ietf-ldapext@netscape.com <ietf-ldapext@netscape.com>
>Dato: 29. september 1999 13:45
>Emne: A tricky matched values problem
>
>
>Thomas Salter providing the following filter:
>
>(OR(AND(mail=sean.mullan@sun.com)(telephoneNumber=47))(cn=
>Sean*))
>
>to an entry containing the following attributes.
>
>cn: Sean Mullan
>mail: sean.mullan@sun.com
>mail: mullan@east.sun.com
>telephoneNumber: +1 781 442 0926
>telephoneNumber: 555-9999
>
>As you can see, the overall filter is true, the AND is false, but the
>mail attribute value matches true. The question is "does matched
>ValuesOnly apply to the mail attribute or not". ie. should one or two
>mail attribute values be returned.
>
>On the FOR side (one returned value), we have that the AVA was
>true,
>On the AGAINST side, we have that the AVA did not contribute to
>the overall filter matching true.
>
>My first reaction was to say that only one mail value should be
>returned, but whilst drafting the proposed textual addition to X.500 I
>have started to change my mind.
>
>What does anyone else think.
>
>David
>
>
>***************************************************
>
>David Chadwick
>IS Institute, University of Salford, Salford M5 4WT
>Tel +44 161 295 5351 Fax +44 161 745 8169
>Mobile +44 790 167 0359
>Email D.W.Chadwick@salford.ac.uk
>Home Page http://www.salford.ac.uk/its024/chadwick.htm
>Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
>Entrust key validation string MLJ9-DU5T-HV8J
>
>***************************************************
>
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com