Chris Barnes

A major use case for sharing transformations between multiscale datasets is when you have an image volume and labels for that volume. You'd usually define the image multiscale first, with...

I agree that if we're going to use UNIXy conventions for ancestor groups `../../`, we should try to avoid using UNIXy conventions for things other than their UNIXy meaning (i.e....

OME-Zarr delegates this decision to UDUNITS-2, which [does not include deca*](https://docs.unidata.ucar.edu/udunits/current/udunits2-prefixes.xml). For the sake of simplicity/ standardisation, it would be nice to avoid taking ownership of any more lists. If...

Adding `class="data"` or `class="complex data"` to the `table` element will add some or many lines respectively. This is, of course, not in the [bikeshed docs](https://speced.github.io/bikeshed/) 🙄

> If people are writing down input/output, I think it's reasonable to make sure that the values are consistent Yes, that's fair. In that case, I'd err on the side...

Keeping `latest` around seems like a feature, so that people can link to the current finished, released, accepted version of the spec in perpetuity. So how about we have a...

I note that Josh has just pushed https://github.com/ome/ngff-spec. I imagine the idea is to develop on the `main` branch there, then branch for every new version; fixes which pertain to...

Neither banning nor allowing extra keys solves backwards compatibility in the general case, they just have different trade-offs. Banning additional keys breaks backwards compatibility when a key is removed from...

It would be a bit painful, but the longer it's left, the more painful it will be as more inconsistent data is being written. There are also some non-camel fields...

Good deserialisation frameworks allow for aliases, so they can continue using the language-appropriate convention internally, be flexible about what they parse, and write the correct new convention. IMO having the...