Grouper Developers Forum

["Jessica Bibbee" <>]

MACE-Dir-Groups Conference Call
March 8, 2006

*Participants*
Tom Barton, U. Chicago (chair)
Joy Veronneau, U. Cornell
Steve Barrett, U. Cornell
Gary Brown, U. Bristol
Renee Frost, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

Carry-over *Action Items*
[AI] Please contact {Tom} if you have a scenario to contribute for use at the Deployment Workshop. (8-Feb)

*Discussion*
Discussion focused on Gary's work of the XML import/export tool, changing path element stem, considerations of name space terms, and having the API settle operational attributes on creation of a group.

{Gary} detailed the XML import/export tool, which he had emailed the list with a couple of examples (8-Mar). The XML files showed groups, members, and privileges assigned.  There is a section for metadata, which gets the structural information on the repository when data is exported, and has an option of creating when importing. Conflict may arise if there is a field that is already defined. He also exported information about the subject sources in the repository before doing an import.

What is the right choice for the naming attribute as a subject identifier of a group? The identifier will be created as part of the load when importing. However, if it is exported, it might be provisioned into LDAP and if maintenance actions are performed, you would want the group ID to be preserved – across both import and export operations. Currently, there is no way to assign an ID such that it can be maintained without a potential duplicate.  If you need to merge registries and had duplicate identifiers assigned, a unique id could be generated and assigned for a specified unit of time. If you export a portion of the tree and then import back into the same repository, you might label it under another ID.

The discussion also surfaced several additional points for review:

• The "path" element name should probably be changed to "stem" for consistency with other parts of grouper.
• Perhaps group attributes ought not to be aggregated by group type – there needn't be a strict relationship between them. In this case it remains to determine how to represent a separate list of group types.
• When a group is shown as a subject in a list, what should its "identifier" attribute be? Should it be the group's name, as shown in Gary's example, or should it be the group's id, i.e., the GUID associated with each group? Perhaps there ought to be a configurable option to include specified subject attributes in addition to the three subject identifiers ("identifier", "type", "source") in <subject/> as attributes in elements.

The "..:" notation disappears on stems for importing, instead giving the whole name from the instance of export. In an export, there is a section for internal groups with the UUID – createSource is empty, while createSubject is available. {Joy and Steve} said that it would be desirable to have an option for operational attributes, such as when created and modified, to be preserved across import/export in a database instance. This would provide more flexibility in generating reports with the exact information needed.  For a conversion use case, changes must be maintained on an import. A relative export does not export the whole repository, but just a stem. You cannot import a given stem and choose the relative if in fact you want the parent. In terms of logging, you need to decide how to handle a conversion – wither to keep it in Grouper logs, or if you want to also keep a specific import/export log.

{Joy and Steve} commented that they are using the terms 'direct' and 'indirect', which seem to be more inherent than the use of 'immediate' and 'effective'. However, current convention will not change, as 'immediate' and 'effective' are used in abundance throughout the documentation and javadocs.

For the upcoming Signet/Grouper Early Adopters Deployment Workshop, Grouper v0.9 will provide the most stable version of work; v1.0 will follow shortly after the Spring 2006 Internet2 Member Meeting. A few more items need to be finished up: making the UI more responsive to the API, XML work, group math, and testing.

{Joy} volunteered to speak at the Workshop regarding current work/progress at Cornell.

The next scheduled Working Group conference call is cancelled due to an overlap with the Signet/Grouper Early Adopters Deployment Workshop. Therefore, the following MACE-Dir-Groups WG conference call will be held on Wednesday, April 5, 2006 at 12pm ET.