I would like to propose a requirement that if a particular type of resource CAN provide a capability, then it MUST provide that capability if it is created. There will be no such thing as a resource providing or not providing a capability based on the value of one of its attributes. My question to subsystem developers is whether they have a situation in their configuration model where this will be a problem? For any case where there is such an attribute, the requirement would mean that a child resource would need to be created instead, and that child resource would provide the capability. There are tricks we can use to preserve the existing attribute to provide management API compatibility. The only case I'm aware of where this is a factor is the 'jts' attribute in the subsystem=transactions resource. The reason for this requirement is we want tooling to be able to inspect the types of resources that are available for use, see what capabilities they provide and what requirements they have, and work out what resources need to be present in a configuration in order to have a consistent set of capabilities. That task is significantly more complex if the presence of a capability is determined by some arbitrary attribute value. David Lloyd described allowing attributes to control this as being "like creating an RDBMS where you have foreign keys that only exist if some function evaluates in a certain way." -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat