OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tosca] Thoughts on TOSCA names and namespaces


I completely agree. The âtosca.nodes.*â notation is just some naming convention that must have been introduced early on, and doesnât actually have any meaning associated with it (i.e. it doesnât refer to any namespace). I fully support eliminating this convention.

 

Of course, this means weâll have to update all the examples in the spec L

 

Chris

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Tal Liron
Sent: Thursday, November 21, 2019 10:59 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Thoughts on TOSCA names and namespaces

 

First, our names are too long. :)

 

The Simple Profile, and all our examples as well as a lot of TOSCA "out in the wild", use "fully qualified names" such as these:

 

tosca.nodes.Compute

tosca.artifacts.Root

tosca.capabilities.Root

myprofile.capabilities.Host

 

The middle part, specifying the type hierarchy, is superfluous. Such names should already exist in separate namespaces per type hierarchy, because there is no ambiguity in how TOSCA uses them. There is never a case in TOSCA where, say, a capability type name could overlap with an artifact type name. So these shorter names should be fine:

 

Node types: tosca.Compute

Artifact types: tosca.Root

Capability types: tosca.Root, myprofile.Host

 

Second, this "fully qualified name" practice, using the dot notation, is itself superfluous, because TOSCA supports namespaces. So if we do:

 

imports:

- file: tosca-simple-profile.yaml
  namespace_prefix: tosca

- file: my-profile.yaml
  namespace_prefix: my

 

The names would then be:

 

Node types: tosca:Compute

Artifact types: tosca:Root

Capability types: tosca:Root, my:Host

 

It just means using a ":" instead of a ".". Actually, this is already the default behavior for the implicit import of the TOSCA Simple Profile. Compliant TOSCA parsers should support this syntax right now. If we stick to this syntax then there's no need for global "fully qualified names" at all. In the profile definition itself you would use simple names, e.g.:

 

node_types:

  Compute:

    ...

 

Using explicit namespaces is much safer, because it can guarantee no ambiguity for users importing the profile.

 

Am I suggesting, then, that the "namespace_prefix" keyword in "imports" should be required? Not necessarily. If the "namespace_prefix" is not provided, then the names can be used without a prefix. If there are ambiguity conflicts then the parser should emit an error and the user can use prefixes to avoid ambiguity. This is how many programming languages work.

 

This proposal would also go some way towards making the Simple Profile seem less like a "normative" standard due to the "tosca." part of the name, which has always bothered me. For example, one could import it this way if one prefers:

 

imports:

- file: tosca-simple-profile.yaml
  namespace_prefix: simple

 

topology_template:

  node_templates:

    MyNode:

      type: simple:Compute

 

Or use "tosca:" for better backwards compatibility with previous versions of the TOSCA standard.

 

I hope this makes sense and be part of our recommendation for separating out the Simple Profile from the core language.

 

Quick note: I am using a file named "tosca-simple-profile.yaml" here. It's intended merely as placeholder. There is a separate discussion going on about how we would import such "built in" profiles, and we probably won't want them to just be filenames.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]