1) Does ARIA actually support  namespace_uri and namespace_prefix for each
import definition as defined in YAML 1.1 spec. See multi-line grammar below:

> imports:
>   - file: <file_URI>
>     repository: <repository_name>
>     namespace_uri: <definition_namespace_uri>
>     namespace_prefix: <definition_namespace_prefix>
>

This is in TOSCA 1.0, too. Repositories are supported. Namespaces aren't,
but we have an open JIRA.

2) What does ARIA do with this information today especially the namespace
> prefix? I guess it is currently ignored but could be used in the future (?)
>

Ignored for now.


> 3) When creating a type definition file, is it important to  ensure all
> new type names defined in the imported file are using the declared
> namespace prefix (assuming namespace prefix is provided in the import
> definition)?
>

The convention is the dot notation, just like in the Simple Profile, e.g.
"tosca.capabilities.Container". First segment is the domain, second is the
type of the type (node, capability, data, etc.), and third is the short
name of the type in camel case.

E.g.: "ericsson.nodes.VirtualRouter"


> 4) Is it bad practice to mix new types from different namespace prefixes
> in the same type definition file (assuming namespace prefix is *not*
> provided in the import definition)?
>

Hard for me to say! I think it could make sense in certain uses.


> 5) For plugins, is it possible to support a more specific filename instead
> of a static/fixed name like plugin.yaml? What about using
> <plugin_name>-<plugin_version>.yaml? I see the need for ST authors to
> retrieve these files for analysis and the last thing I want to do is to
> rename them.
>

There are discussions afoot for redoing a lot of things with plugins... for
now I would say keep an eye on developments and voice your opinion as it
moves. We will make sure to get feedback from the community.


> 7) To simplify the import definition for plugins, the user should also be
> able to import a plugin name without specifying the version. For instance:
> - file: <plugin-name>
>   repository: plugins
> Here  <plugin_name> is an alias always pointing to the latest version of
> the <plugin_name>-<plugin_version>.yaml file.
>

There's just a general mess between the import and the use of policies for
plugins. We would want to unify the two and make it more transparent.

Reply via email to