[OASIS Issue Tracker] Commented: (CAMP-155) attribute_definition resource is modeled incorrectly

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36166#action_36166 ] 

Gilbert Pilz commented on CAMP-155:
-----------------------------------

After working through all the resources and their attributes (post great-refactoring) I have found that there are still a couple of cases in which attributes of the same name, type, and value space are constrained differently by different resources. For example, the "version" attribute (of type "String" that identifies a version of something) is required by the "extension" resource but optional in the "format" resource; the "documentation" attribute is required by "format", "operation", "sensor", and "type_definition", but not "extension".

We could resolve this issue by giving those attributes with unique constraints unique names. For example "extension_version" and "format_version". I think this is the wrong way to go, but it is an option.

> attribute_definition resource is modeled incorrectly
> ----------------------------------------------------
>
>                 Key: CAMP-155
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-155
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira