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

Re: A tricky matched values problem

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

***************************************************