[ENH] Encode mutually exclusive extensions in schema with sub-lists

[Remi-Gau]

fixes https://github.com/bids-standard/bids-specification/issues/1487

[Remi-Gau]

I would personally consider the rendering fixed and OK but I will let others be the final judge of this.

Example here: https://bids-specification--1492.org.readthedocs.build/en/1492/modality-specific-files/electroencephalography.html#landmark-photos-_photoextension

[Remi-Gau]

@effigies I am done with the rendering fixes and adding doc + type hints / refactoring.

Will let other fixes to you.

[Remi-Gau]

on second though this rule should phrased somewhere in the specification and not just in the schema, no?

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 90.00000% with 5 lines in your changes missing coverage. Please review.

Project coverage is 88.95%. Comparing base (1235e5b) to head (3958ac0).

Files	Patch %	Lines
tools/schemacode/bidsschematools/render/text.py	89.28%	3 Missing :warning:
tools/schemacode/bidsschematools/schema.py	88.23%	2 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1492      +/-   ##
==========================================
+ Coverage   88.06%   88.95%   +0.89%     
==========================================
  Files          16       16              
  Lines        1391     1413      +22     
==========================================
+ Hits         1225     1257      +32     
+ Misses        166      156      -10     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[effigies]

@Remi-Gau With #1508 merged, is this ready for review?

[Remi-Gau]

@Remi-Gau With #1508 merged, is this ready for review?

Yup

[sappelhoff]

xref #1560

[Remi-Gau]

• [x] Remove digitizer from this PR and let's solve it in 1560

[Remi-Gau]

test failures started appearing after this commit:

https://github.com/bids-standard/bids-specification/pull/1492/commits/53c4fd3797b45aab8f1b4193dd5196522baaefda

[effigies]

@Remi-Gau I don't know if we want to try to work on this in the nearish future, but it will need merge conflicts to be resolved before we go further.

[Remi-Gau]

will try to fix

[effigies]

Okay, I got tests passing, although this does seem to be failing to render a bunch of extensions. Can look into it.

Before I do, though,I wonder if what we instead want is mutually exclusive lists of valid groups (instead of lists of mutually exclusive groups):

extensions:
  - [.nii.gz, .json]
  - [.nii, .json]

...

extensions:
  - [.eeg, .vhdr, .vmrk, .json]
  - [.set, .fdt, .json]
  - [.edf, .json],
  - [.bdf, .json]

Sure, it's duplicative, but it's not as ambiguous as the current proposal, where you could have a .eeg and .fdt file next to each other with no complaints.

We could go further and start referencing extension sets:

extensionsets:
  brainvision:
    required: [.eeg],
    optional: [.vhdr, .vmrk],
  nifti:
    oneOf:
      - required: [.nii]
      - required: [.nii.gz]
  sidecar:
    optional: [.json]

extensions:
  - nifti
  - sidecar

extensions:
  - [edf, brainvision, eeglab, biosemi]
  - sidecar

# OR

extensions:
  - [nifti, sidecar]

extensions:
  - [edf, sidecar]
  - [brainvision, sidecar]
  - [eeglab, sidecar]
  - [biosemi, sidecar]

[Remi-Gau]

yeah I like the idea of the extension groups: may allow some refactoring

[effigies]

Inline extension groups (as in the first proposal) or explicit (one of the latter approaches)?

[Remi-Gau]

definitely explicit