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

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

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

Gilbert Pilz commented on CAMP-44:
----------------------------------

To sum up where we stand, it seems that we agree on the following:

A1.) CAMP should support inheritance of resource types. The primary, high-level constraint is that the representation of a resource that is a sub-type of another resource must be "substitutable" for the representation of its parent type. If I have client code that depends upon the "contract" defined for the parent type (for example, depends upon a required attribute being present), this client code should not break when processing a representation of a sub-type. Consistent with this notion is the idea that sub-types cannot override their parent types. If a parent type defines a "foo" attribute of type "String", its sub-type cannot override that with a "foo" of type "Boolean".

A2.) CAMP-defined resource inheritance does not involve the "Operations" or "Operation" resources. The "Operations" resource (and, transitively, the "Operations" it references) can be attached to specific instances of the Assembly, Component, and Sensor resources, not an entire resource type. That being said, we haven't talked about HTTP methods very much. By the "substitutability principle" from A1 it makes sense that, if a resource type supports a particular HTTP method, any resource types that inherit from that type should support the same method and implement the same semantics. The "Parameters" and "Parameter" resources could be handled the same way as the "Operations" and "Operation" resources (i.e. they do not affect inheritance).

A2.) CAMP should support inheriting multiple resource types.

It seems we disagree on the following:

C1.) How much, if anything, to say about issues arising from the diamond pattern of inheritance. So far I have heard a spectrum of opinions. On one end of the spectrum I have heard the idea of explicitly forbidding any inheritance pattern in which there is a collision of attributes from parent types (i.e. in which there is an attribute "foo" that is separately inherited from two or more parent types and not from a common ancestor). On the other end of the spectrum there is the idea of not saying anything about the diamond pattern. The idea is that, if we do a proper job of defining what it means to be a sub-type, any of the issues with the diamond pattern fall out as errors. For example, if you try to inherit from two parent types, one that defines "foo" as a String and the other that defines "foo" as a Boolean - you are either going to violate one contract or the other and that, in itself, violates what the spec has to say about inheritance. There is an anti-constraint behind this idea in that we don't want to be overly restrictive and prevent implementations from inheritance patterns in which it is possible to simultaneously honor the contract of two or more parent types, even if they have attribute collisions. In between these two poles I've heard a couple of options. One option would be to leave open the idea of inheriting from two or more types that have the same, non-commonly-derived attribute but to require that such attributes SHALL have the same type.

> 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