Subject: RE: A tricky matched values problem - I vote for (2)!!

From: "Salter, Thomas A" <[email-masked]>
Date: Mon, 18 Oct 1999 10:05:47 -0400

I'm also voting for 2 for similar reasons.

However, instead of a "search filter", I think it should just be a "SET of
AVA".  Eliminating the filter should eliminate all ambiguity about which
filter items get evaluated.  In X.500 this should be added to
EntryInformationSelection.  

 > -----Original Message-----
 > From: Anthony Hodson [mailto:[email-masked]]
 > Sent: Monday, October 18, 1999 6:10 AM
 > To: [email-masked]
 > Cc: [email-masked]; [email-masked]
 > Subject: A tricky matched values problem - I vote for (2)!!
 > 
 > 
 > Hi, David!
 > 
 > Good to have your analysis, which I *generally* agree with.  But ...
 > 
 > With 1A, consider a filter OR(A, B) where, with a particular 
 > entry, both
 > A and B are true; as a result of this (using 1A), assume that A would
 > cause a value x to be returned, and that B would cause a 
 > value y to be
 > returned.
 > 
 > Presumably you would return both x and y with 1A, even 
 > though neither A
 > nor B could be *completely* said to have contributed, since 
 > either could
 > be omitted without affecting the outcome.
 > 
 > It was consideration of this kind of issue that led to the simple and
 > easy-to-implement rough-justice rule: if a filter item is 
 > TRUE, send the
 > value anyway.  I don't defend it at all on philosophical grounds.
 > 
 > My view is that your solution 2 is *much* the better 
 > solution because of
 > its direct approach to solving the problem, since matched-values was
 > always a bit kloodgy for the reasons that you suggest.  I 
 > think that it
 > would be much better for FDAS/F.510, too.  Something has to 
 > change with
 > existing MVO implementations, and (2) presents no technical 
 > challenges.
 > 
 > Best wishes
 > 
 > Anthony
 > 
 > In message <[email-masked]>, David Chadwick
 > <[email-masked]> writes
 > >First let me apologise for taking so long to answer all the 
 > emails on  this 
 > >topic, but I have been up to the proverbials in work (I 
 > still am, its  now 
 > >10,30pm on Sunday evening).
 > >
 > >Firstly I do not believe that the Molesworth principle 
 > should apply for  the 
 > >matched values control. This is because the user, in 
 > specifying  this control, 
 > >is obviously trying to limit the size of the response,  
 > therefore the correct 
 > >action by the server would be the Molesless  principle if 
 > there were one i.e. if 
 > >in doubt return less attribute values  rather than more.
 > >But I am not advocating either principle, but rather I am 
 > agreeing  with Paul 
 > >Dale that sound logic and a consistent and easily  reasoned 
 > scheme is needed. 
 > >And as Erik said "we need to be  precise".
 > >
 > >Harald has rightly pointed out that quote "it might be 
 > better to have a  control 
 > >that tells the server something about what the client wants 
 >  back rather than 
 > >something about how he wants the search criteria  treated." 
 > What matched values 
 > >was trying to do was both with one  simple boolean. ie. the 
 > matched values 
 > >boolean was saying  something about what the client wanted 
 > back (i.e. limit the 
 > >values),  but using the search filter to specify precisely 
 > which values are to  
 > >be limited in the return. The trouble as we can see arose 
 > because  the search 
 > >filter can be a mixture of truths, unknowns and falses,  
 > and a simple 
 > >matchedValuesOnly boolean was too blunt a tool (as  
 > currently specified) to 
 > >differentiate between them. It therefore was  not precise 
 > enough in its 
 > >specification.
 > >
 > >Therefore it seems that there are two sensible options that 
 > can be  taken:
 > >
 > >1) is to tighten up considerably on the definition of the 
 > current  MVO boolean. 
 > >There are three views of how to tighten up the  definition. 
 > 1A) One is to say 
 > >that only those attributes that  contributed to the overall 
 > truth of the filter 
 > >are governed by the MVO  boolean. 1B) Another is to say 
 > that if the filter item  
 > >was true then  MVO applies to the attributes in the filter 
 > item (even if the 
 > >subfilter  containing the filter item was false). 1C) And 
 > the final one 
 > >suggested  by Bruce was if the attribute was in the filter, 
 > even if the filter 
 > >item  was false, then apply MVO.
 > >
 > >2) the other is to replace the boolean by a return filter 
 > (as  suggested by both 
 > >Harald and Bruce) that acts on the attributes to  be 
 > returned and filters out 
 > >some of the values. This works  independently of, and 
 > after, the Search filter.
 > >
 > >My preferred approach is the first, 1A) i.e.only those 
 > attributes that  
 > >contributed to the overall truth of the filter are governed 
 > by the MVO  boolean. 
 > >My reasons are as follows:
 > >
 > >I reject the current X.500 text (option 1B) for the 
 > following reason:
 > >subfilters that evaluate false or undefined might as well 
 > be missing  from the 
 > >filter, and if they were there on their own then no entries 
 >  would be returned. 
 > >THerefore they have no claim to act on the  returned values 
 > of any entries.
 > >
 > >I reject option 1C) as it is too loose and it does not work 
 > properly for  false 
 > >filter items, as presumably no attribute values would be  
 > returned from these 
 > >attributes.
 > >
 > >Option 2) has its merits, and is clean. The reason for 
 > rejecting it is  
 > >compatibility with X.500, and that option 1A can (as Mark 
 > points out)  do the 
 > >same task anyway, but perhaps not quite as efficiently. So  
 > option 2) might be 
 > >more efficient than 1A) but at the expense of  
 > compatibility with existing 
 > >implementations.
 > >
 > >I am happy to update the ID was the proposed solution 1A 
 > unless  anyone has 
 > >strong objections to this.
 > > 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 
 > >[email-masked] Home Page  
http://www.salford.ac.uk/its024/chadwick.h
>tm 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
>***************************************************

Anthony Hodson <[email-masked]>      X   X    DDD
XdotD Associates                             X X  O  D  D
Spring Lanes House, Holly Spring Lane         X  OOO D   D  
Bracknell, Berks RG12 2JL, ENGLAND           X X  O  D  D
Tel: +44 1344 310665                        X   X    DDD
Mob: +44 771 360 7086
Fax: +44 870 056 8242

---

From: "Salter, Thomas A" <[email-masked]>
Date: Tue, 19 Oct 1999 10:39:28 -0400

You're right.  I missed the "simple" in "simple filter". 

Tom

 > From: Bruce Greenblatt 
 > [mailto:[email-masked]]
 > Sent: Tuesday, October 19, 1999 1:38 AM
 > To: Salter, Thomas A; [email-masked]
 > Subject: RE: A tricky matched values problem - I vote for (2)!!
 > 
 > 
 > At 10:05 AM 10/18/99 -0400, Salter, Thomas A wrote:
 > I don't think that the SET of AVA is sufficient for attribute value
 > selection.  AVAs in LDAP only allow you to specify the 
 > attribute type and a
 > proposed value.  They don't let you specify the relational 
 > operator.  This
 > is why I proposed the "Simple Filter" construct previously.
 > 
 > Bruce
 > 
 > >>tm Understanding X.500  
 > http://www.salford.ac.uk/its024/X500.htm X.500/LDAP
 > >
 > ==============================================
 > Bruce Greenblatt, Ph. D.
 > Directory Tools and Application Services, Inc.
 > http://www.directory-applications.com
 >