Quote from the last round (one of the last outdated diffs):
> Maybe a "code" attribute like the security subsystem ? So we can handle two situations:
> 1) User-defined types with "class-name" + "module"(optional)
> 2) Built-in types with "code"
> Where in #2, we resolve the proper type based on a alias like: Partition, IdentityType or Relationship. Which are core concepts in PL IDM.
> FYI, the configuration above can be easily replaced by:
      supported-types supports-all="true"
> So no additional supported-type is necessary in order to support all PL IDM types and their corresponding sub-types.
> The supported-type will be mostly used when users want a more fine-grained configuration, where only some specific types are supported by a specific store. Eg.:
> ldap-store may support only User (which is a sub-type of IdentityType) and Grant (which is a sub-type of Relationship). And no Partition type is support.
> jpa-store may support only GroupRole (which is a subtype of Relationship).

So I think the optional module means load from the subsystem/idm?

I think a 'code' makes sense for these predefined ones. I think @bstansberry 's point about using enums here is that the "alias" approach in the security subsystem is brittle when you think of the future. We should offer a short-hand, but not for things which are likely to disappear. If using enum (implemented internally as an EnumValidator for the SimpleAttributeDefinition) a nice thing is that the user gets to see all the accepted values when doing read-resource-description/read-operation-description, so you could have a tailored set of enums for each store.

So you'd have either an external module:
     <supported-type class-name="some.Thing" module="some.module">
or a picketlink module:
     a)  <supported-type class-name="org.picketlink.idm.model.Partition">
     b)  <supported-type code="Partition"> (an enum)

If we're going with 'code' (b) then I don't think a) is needed, so IMHO 'module' should be required if 'class-name' is used.