Consider relaxing alphanumeric constraint on group path in well metadata

[imagejan]

The datasets/path field in the well metadata is currently constrained to alphanumeric characters only:

The path MUST contain only alphanumeric characters, MUST be case-sensitive, and MUST NOT be a duplicate of any other path in the images list.

However, some tools "in the wild" already allow using e.g. underscores (_) in the path field, see these issues:

• Disallow non-alphanumeric characters for suffix when creating new OME-Zarr groups fractal-analytics-platform/fractal-tasks-core#988
• Use alphanumeric suffix only m-albert/fractal-ome-zarr-hcs-stitching#31

Note that the multiscales specification doesn't currently impose such a constraint on the paths within a multiscales:

Each dictionary in "datasets" MUST contain the field "path", whose value contains the path to the array for this resolution relative to the current zarr group. The "path"s MUST be ordered from largest (i.e. highest resolution) to smallest.

How about relaxing the constraint to something like [A-Za-z0-9_] (i.e. regex \w which would simplify the regex in the json schema), or include even more commonly used characters?

(/cc @SabineReither)

[d-v-b]

the zarr v3 spec has a recommended set of characters for node names. Removing the normative language from the ome-zarr spec and just linking to the relevant section of the zarr v3 spec would probably simplify this matter.

[jluethi]

I'd be a big fan of relaxing this!
Within Fractal & ngio, we realised we were not following the spec in this area a few months ago (thanks to the validation of ome-zarr-models-py). It makes it really hard to have distinct names of images in wells when they are not just numbers though. Example: We have images like 0, 1, 2, 3 in our well. Now we create derived images like 0_illum_corr, 0_registered etc. And potentially combinations like 0_illum_corr_registered.

For now, we've decided that we accept being in violation of that part of the spec and will lobby that collections don't introduce such restrictions. Really useful to know the zarr v3 recommendations on it