The 'natural' implementation in LDAP is probably do it the same way as in SQL except in the many to many relations, because in SQL we will have a new table and in LDAP we could only have multivalued attributes. Nevertheless, when I finish the SQL implementation, we can have a framework to discuss about this. Regards, David On Thu, Apr 16, 2009 at 5:53 PM, Burke, S (Stephen) <stephen.burke@stfc.ac.uk> wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Burke, S (Stephen) said: There are also practical implications for the way the info providers are written.
And an even stronger example would be that a UserDomain provider couldn't possibly fill in explicit relations to all the things which refer to it, because it won't have any list of objects to refer to. In general I think there's likely to be a natural hierarchy where the explicit relation should point upwards (c.f. the chunkey discussion), although there may be some cases which are naturally symmetrical where it does make sense to have relations in both directions.
It also seems to me that this must apply a fortiori to the SQL representation since that can't directly have multivalued relations at all, and while the two representations don't have to take the same decisions there may be a natural way to do it which is the same in both.
Stephen
-- Scanned by iCritical.
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Professional Web: http://cern.ch/horat Personal Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat