The attribute_definition resource is modeled incorrectly. The "required", "mutable", and "consumer_mutable" attributes are not properties of the attribute definition but, instead, properties of the relationship between the attribute and its containing resource. I noticed this when I was writing the type and attribute definitions for the pre-great-refactoring version of CAMP. One resource would have a "parameterDefinitionsUri" attribute that was required and another resource would have a "parameterDefinitionsUri" attribute that was optional. The value space and semantics of both attributes are identical but, because we model the required/optional choice in the definition of the attribute itself, I had to create two resources: one to represent a required "parameterDefinitionsUri" attribute and another to represent an optional "parameterDefinitionsUri". Obviously each of these resources had its own, unique URI.

This isn't that big of a deal until you add the notion of resource type inheritance to the mix. If someone where introspecting the type and attribute definitions to figure out what a particular extension resource looked like and came across two parent types, each with an attribute named "parameter_definitions_uri" but which referenced different attribute_definition resources for this attribute, that person would be justified in concluding that this implementation was violating the rules of resource type inheritance.