Which I suggest to call simply “name”. The last part of it could be referred to as “short name”. The full notation could be like this: https://github.com/UAVCAN/pydsdl/blob/008c8f16a45ed2a73d7fc22bdc2991c6a538ae55/pydsdl/dsdl_definition.py#L80-L103
How is this possible, isn’t the definition of a root namespace that it isn’t contained inside another namespace?
Is what you mean that when naming a type it must either be inside the exact same namespace (and use the short name) or you must use the fully qualified name?
I still don’t understand this restriction. Does this restriction disallow having a
root.esc1.control namespace and a
root.esc2.control namespace? Or a
root.esc1.Command definitions together with a
I think of “name” instantly as short name, if you think of it as the fully qualified name perhaps we should avoid using only “name” to avoid ambiguities. I suggest:
uavcan.node - “namespace”
Heartbeat - “short-name”
uavcan.node.Heartbeat - “fully qualified name”
Exactly, and that’s what we’re checking. Suppose a parser is invoked to parse a namespace, and that namespace needs to use types defined in another namespace. Both will have to be supplied to the parser. Now, the parser will need to ensure that one namespace directory is not nested within the other.
Neither of those is affected. What is prohibited is that you can’t invoke a parser with two root namespace directories both ending with the same final path component:
/abc/baz/uavcan; because that would imply that either the same definitions are supplied twice, or members of the same root namespace are distributed across several directories. The latter is dangerous because if a parser is ever invoked on only one of those directories, it will be unable to detect possible conflicts with the other.
Ok, let’s avoid saying “name” and use either “fully qualified name” (can we just say “full name” for brevity?) or “short name”.
DSDL processing tools (e.g. parsers) should issue a warning when a non-deprecated type is dependent on a deprecated type. This would typically mean that the developer forgot to update a dependency version number somewhere in a dependent definition.
Or do we want to treat that as an error? That would make sense to ensure that all dependencies are updated timely? In that case it should also be specified in the spec.
@deprecated # ...definition...
@deprecated # The referred version of foo is deprecated, so is this one Foo.1.0 foo
# This type should be deprecated by extension # The developer probably forgot to bump the version number of Foo Foo.1.0 foo