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-44) Clarify resource type issues and API


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

Anish Karmarkar updated CAMP-44:
--------------------------------

    Proposal: 
Directional proposal:

1.) Amend the TypeDefinition resource to contain an array of Links to other TypeDefinition resources. The resource type described by this TypeDefinition is a sub-type of the types referenced by these Links - it is substitutable for those types.

2.) Add language to clarify that the types referenced in this array cannot define attributes of the same name unless those attributes are inherited from a common ancestor (e.g. Resource).

3.) Re-factor the "common attributes" (e.g. "name", "type", etc.) as attributes of a base resource type called "Resource" that every other resource inherits from.

Inlined proposal based on agreements on previous calls: https://www.oasis-open.org/committees/download.php/51688/camp-spec-v1.1-wd32-issue44rev2.doc

Updated version of inlined proposal at https://www.oasis-open.org/committees/document.php?document_id=51791&wg_abbrev=camp
This resolves comments by AlexM and Gil

  was:
Directional proposal:

1.) Amend the TypeDefinition resource to contain an array of Links to other TypeDefinition resources. The resource type described by this TypeDefinition is a sub-type of the types referenced by these Links - it is substitutable for those types.

2.) Add language to clarify that the types referenced in this array cannot define attributes of the same name unless those attributes are inherited from a common ancestor (e.g. Resource).

3.) Re-factor the "common attributes" (e.g. "name", "type", etc.) as attributes of a base resource type called "Resource" that every other resource inherits from.

Inlined proposal based on agreements on previous calls: https://www.oasis-open.org/committees/download.php/51688/camp-spec-v1.1-wd32-issue44rev2.doc


> Clarify resource  type issues and API
> -------------------------------------
>
>                 Key: CAMP-44
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-44
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Task
>          Components: Spec
>            Reporter: Alex Heneveld
>            Priority: Minor
>
> There were several key questions about types that have come up in today's F2F:
> What type hierarchy will we use?  Mark requests ability to define e.g. MyGreatDatabase which extends Database.  (We could also have multiple inheritance / interface / etc.)
> How do we explore the type hierarchy?  (The apidoc suggestion in CAMP-1 could come in here.)
> And do we permit dynamic attribute extensions -- e.g. a resource instance has values for other attributes not on its type?  (Yes please!)

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