Debating need for advanced inheritance

[Lestropie]

Diverting conversation from #69 as the primary point of discussion has deviated from the title of that Issue.

Responding to @oesteban's last comment:

What I'm bringing up here is that the multiple inheritance problem is not an urgent one to solve IMHO

I've been convinced enough that it's a prohibitive problem to have written mountains of text on it and made multiple PRs on the inheritance principle itself. I think part of the problem is that one can envisage some kind of tweak that bypasses that problem without appreciating the massive consequences that such seemingly innocuous tweaks can have. Therefore I've tried to have all options documented (for other observers: see #32, #50, workshop document), so that when someone raises such a proposal I can immediately point them to the result of fully contemplating such.

If the comment relates specifically to the need to inherit multiple files within a directory, ie. an explicit augmentation of the inheritance principle, then the selection of option 3 in #50 (ie. placing model fit parameters in a sub-directory) is the way in which hierarchical inheritance is achieved; but while that doesn't necessitate a change to the inheritance principle part of the spec, it requires a highly non-trivial change elsewhere in the spec. No free lunch and all that.

could be pushed to BIDS 2.0 where breaking backward compatibility with BIDS 1.0 should not be a problem

There is an argument to be had about modifying the inheritance principle within BIDS 1.0. Both proposals (bids-standard/bids-specification#1003 and Lestropie/bids-specification#5) would not change the parsing of any existing validator-compliant dataset, they would only make hypothetical datasets that are impermissible under one minor version to become permissible in a subsequent minor version. Not making a hard case for it, just noting that it's plausible.

I prefer to follow the BIDS workshop's motto and go from specific to general.

The ball-and-sticks example near the end of the current BEP contents shows how that model requires complex inheritance. The current contents there are predicated on augmentation of the inheritance principle; a PR could be constructed to conform the contents here to the model sub-directory solution converged toward in the workshop, but my argument is that it requires "a hierarchy of metadata" regardless of the filesystem / specification solution utilised to facilitate such.

I imagine that this would be even worse for the more general case of mixture models, with different parametric forms for different components of the composition, but I've not yet fully familiarised myself with that space.

let's take the most common DWI models (e.g., everything currently supported by MRTrix and DIPY)

Everything supported by DIPY would I think be a lot more than is currently present. We deliberately stripped it back to just rank-2 tensor, MSMT CSD, and ball-and-sticks.

[Lestropie]

As per #92, currently progressing on the premise of duplication of model metadata across multiple sidecars.