Allowed characters in labels/keys

[tsalo]

https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-fVf4sCpOHKesUvfb8Grc/edit?disco=AAAAB1zsEbg

Some labels that are desired to be used consist of concatenated abbreviations, and would be more readable with a separator character (e.g., "32k-fs-LR"). This restriction seems excessive.

One possibility is to actually allow dashes in values, while keeping them forbidden in keys. This can still be parsed consistently by splitting everything on underscores, and then splitting each of those on the first dash.

If this is unpalatable, perhaps another cross-platform-allowed filename character can be added to the set of allowed characters, such as '=' or '+'. These are not as easy to read as a dash, but at least gives people an option for cases that are otherwise difficult to resolve.

Original authors: Unknown

[tsalo]

This is related to https://github.com/bids-standard/bids-specification/issues/226 and #7.

[jbteves]

I disagree with allowing dashes only "sometimes" and thus giving them multiple possible meanings. It ultimately means more difficulty in writing parsers.

[yarikoptic]

I would like to bring this back to "agenda" and do make - and + allowed. We are not to give any semantic, but rather just to allow file names to be more readable. For implementing support, it should be quite trivial since it doesn't add any ambiguity to parsers: split on _ into entities + optionally a suffix, and then split entities on - to separate key from value. The only possible difficulty is may be for regex based parsing.