[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=36180#action_36180 ] 

Anish Karmarkar commented on CAMP-155:
--------------------------------------

Some of the attribute types in Plan resource are not covered by any of the JSON types that we define. For example, artifact specifications. I suggest we create a new type in common types called 'Object'. This can be used for any of the complicated types that are not covered by our existing common types. This new type, called 'Object', can be defined by pointing to RFC4627 section 2.2.

> 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