Re: [camp] [OASIS Issue Tracker] Commented: (CAMP-44) Clarify resource type issues and API

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Actually, in this particular example, the syntax (if you go beyond 
'String') itself is not compatible. I'll update the proposal accordingly.

-Anish
--

On 12/10/13 10:24 AM, OASIS Issues Tracker wrote:
>      [ http://tools.oasis-open.org/issues/browse/CAMP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36107#action_36107 ]
>
> Alex McDonald commented on CAMP-44:
> -----------------------------------
>
> <quote from latest>
> 5.3 CAMP Resource Type Inheritance
> ...
> For example, if type A contains an attribute "address" of attribute type String, which is an IP address; type B also contains an attribute "address" of type String, which is a mac address; and type C inherits from both A and B, then this is considered an error as the semantics of the attribute "address" are not compatible.
> </quote>
>
> What is meant here is not "semantics of the attribute" since only the contents of an attribute have semantics. What is meant is "as the semantics of the contents of the attribute "address" are not compatible".
>
> That poses the question; how do I differentiate, for example, between a MAC address and an IPv6 address so I can consider it incompatible?
>
> > 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!)