Grouper Developers Forum

[Tom Barton <>]

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 
urn:mace:uchicago.edu:app:taghr:authorized. I suppose the same 
urn-prefix approach could pertain to attributes.

Tom

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.
>
> TomZ
>
> On Thu, Jun 11, 2009 at 1:19 AM, Chris Hyzer < 
> <mailto:>> wrote:
>
>     Hey,
>
>     There was already a wiki page on the attribute framework, and I
>     updated it.
>
>     https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Attributes
>
>     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.
>
>     Regards,
>     Chris