Re: VLV indices and multi-value attributes

[dboreham@netscape.com (David Boreham)]

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

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.