[OASIS Issue Tracker] Issue Comment Edited: (CAMP-63) TypeDefinitions for CAMP-defined types

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

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

Gilbert Pilz edited comment on CAMP-63 at 9/11/13 12:59 AM:
------------------------------------------------------------

What isn't clear to me is what I should do if my implementation does not extend the spec with additional resource types, but does add additional attributes to some of the CAMP-defined resources.

After talking with Adrian for a bit we agreed that, since the addition of an attribute to an existing type effectively creates a new type, adding a single extension attribute requires an implementer to build-out the entire tree of type definitions for every resource type in CAMP.

Now, I have another issue. It seems that TypeDefinition resources are collections of Links to AttributeDefinition resources. From the spec: 

"An AttributeDefinition resource represents exactly one supported attribute of one or more resource types."

So, in general, if resource type A has an attribute named "foo" and resource type B has an attribute named "foo", unless both "foo" attributes are of the same type and have exactly the same semantics, I need to create separate, individually addressable AttributeDefinition resources for each "foo" attribute?

      was (Author: gilbert.pilz):
    What isn't clear to me is what I should do if my implementation does not extend the spec with additional resource types, but does add additional attributes to some of the CAMP-defined resources.
  
> TypeDefinitions for CAMP-defined types
> --------------------------------------
>
>                 Key: CAMP-63
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-63
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Priority: Minor
>
> In WD08 Section 5.20.1 (description of TypeDefinitions.typeDefinitionLinks) it reads:
> "This attribute contains Links to TypeDefinition resources that contain information about resource types supported by the Platform. If the Platform does not extend this Specification to add new resource types then the array can be empty. If the array is non-empty, for every resource type that the Platform supports, there MUST be a TypeDefinition resource Link that represents such a resource type."
> If I understand this correctly, this means that if I were to add a new resource type (e.g. org.example.apache:TomcatServer) not only would I have to create a TypeDefinition resource that describes it (along with all its AttribueDefinition resources) but I would also be required to create TypeDefinition resources for Platform, Assembly Template, Application Component Template, Platform Component Template, etc. All this just because I wanted to add one resource type! If I were a developer I would not be at all enthused about having to write all the details of CAMP-defined resource as a prerequisite to defining my own resource type.
> I think the CAMP spec should contain annex that provides the TypeDefinition trees for each of the CAMP-defined resources. Not only would this save developers time, it would also ensure uniformity of the TypeDefinition trees across CAMP implementations. In addition to this, it would provide a style guide for devs that create their own resource types.

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