RE: VLV indices and multi-value attributes

[William Aitken <waitken@geotrain.com>]

	On Tuesday, October 20, 1998 11:51 AM Ed Reed wrote :
	> 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.

	I agree with Ed Reed that there is a potential for reuse of existing
knowledge (in research, standards, products and consumers) of the relational
model. I did not understand that Ed was suggesting developing  "Relational
access to the underlying data stored in a Directory Service", but using the
relational model only as a useful metaphor for analysis and design.

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

	I agree with Ed that these are 'two separate functions'. I see the
creation of the sorted return set (using client supplied sort control) as a
server ' view creation'  function; and the data positioning in the return
set (cursor control) as a client-server 'distribution' function. Relational
database products have used this approach for many years. 

	Perhaps David Chadwick can shed some light on the status of how the
X.500 Working Group is approaching 'paged results / vlv' . Afterall, I do
believe that X.500 is another example of a potential for reuse of existing
knowledge (in research, standards, products and consumers) for the benefit
of the Directory. :-)                  --------

	Bill
-
William Aitken
waitken@geotrain.com
+1-613-736-6110
http://www.geotrain.com
Enterprise Directories: Consulting and Training
GeoTrain Corp.
2430 Don Reid Drive
Ottawa, ON  
Canada K1H 1E1



> -----Original Message-----
> From:	Ed Reed [SMTP:ED_REED@novell.com]
> Sent:	Tuesday, October 20, 1998 11:51 AM
> To:	dboreham@netscape.com; Ed Reed
> Cc:	osidirectory@az05.bull.com; d.w.chadwick@iti.salford.ac.uk;
> ietf-ldapext@netscape.com; merrells@netscape.com; Jim Sermersheim
> Subject:	Re: VLV indices and multi-value attributes
> 
> 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
> 
> >>> 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.
> 
>