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

Re: VLV indices and multi-value attributes

Date forwarded: 	Mon, 5 Oct 1998 09:31:42 -0700 (PDT)
Date sent:      	Mon, 05 Oct 1998 09:30:56 -0700
From:           	dboreham@netscape.com (David Boreham)
To:             	Ed Reed <ED_REED@novell.com>
Copies to:      	ietf-ldapext@netscape.com
Subject:        	Re: VLV indices and multi-value attributes
Forwarded by:   	ietf-ldapext@netscape.com

> Ed Reed wrote:
> 
> > re: multivalued attributes in vlv sorted sets...
> >
> > I don't know how X.500 came to the conclusion you cite, that entries
> > only appear once in any result set, even if there are multiple
> > values...I'd be interested to hear (David Chadwick?)...
> 
> I'm reading from X.511, dated 11/93, page 12, section 7.9 (b), quote: "Is
> the attribute type is multivalued, the "least" value is used..."
> 

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.

I am copying this message to the X.500 list so that anyone who does recollect 
how the sorting rule was made can respond directly. (I suspect Rolf Exner from 
Australian Telecom had something to do with the decision).

David



> > But with the increasing interest in JOIN operations in directories
> > (meta-directories, for instance, and the X.500 proposal to add JOIN
> > semantics to SEARCH operations), it seems we should be taking a more
> > relational perspective on how result sets are computed.
> >
> > It seems like the results of projecting values from attributes into a
> > list should include the kind of dot-product operation that the implied
> > relationship between a single entry and it's multi=valued attribute
> > implies:  They would probably be rendered  in a "values" tuple which
> > looks a bit like (entryID, attributeID, value), and so represented in a
> > relational table, each value being a member of a single tuple, each
> > attribute being the collection of tuples sharing the same entryID and
> > attributeID, and all > Projecting that table into a list where the
> > selection criteria was on entryID and attributeID DOES get you multiple
> > values for each entryID, if indeed there are multiple values stored ...
> > and isn't that the behavior "reasonable" consumers would expect?
> 
> Hmm. Sounds interesting, but I'm not sure what problem you're trying to
> solve. Can you give an example ?
> 
> 
> 
> 


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

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.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

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