Re: [tosca-interop] RE: Background question on working assumptions about TOSCA types.

[Thomas Spatzier <thomas.spatzier@de.ibm.com>]

Hi Travis,

you bring up some interesting points below. I added some inline comments.

Regards,
Thomas

<tosca-interop@lists.oasis-open.org> wrote on 06.06.2013 21:44:57:

> From: "Tripp, Travis S" <travis.tripp@hp.com>
> To: Dale Moberg <dmoberg@axway.com>, "tosca-interop@lists.oasis-
> open.org" <tosca-interop@lists.oasis-open.org>,
> Date: 06.06.2013 21:46
> Subject: [tosca-interop] RE: Background question on working
> assumptions about TOSCA types.
> Sent by: <tosca-interop@lists.oasis-open.org>
>
> Hi Dale,
>
> I will provide my impressions.
>
> 1.      A type may only have one parent.  It is basically a tree
> structure.  Something of interest, I have a little program that
> prints out the SugarCRM Capability Type hierarchy.  I’ve pasted that
below.
> 2.      I’ve thought of Types that support having capabilities
> defined on them as similar to the notion of interfaces in Java,
> except that the capabilities have properties, not methods (yet).
> So, if I have a NodeType of Compute, I could actually put multiple
> capabilities on it to decorate it. So, the NodeType can effectively
> be identified through capabilities it provides rather than a
> concrete type. All the examples show a 1:1 of NodeType to
> CapabilityType, but that certainly isn’t what the spec shows as
> possible and isn’t what I think makes sense in many cases. As an
> aside, I am going to try to send out an email on Requirement and
> Capability matching by Monday.

A question that I am asking myself more and more is what kinds of types are
actually more important? I.e. are Node Types the more important thing or
Req/Cap types? For substitutability, it seems that the most important thing
a "client" is interested in are the capabilities of another component.
Likewise, for the client, its requirements are most important.
So we actually don't care if a NodeType is called "foo" as long as it has
the right capabilities (e.g. "compute").
We could think of normative NodeTypes as well-defined combinations of Reqs
and Caps to have some reasonable base system, though, to make everything
more consumable for users.

Anyway, these are just a couple of thoughts ...

> 3.      “Conflicting definitions are resolved by the rule that local
> new definitions always override derived definitions.” Each Type
> section of the document has something called “Derivation Rules”.
>
> SugarCRM Capability hierarchy:
>      RootCapabilityType  (http://docs.oasis-open.org/tosca/ns/2011/
> 12/ToscaBaseTypes)
>           ContainerCapability  (http://docs.oasis-open.org/tosca/ns/
> 2011/12/ToscaBaseTypes)
>                ServerContainerCapability  (http://docs.oasis-
> open.org/tosca/ns/2011/12/ToscaBaseTypes)
>                OperatingSystemContainerCapability  (http://
> docs.oasis-open.org/tosca/ns/2011/12/ToscaBaseTypes)
>                SoftwareContainerCapability  (http://docs.oasis-
> open.org/tosca/ns/2011/12/ToscaBaseTypes)
>                WebApplicationContainerCapability  (http://
> docs.oasis-open.org/tosca/ns/2011/12/ToscaBaseTypes)
>                     ApacheWebApplicationContainerCapability  (
> http://docs.oasis-open.org/tosca/ns/2011/12/ToscaSpecificTypes)
>                DatabaseContainerCapability  (http://docs.oasis-
> open.org/tosca/ns/2011/12/ToscaBaseTypes)
>                     MySQLDatabaseContainerCapability  (http://
> docs.oasis-open.org/tosca/ns/2011/12/ToscaSpecificTypes)
>                ApacheModuleContainerCapability  (http://docs.oasis-
> open.org/tosca/ns/2011/12/ToscaSpecificTypes)
>           EndpointCapability  (http://docs.oasis-open.org/tosca/ns/
> 2011/12/ToscaBaseTypes)
>                IPEndpointCapability  (http://docs.oasis-open.org/
> tosca/ns/2011/12/ToscaBaseTypes)
>                     HTTPEndpointCapability  (http://docs.oasis-
> open.org/tosca/ns/2011/12/ToscaBaseTypes)
>                     DatabaseEndpointCapability  (http://docs.oasis-
> open.org/tosca/ns/2011/12/ToscaBaseTypes)
>                          MySQLDatabaseEndpointCapability  (http://
> docs.oasis-open.org/tosca/ns/2011/12/ToscaSpecificTypes)
>           FeatureCapability  (http://docs.oasis-open.org/tosca/ns/
> 2011/12/ToscaBaseTypes)
>                PHPRuntimeCapability  (http://docs.oasis-open.org/
> tosca/ns/2011/12/ToscaSpecificTypes)
>
>
>
> From: tosca-interop@lists.oasis-open.org [mailto:tosca-
> interop@lists.oasis-open.org] On Behalf Of Dale Moberg
> Sent: Thursday, June 06, 2013 12:16 PM
> To: tosca-interop@lists.oasis-open.org
> Subject: [tosca-interop] Background question on working assumptions
> about TOSCA types.
>
> Hi,
>
> Last Monday someone brought up whether we should think about TOSCA
> types as something like JS prototypes or more like OO classes.
>
> This question made me realize that I did not know what we are/were/
> will be assuming about TOSCA types, but I hope it will be something
> simple and not involve us in something like the “Lambda cube”  and
> “Rank-N polymorphism” and the all the distinctions of the
> programming-language, type theorists behind Coq, ML, F, Haskell and the
like.
>
> Here is what I had been assuming we meant by TOSCA types:
>
> 1. types can have subtypes
> 2. there is inheritance  by subtypes.
> 3. subtypes inherit from at most one supertype (no multiple
> inheritance, no diamond)
>
> Some things unclear to me from our documentation so far:
>
> 1. can anything (method,variable,value,default,etc.) be overridden
> in a subtype?
> 2. if there are abstract types, how do we tell when a type can be
> the type of, for example, a given node template? (we have 3 levels
> now, is the first level abstract and the other two concrete enough
> to have instances?)
>
> I reserve the right to ask a few more questions depending on what
> answers I hear!
>
> [Matt, I have not finished all your slides, and maybe the answers
> were implicit somewhere, but I wasn’t smart enough to extract them.]
>
> Bye
> Dale Moberg
>
>
>
>
>