Stanford has been looking into implementing the value-sort attributes overlay, and realized some problems with using it, if the attribute to be weighted is also indexed and you will be using weights. Primarily, the problem stems from this:
The unweighted form of the data could look like:
suaffiliation: stanford:staff suaffiliation: stanford:faculty
etc
The weighted form of the data looks like:
suaffiliation: {2}stanford:staff suaffiliation: {1}stanford:faculty
This means if you use the data for indexing (in particular, in my case, eq indexing), it will no longer be possible to use filters of the type (suaffiliation=stanford:staff). Which is problematic when many applications do that very thing (and internal ACL's use it as well).
I thought a potential solution (not possible at this time, per Howard) would to be able to support something like multiple indices (sub indices?) that would actually index the data in both its weighted and unweighted form, if the val-sort overlay was present. It is also something I thought could be potentially useful for other overlays (how, I'm not sure). But the ability to have indexing behave differently based on different factors does seem potentially useful.
In addition, things get more complicated when telephoneNumber (and things using its syntax) are involved. Mostly because {}'s are not valid characters per its syntax, meaning you can't sort the attribute via weights. The ability to tweak SYNTAX based on overlays I guess would be the solution, but sounds ugly.
Anyhow, just a set of thoughts, I don't know how practical implementing such a thing would really be.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html