# Remove the requirement to have uniquely named top-level DSDL namespaces **URL:** \ **Category:** Development & Maintenance\ **Created:** [July 8, 2022, 11:46am UTC](https://forum.opencyphal.org/t/remove-the-requirement-to-have-uniquely-named-top-level-dsdl-namespaces/1706 "2022-07-08T11:46:47Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [July 8, 2022, 11:46am UTC](https://forum.opencyphal.org/t/remove-the-requirement-to-have-uniquely-named-top-level-dsdl-namespaces/1706/1 "2022-07-08T11:46:47Z")
@scottdixon I recall we discussed this briefly several times a few years ago but the topic was shelved. Was there interest in revising this rule? ![image](https://forum.opencyphal.org/uploads/default/original/2X/1/109024499d3823f2d5274805a1f16113cfe37032.png) Context: [https://github.com/OpenCyphal/pycyphal/pull/68#issuecomment-519625518](https://github.com/OpenCyphal/pycyphal/pull/68#issuecomment-519625518) Currently, it is impossible to have namespaces like `com.nozama` and `com.cyphal` maintained by separate entities, which may be a limitation that can possibly outweigh the risks mentioned above. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [August 31, 2022, 5:02am UTC](https://forum.opencyphal.org/t/remove-the-requirement-to-have-uniquely-named-top-level-dsdl-namespaces/1706/2 "2022-08-31T05:02:49Z")
indeed there is great interest. How did we agree this was a good plan? Geesh. I vote we strike this line. That said, do we need to add in additional specifications about what is allowed or what should be guaranteed by DSDL processing tools? Namely, does the specification control required mechanisms to ensure that type collisions do not occur? For example: given two search paths: ```auto repo0/com/awesomeco/foo_1_0.dsdl repo1/com/awesomeco/foo_1_0.dsdl ``` what is the expected/required output from a conformant DSDL tool where `repo0/com` and `repo1/com` are both used as search paths? Should we just disallow this on its face? Should we semantically compare the contents of duplicate namespaces and allow this if the contents are identical? What about: ```auto repo0/com/awesomeco/foo_1_1.dsdl repo1/com/awesomeco/foo_1_0.dsdl ``` Do we use foo\_1\_1 and mask 1\_0? Make them both available? Another consideration; do we care about this type of thing across multiple runs of a tool? For example: We generate `bar_1_0.dsdl` with the following types available in the tool’s search paths: ```auto repo0/com/awesomeco/foo_1_0.dsdl repo1/com/awesomeco/wazzit_1_1.dsdl ``` Later we try to generate `bar_1_0.dsdl` again but the following types are present: ```auto repo0/com/awesomeco/foo_1_0.dsdl repo1/com/awesomeco/wazzit_1_2.dsdl repo1/com/awesomeco/dohicky_1_0.dsdl ``` Assuming our theoretical dsdl tool could see the previously generated `bar_1_0` types and wanted to determine if they were still valid and assuming that `bar_1_0.dsdl` doesn’t actually use `wazzit` nor `dohicky`, does it matter that the resolved namespaces changed between runs? That is, do we assert that a signature of the namespaces available, as resolved by a union of the contents of available folder trees , is part of a type’s identity or is the type’s identity only determined by the transitive closure of its dependent types? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [August 31, 2022, 10:32am UTC](https://forum.opencyphal.org/t/remove-the-requirement-to-have-uniquely-named-top-level-dsdl-namespaces/1706/3 "2022-08-31T10:32:17Z")
> [@scottdixon](#): > > That said, do we need to add in additional specifications about what is allowed or what should be guaranteed by DSDL processing tools? Namely, does the specification control required mechanisms to ensure that type collisions do not occur? The outcome ultimately depends on the inputs given to the _DSDL processing tool_ so I suggest we state that a given type of a particular version _should_ be defined in exactly one namespace directory; otherwise, the behavior is unspecified. We may add restrictions later. Making the output depend on the previously generated output is hazardous because the result would depend not only on the inputs given to the tool but also on the particular sequence of its invocations beforehand. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [September 30, 2022, 3:58pm UTC](https://forum.opencyphal.org/t/remove-the-requirement-to-have-uniquely-named-top-level-dsdl-namespaces/1706/4 "2022-09-30T15:58:16Z")
Given that this proposal has been available for public comment for over 10 days I move that we approve a change to the specification to change the “shall” requirement for complete namespace definition under a given folder. In the PR we can discuss if this should be left unspecified or if it should be demoted to a “should” requirement. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [September 30, 2022, 4:10pm UTC](https://forum.opencyphal.org/t/remove-the-requirement-to-have-uniquely-named-top-level-dsdl-namespaces/1706/5 "2022-09-30T16:10:57Z")
Do likes count as endorsements? ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [September 30, 2022, 4:12pm UTC](https://forum.opencyphal.org/t/remove-the-requirement-to-have-uniquely-named-top-level-dsdl-namespaces/1706/6 "2022-09-30T16:12:21Z")
I suppose but I textual response might be better for RTCs