[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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 <E11cz2q-00018p-00@rhenium.btinternet.com>, David Chadwick
<d.w.chadwick@salford.ac.uk> 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
>D.W.Chadwick@salford.ac.uk 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 <aeh@xdotd.demon.co.uk> 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