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: 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]