Grouper Developers Forum

[Tom Barton <>]

Tom Zeller wrote:
> On Thu, Jun 5, 2008 at 9:35 AM, Tom Barton < 
> <mailto:>> wrote:
>
>     In addition, attribute names should come from the grouper_fields
>     table. In particular, there's no [effective|immediate|composite]
>     variants of a list field - that's a UI presentation thing.
>
>
> So do away with [attr|list|priv]Name and just use the field names ? e.g.
>
> dn: ...
> add: members
> members: subjectA
> -
> add: admins
> admins: subjectA
> -
>
> That's (almost embarrassingly) straightforward - I was thinking that 
> non-grouper consumers would want to identify attributes and 
> lists (grouper types) so they would know what values to expect (subjects 
> or strings). At first I thought we should include 'type' in the change 
> representation, and had <type name>[attr|list]Name to identify default 
> and custom attributes, e.g. baseAttributeDescription and 
> memphisAttributeDescription to provide separate attribute namespaces. I 
> wasn't looking at grouper_fields, but rather the API, perhaps I thought 
> too much :)

I don't think that the audit/notification systems need to be signaled 
in-band about the nature of each attribute. Just as with LDAP 
objectclasses or any other container with explicit schema, an 
application will need to know, through configuration or coding, how to 
use the data it's dealing with. An xml-export of the group registry's 
metadata provides a nice human- and machine-readable description 
perfectly suited to this purpose.

Tom
begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
email;internet:
title:Sr. Director - Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard