Re: VLV indices and multi-value attributes

[dboreham@netscape.com (David Boreham)]

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

> 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 the attributes with the same entryID being treated as the object entry itself.
>
> 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 ?