control separation of function (was Re: VLV indices and multi-value attributes)

[Ed Reed <ED_REED@novell.com>]

Jim and I have just spent some time going over the issues here, again...

I still think separate controls for sorting and indexed retrieval (vlv) are
a good idea.

But the question of how a requestor wants multivalued attributes to be
returned is associated with the search result set, not its ordering, nor 
its paged results.

Perhaps we're arguing ourselves into a new control that allows the user
to specify when multivalued attributes should be exploded out into a 
results set where each single value attribute is matched with each value
of each multivalued attributes (leading to an explosion in the size of the
result set, I know, but that's what the server-side sorting helps with, and
the paged results lets the user browse the result set at their will).

This optional behavior would only be invoked when the appropriate control
is used to augment the attribute selection with another list of special
treatments to be given to the attributes.  Such special treatments might
include any number of things - formatting of output, min/max/average/other
operations on the attributes (in the case of grouping-type functions like
min/max/average only one value would be returned for that attribute, but
the requestor would have control over WHICH value that was), etc.  I'm 
sure you can think of more.

Such a control would be useful on READ and LIST operations, too, when
they're added to the LDAP vocabulary...

Ed
>>> "Ed Reed" <ED_REED@novell.com> 10/20/1998 09:50:51 >>>
Granted.  But relational IS the metaphore that is taught, these days, in 
computer science schools, almost to the exclusion of hierarchical or
network models.  And you have to admit that the SELECT clause
construct presents a useful breakdown of the relevant parameters, and
even suggests, reasonably, I think, a way of breaking down the problem...
identify the useful data from the data sources on the basis of some
inclusion/exclusion criteria, then sort the results and return them to the 
requestor.  It's that separation of inclusion/exclusion criteria from the
desired ordering that I think can inform us about "intuitive" partitioning
of arguments and operations, and that suggests that the sorting control
is usefully separate from the selection criteria, or from the cursor management,
for that matter (vlv controls).  It leads me to believe that a sort control
that specifies collation sequence for the return set and a
cursor (paged results / vlv) control providing programs with data positioning
in the return set should be separate and not munged together (an undesireable
linking of two separate functions).

And, yes, the issue of multiply valued attributes is not something which is
dealt with generally in relational models, except through dot products and
equi-joins, but those are merely the mechanism of the relational calculus
for handling the data we construct and use.  We don't have to adopt
a relational model for the directory, but neither need we ignore the
work done there as we consider how to surface directory content 
in useful ways for developers and consumers.

Best regards,
Ed

----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320

----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320

>>> David Boreham <dboreham@netscape.com> 10/19/1998 10:56:10 >>>
Ed Reed wrote:

> In fact, if you simply follow the canonical syntax for relational SELECT operations, you see
>
> SELECT columns (attributes, in LDAP)
> FROM tables (classes in LDAP)
> WHERE selection criteria (search filter in LDAP)
> ORDER BY results ordering criteria (your proposed sort control in LDAP)

Trouble is, the Directory isn't a relational database.
Different information model.
Many subtle consequences result.

Relational access to the underlying data stored in
a Directory Service is an intersesting facility, but
I suspect it's a quite different animal to some extensions
to LDAP.