[OASIS Issue Tracker] Commented: (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=36155#action_36155 ] 

Gilbert Pilz commented on CAMP-63:
----------------------------------

I'm having a bit of trouble figuring out what to do about the "plan" resource. All of other resources contain attributes that are either Booleans, Strings, Links, etc. and arrays of the same but, in addition to some (but not all) of the usual attributes, "plan" contains the "artifacts" array each element of which may contain, in turn, the "requirements" array each element of which may contain, in turn, the "fulfillment" attribute which may contain ... The metadata mechanism defined in the spec, "type_definition" resources linking to "attribute_definition" resources, is not capable of expressing this. It seems to me we could:

(a) Omit the type_definition for the "plan" resource entirely.

(b) Include a partial type_definition for the "plan" resource, but omit the attribute_definition for the "artifacts" attribute.

(c) Include a full definition for the "plan" resource with a link to an attribute_definition definition who's "attribute_type" has the value "ArtifactSpecification".

(d) Include a full definition for the "plan" resource that serves as the root of a tree of attribute_definition resources that fully describe the Plan; the attribute_definition for "artifact" would link to the attribute_definition for "requirement" which would link to the attribute_definition for "fulfillment", etc.

Note that (d) would either require us to document an extension to the attribute_definition resource or create and resolve an issue to allow attribute_definitions to reference other attribute_definitions.



> 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