@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?
Context:
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.
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:
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:
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:
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:
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?
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.
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.
Do likes count as endorsements?
I suppose but I textual response might be better for RTCs