TODO: This allows for generic dependencies to be declared from any node type and we DO have an use case/example for it.

TODO: We need to show a good use case for this generic “feature” capability or remove it. Currently, it is simply the logical analog of the “dependency” requirement of this Root type

TODO: Link to examples elsewhere in document if they exist elsewhere.

I think the definition of the Root node has something wrong: right now we have removed the Feature capability/dependency to replace it with a single dependency requirement of type tosca.capabilities.Root.
But actually no nodes defines the tosca.capabilities.Root capability. I think it's not very correct to satisfy a requirement by something that doesn't match the type of the requirement (and we don't have node directly defining the tosca.capabilities.Root capability).
To make it simpler and, I think, more correct, we should change the dependency definition so the requirement type is directly tosca.nodes.Root as I think any node can depends from another one.

Woud be:

tosca.nodes.Root:
description: The TOSCA Node Type all other TOSCA base Node Types derive from
attributes:
tosca_id:
type: string
tosca_name:
type: string
requirements:

• dependency:
  type: tosca.nodes.Root
  lower_bound: 0
  upper_bound: unbounded
  interfaces: [tosca.interfaces.node.lifecycle.Standard | tosca.interfaces.node.lifecycle.Simple ]

Related to duplicate issue TOSCA-181

Actually if there is no use case for this issue maybe we should remove the depends-on relationship as this is somehow confusing ?

Hi Luc,

In terms of the definition, it is correct using our existing semantics, as a requirement is fulfilled either by a Node Type (which has implicit capabilities) or a an explicit Capability which is included on a Node Type. I believe the "gap" is that no where do we say (nor in schema can we prove) that a Node Type represents a a packaged set of Capabilities. This is an interesting question and could be addressed in schema or addressed in prose/text.

In any event, I do not want to lose your commentary when we get back to this issue.

FYI, I had been in favor of removing the built-in "dependency"; however Thomas points out this allows "simple" (optional) declaration of dependencies as template authors create node templates (which is very good) without needed to create (subclass a new type) which I am completely in support of.

Hi Matt,

Not sure I get your comment...

Correctly the definition of the requirements for Root node is

requirements:

• dependency:
  type: tosca.capabilities.Root
  lower_bound: 0
  upper_bound: unbounded

This means that we have to connect to any node that provides the "tosca.capabilities.Root" capability. Right now I don't see any node that defines a capability of type "tosca.capabilities.Root". It is not mentioned that somehow all nodes have a "tosca.capabilities.Root" capability so right now the dependency require that a user explicitly defines a node with a "tosca.capabilities.Root" capacity so he can create a depends-on relationship.

I think that if we want to keep the dependency requirement we should change the type from "tosca.capabilities.Root" to "tosca.nodes.Root" to indeed use the implicit capability of the node.

From use-case perspective I would use this as a kind of un-managed relationship. For example for middleware that supports automatic discovery of services through multicast (and having a manager that should be started before containers etc..) I have a valid example of such middleware with GigaSpaces Data-grid product.
Of course you can create a connects to relationship but as the connection is not managed by the TOSCA container you won't have any artifacts related so maybe depends on is more convenient ?

At the TC meeting of Aug. 28, it was indicated that this issue may be related in some fashion to TOSCA-181.

TOSCA TC approved deferment of this issue at the 2014-11-20 meeting. See https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/54595/TOSCA%20Minutes%202014-11-20.docx