[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: Version 2: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51955/camp-spec-v1.1-wd35-155-v2.doc (was: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51757/camp-spec-v1.1-wd34-155.doc)
Update base of proposal to WD35. Extend the Links from the parameter_definitions resource to the parameter_definition resources in a similar manner to the way in which we extend the Links from the type_definition resource to the 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]