Re: VLV indices and multi-value attributes

[Helmut.Volpers@mch.sni.de (Helmut Volpers)]

David Boreham wrote:

> David Chadwick wrote:
>
> > Ed is correct. Section 7.9 clearly states that the least value is used, and the
> > inference is that the entry only appears once in the sorted list. I don't know how
> > this decision was made as I was not party to this particular discussion. I was
> > however party to the discussion in X.518, of results merging (section 21), in
> > which it states that duplicate entries are removed from a merged result if the
> > partial results are not signed. However, I believe that this is a different issue to
> > the sorting/ ordering of the results presented to a user when multivalued
> > attributes are present in an entry. But I can see that maybe the two issues
> > have become inter-related, and that the sensible decision for a DSA to remove
> > duplicate entries before passing the result set back to the caller (which can be
> > another DSA in a distributed system), has been mapped into the decision that
> > a DSA passing sorted entries back to a user does not include the same entry
> > twice even though it contains multiple different values of the sorted attribute.
> >
> > I would be prepared to raise a defect on X.500 over the sorting issue if people
> > agree that entries should appear multiple times in a sorted list in each place
> > where their multiple valued attribute occur.
>
> Trouble is, you can cite instances where either behavior is
> more appropriate. For example: if a person has two surnames
> (canonical example is someone who gets married), and
> you're displaying a sorted list of people, then a strong case
> can be made that that person should show up twice, otherwise
> how can they be "found" by both names ?
> However, consider the case where people entries have
> a multivalued objectclass attribute (the example works
> with any attribute which is multivalued for every entry
> and gets sorted), and the client requests sorting on that
> attribute. If entries show up in the list once for each
> value, then _every_ entry will be repeated n times.
>
> We actually build a server which worked the "wrong"
> way first (it was a bug), and only noticed when an
> example of the second kind above happened
> (i.e. "Hey why is every entry showing up 4 times ???).
> We then fixed the bug, and had people complain that
> the behavior was now "wrong" because they were
> looking at an example of the first type above.
>
> In the thinking I did following these events,
> I came to the conclusion that a case may be
> made for both kinds of behavior, but that the
> best to implement for now is the "single entry copy"
> version. This is both compliant with X.500, and
> also seems to match up well with deep assumptions
> in the Directory information model (as you say above,
> the rule that entries should not be returned more than
> once is fundamental).

I like David's rule that entries appear only once in a search result.

Helmut

>
>
> It's been suggested that perhaps the thing to do is
> to extend the sort control to allow the client to specify
> which behavior they require.


begin:          vcard
fn:             Helmut  Volpers
n:              Volpers;Helmut 
adr:            Otto-Hahn-Ring 6;;;Munich;;81730;Germany
email;internet: Helmut.Volpers@mch.sni.de
title:          Directory Server Architect
tel;work:       +49-89-63646713
tel;fax:        +49-89-63645860
tel;home:       +49-89-1576588
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard