[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (CAMP-155) attribute_definition resource is modeled incorrectly
[ http://tools.oasis-open.org/issues/browse/CAMP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Pilz updated CAMP-155: ------------------------------ Proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51757/camp-spec-v1.1-wd34-155.doc (was: High level proposal: extend the Link type in the attribute_definition_links array to include "required", "mutable", and "consumer_mutable" as modifiers to the link. Remove the same attributes from the attribute_definition resource.) Added concrete proposal that moves the "required", "mutable", and "consumer-mutable" attributes from the "attribute_definition" resource to the Links between the "type_definition" resource and its "attribute_definition" resources. > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]