Add initial compatibility matrix

[joshmoore]

This is largely a PR to think out loud about possible representations. e.g. this might should be split up by version. Thoughts welcome.

http://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/joshmoore/ngff/spec-compatibility/latest/index.bs

[will-moore]

Do we also want to include details such as support for labels, HCS etc?

[joshmoore]

If we can balance that with readability and maintainability, 👍 (To some extent, it'd be nice if ome_zarr_test_suite would generate that matrix, but shrugs)

[joshmoore]

@sbesson has started working on a feature-level matrix for this. It's likely "too much" for the index.bs file itself and may end up in its own repo.

[sbesson]

To complement #59 (comment), the current version of the compatibility matrix I am working against is:

• features / version as the first two columns so that each row is a combination of feature + version
• samples as the third column
• various implementations (ome-zarr-py, ZarrReader, bioformats2raw) as follow-up columns

A minimal example of the current representation is:

Features	Version	Samples	ome-cli-zarr
multiscales	0.1	link	read
multiscales	0.2	link	read
multiscales	0.3	link	read/write
axes 2D-5D	0.3	TBD	read/write

I opted for putting features/specifications as rows as this is likely the dimension which will expand the most rapidly and this is more amenable to scrolling down.

Tested captured a specification as a row rather than a feature. It works when a new specification is added from scratch e.g. labels but I found this representation to be limiting when dealing with feature is added to an existing specification e.g. axes in multiscales 0.3 or upcoming transformations in multiscales 0.4.

For the samples column, still pondering on whether the samples should be maintained as a separate table with every row describing a sample dataset with metadata and the associated features/versions.

Feedback/suggestions welcome

[joshmoore]

Closing. This is likely something we will want to resurrect at some point in the future, perhaps as early as RFC-3, e.g., which clients support more than just xyzct