Since the issue of namespaces has been raised again, and we intend to add it to the draft for 2.0, I thought it might be useful to revisit some of our discussions. See archived threads
here and
here.
I'd like to add several issues:
1) The example in the spec regarding imports is not elaborate enough. We need clarification for when you have a tree of imports, not just a simple service template importing from two other files. What if those files import from other files? And what if somewhere in tree the same file is imported again? (This happens a lot in my use cases, in which I tend to have many different smaller profiles that are reusable.) It would be best if the example listed explicitly what is present in each unit's namespace table, which would also clarify what gets imported into others. (You can use "puccini-tosca parse -d 2" to print out the namespace tables.)
2) Are namespace prefixes additive in imports? That is, if you import a file that imports other files, you would get those names as well, but in what form? Is the import prefix there prepended to existing names? Or are namespace prefixes local to the file itself? Again, a more elaborate example could clarify this.
3) Does the "namespace" keyword affect imports? I think: yes, the imports inherit it unless they specifically change it. That way you can specify a namespace at the root of your profile and all the imported parts will share that namespace. The algorithm for finding the current namespace would thus be to go back in the import tree until one hits the keyword.
4) Are name clashes allowed? E.g., if one namespace takes precedence over the other, will the name be quietly overridden? I would hope not. I think it's a bad idea to make "silent" choices for types behind the designer's back. This is not a "best effort" dynamic language, we need precision here. Any ambiguity in TOSCA should be considered an error. Puccini treats an ambiguous name as an error.
5) I briefly raised the issue of canonical names in relation to the namespace keyword, and indeed my solution in Puccini is an implementation detail, but I think there is benefit to standardizing something in the spec. Canonical names are essentially UUIDs for types, and can facilitate better cooperation between various TOSCA implementations, and also provide an easier reference for documentation, API calls, etc. I think it's clear to all of us that this kind of UUID would be a combination of the namespace and the type name. Note that I'm not thinking that canonical names should be used within TOSCA service templates: e.g. you shouldn't be able to use them as a value for the "derived_from" keyword. I think it's best to keep the namespacing internal to the TOSCA import/namespace_prefix mechanism.
Matt suggested we keep the current scheme of having the namespace be a URL. If we do, I suggest we require this to be so in the spec and not leave it up to arbitrary convention, because this would then define the notation for canonical names. I can think of three ways to combine the components. One is by adding a path element:
name: Compute
One problem with this form is that it may be a bit tricky to parse, one would have to go beyond generic URI parsing and look for the last slash in the path (note that there is no problem in including slashes in type names, because they can be standardly encoded as %2F). But I feel it's a bit problematic conceptually, as it seems to imply some kind of hierarchical structure to the namespace, which is not the case. Another option is to use the URI fragment:
Yet another option is to use a URI query string:
I kinda like this option because it gives us an opportunity to add the "type of the type" (node type in this example) via the query var name, providing a UUID that is even more specific.
But I have to say I'm uncomfortable about using the "http" or whatever standard URL schemas, because actually no network protocol is involved here -- it is misleading and potentially confusing. You cannot normally go to this URL with a web browser. So, we can also use our own URL scheme for namespaces, e.g. "tosca:":
What's nice about this is that it's immediately clear what this URI is for. And you can even do some interesting implementations whereby a client library can support this kind of schema to load a type into a system directly from the canonical name.
But, I wonder if using the URI spec is really necessary. If we go back to the previous discussions we had, I suggested that the Java style ("reverse domain") could be simple and effective:
namespace: org.oasis-open.simple
canonical name: org.oasis-open.simple.Compute
I tend to prefer this the most, because it's much more programming-language-like rather than markup-language-like (XML). It also looks more like the "Type URI" we had in TOSCA 1.0 to 1.3, which we intend to remove but could then have a comeback of sorts via such canonical names. (Though, again, I don't think you should be able to use these canonical names in places like the "derived_from" keyword.)
If we do this, then we also have to discuss how to handle the dot. If the type name would be after the last dot in the canonical name, then should dots be allowed in type names? Or would we allow dots to be escaped, perhaps via a backslash ("\.")? I think it's best not to limit type names in any way, so I would be inclined to allow for escaping them:
canonical name: org.oasis-open.simple.Abstract\.Compute