tosca-interop — archive

Background question on working assumptions about TOSCA types.

From: Thomas Spatzier <[email protected]>
To: [email protected]
Date: Fri, 07 Jun 2013 07:09:00 -0000

Hi Travis, you bring up some interesting points below. I added some inline comments. Regards, Thomas <[email protected]> wrote on 06.06.2013 21:44:57: > From: "Tripp, Travis S" <[email protected]> > To: Dale Moberg <[email protected]>, "[email protected] > open.org" <[email protected]>, > Date: 06.06.2013 21:46 > Subject: [tosca-interop] RE: Background question on working > assumptions about TOSCA types. > Sent by: <[email protected]> > > 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: [email protected] [ mailto:tosca- > [email protected]] On Behalf Of Dale Moberg > Sent: Thursday, June 06, 2013 12:16 PM > To: [email protected] > 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 > > > > >