OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[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]