Handling 1 of N dependencies

[manicprogrammer]

In various specs there are sections that references to other specifications in which the exact choice is not specified but typically one of multiple of those specs would be in use. An example is when an encryption or signing scheme is used- there may be multiple schemes that are supported by the spec but only 1 is used. The relationship to the signing scheme is neither only a reference nor a pure dependency.

The map currently is inconsistent in how it treats those. The relationships may be treated as references, dependencies or handle specially with an intermediate element representing 1 of n relationship.

How to represent these relationships should be done consistently. Some current ideas are:

• make the connection type "depends" but make the label for the connection something like "depends 1 of a"
  • where all the connections for one set would be '1 of a' and if there were additional sets of relationships from the parent it would be represented as '1 of b' etc.
  • this is likely confusing to observe in the map and error prone to maintain
• create an intermediate element that represents a dependency that then has child references connections to the set/sub-set of other specs
  • [spec a] ---depends -> [intermediate] -- references -> [spec y ] and [spec z]
  • This will create a clean separation in the map and not be too difficult to maintain
  • This intermediate element type may need a new element type since it is not a specification but a relationship element but a ; something other than core, non-core

[manicprogrammer]

V1.31+ has the proposed scheme applied to

• well-known-did
• did-spec-registries

did-spec-registries has two 1-to-many relationships, one for signatures and the other for did-method

One variation was made to the proposed scheme. The same relationship label was carried through to the specs so instead of [spec a] ---implements -> [intermediate] -- references -> [spec y ] and [spec z] it was applied as: [spec a] ---implements -> [intermediate] -- implements -> [spec y ] and [spec z]

The element type for the was set to 'intermediate' for the intermediate element.

[manicprogrammer]

The wiki page on how to populate the CSV has been updated to document this scheme as it is expected to be a final change. This issue will be left open for an indefinite period to allow for more input if needed.

[manicprogrammer]

closing issue. An implementation was performed in an earlier release and additional issues for improvements have been made e.g. #35