Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] grouper attribute framework

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] grouper attribute framework

Chronological Thread 
  • From: Tom Barton <>
  • To: "" <>
  • Subject: Re: [grouper-dev] grouper attribute framework
  • Date: Thu, 11 Jun 2009 09:15:23 -0500

Managing an attribute namespace becomes more important the more widely attribute creation rights are delegated. So I agree with TomZ that we should build this in up front, even if we don't intend initially to support delegation of attribute creation.

Of course, namespace management is one of grouper's primary capabilities, so we can leverage what we've already built.

And we'll need to recognize that some attributes are delivered with the system and so reserve a namespace for those.

I suppose we could root the namespace for attributes in the local grouper database under a new root stem, say attr:, or under the etc: root stem, as in etc:attr:. Then delegation is supported in the usual way.

But we'll need a convention about which object type under this stem define attributes, probably constrained by the requirement (if we keep it) to enable attributes to be attached to attributes. Eg, will the group etc:attr:enabledate lend its name to the enabledate system attribute? And if Bob is delegated CREATE to etc:attr:bob:, then he can define attributes starting with bob:?

Finally, in eventual federated scenarios we may need to ensure that attributes carried by groups being shared outside of the local enterprise don't have conflicting names. For groups themselves the enterprise's registered urn prefix is to be prepended to the group's name, eg, the group known locally as app:taghr:authorized becomes I suppose the same urn-prefix approach could pertain to attributes.


Tom Zeller wrote:
I'm wondering if we might want to support/encourage namespaces in attribute names.

(I think there's folks on this list with lots of experience with such things :-)

My rationale is that often a group is represented as a collection of attributes, whether it be for provisioning, auditing, or transmission across a wire, and it might be beneficial for a consumer to be able to determine attribute 'metadata' based on name, since a consumer might have access only to an attribute's name and value.

For example, an attribute describing a stem might be named "grouper:stemAttribute:name".

I don't think we need any special code, we should consider an attribute name to be a String, but in practice we should use a reasonably simple naming convention - which I hope others will have more experience suggesting.


On Thu, Jun 11, 2009 at 1:19 AM, Chris Hyzer < <mailto:>> wrote:


There was already a wiki page on the attribute framework, and I
updated it.

Note, this doesn't specify which release the features will go in, I
assume 1.5 will be a limited edition as we get started with
attributes. :)

Let me know any feedback.


Archive powered by MHonArc 2.6.16.

Top of Page