RE: Background question on working assumptions about TOSCA types.

["Tripp, Travis S" <travis.tripp@hp.com>]

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.

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