[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: VLV indices and multi-value attributes
> 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. :-) --------
>
Whilst X.500 is doing some very interesting things at the moment
for the 2000 version of the standard, work with paged results is not
one of them. This was completed in the 1993 version of X.500 and
is the basis for the original LDAP paged results service (though not
the vlv one).
the interesting things that X.500 is doing, that you might be
interested in are
i) the joining of different entries (in different directories or different
servers) across one or more attributes - this will be of particular
interest to people with hitherto disjoint directories, or ones with a
shared tree but with different service providers holding different
attributes in different entries for the same real world object.
ii) a conceptual compound attribute that will allow collections of
attributes to be related together in a single entry. this feature has
been needed since the inception of directories and was one of the
problems that killed the initial standardisation work of PGP keys -
the ID could only support a user having a single PGP key with
several single valued attributes holding properties of the key. There
are two different approaches being suggested for this feature at
present - one is a real compound attribute whose values are
attributes, and the other is a subentry approach where the
subordinate entries hold the collection of attributes for the parent
entry. i believe that Zoomit via and NDS have the latter approach in
their existing products.
iii) a mapping of X.500 protocols directly onto TCP/IP, without
needing ACSE, ROSE, Session, Presentation layers. This may be
of use to the LDAP folk who want an LDSP. It will be provided,
along with an LDISP for replication.
iv) at the Beijing meeting we also agreed to be supportive of the
access control work suggested by Tim in his email of 2 July, and if
the LDAP group do find necessary technical changes to be made
to the X.500 model then these will be regarded sympathetically by
the X.500 group in order to provide compatibility between the 2
schemes.
v) there is also a lot of work being done to support international
telephone directory enquiries using F.510 and X.500, but this stuff
is very specific to this group of users and does not have wide
applicability in corporate directories in my view.
thats about it for now
David
> 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.
> >
> >
>
***************************************************
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
***************************************************