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-63) TypeDefinitions for CAMP-defined types

     [ http://tools.oasis-open.org/issues/browse/CAMP-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Chapman  updated CAMP-63:


on the cover page add the following text to Additional artifacts:

"This prose specification is one component of a Work Product that also includes a non-normative auxiliary file:  http://docs.oasis-open.org/camp/camp-spec/v1.1/camp-type-definitions.zip";

and at the end of section 5.18.1 of wd37 add the following:

 "To help developers in supporting this requirement, a package containing the type_definition resources for every resource defined in this specification is included as a non-normative auxiliary file."


> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]