camelCase vs snake_case

[normanrz]

I know this has been discussed in the past: #54 #70 #109. But I find the inconsitency quite annoying that Zarr uses snake_case and OME-Zarr uses camelCase. In the past this has not been a huge issue, because the Zarr metadata was in .zarray and .zgroup and the OME-Zarr metadata was in .zattrs. But with Zarr 3/OME-Zarr 0.5 both are in the same file and now it just feels messy.

I would advocate switching to snake_case for OME-Zarr. I know this might not be a high priority and doesn't add any features, but would be a good cleanup before 1.0.

[clbarnes]

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 lurking too - in the plate specification, there's maximumfieldcount, starttime, endtime.

[will-moore]

I was originally in favour of snake_case, but having been working with coordinateTransformations for a while, and now coordinateSystems etc, I am fine with camelCase. I don't feel any conflict with Zarr's snake_case because I'm not editing core zarr metadata.

I'm OK to go with this if everyone else is keen, but it feels like the massive breaking change of renaming camelCase fields is maybe not really worth it?

[clbarnes]

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 mix of different casings might bounce first-time readers as in some cases it's a symptom of a project which wasn't well thought out or burdened with a lot legacy weight.

[joshmoore]

A few thoughts from my side:

• This issue has the potential for a lot of bike shedding. If so, I will close it and ask for an RFC. :smile:
• My inclination is to only attempt this in a version in which there are significant other breaking changes.
• Though I don't fundamentally disagree with the point that it can confuse people, I think the NGFF community's decision will have to be independent of the Zarr's community as so I don't personally rank it as indicative of a difference of opinion (between the two communities) or baggage.

[clbarnes]

Even if we don't prioritise consistency with zarr, we should at least aim for internal consistency, which would require breaking changes anyway (e.g. image-label). Given that, IMO the best way to avoid bikeshedding is to remove the necessity of making a decision ourselves as in the black philosophy - by delegating the decision to the zarr ecosystem we live within. It's the only route which doesn't require making any value judgements about different casings.

[jo-mueller]

I'd be mildly in flavor for snake_case, but that's just my Python hat speaking. Could be added to the backlog of 0.6dev3?

[joshmoore]

I'd target this decision more for the types of changes in RFC-6.

[mkitti]

I lean heavily towards snake_case at this point. Zarr v3 uses snake_case in many cases and that is not going to change.

• zarr_format
• node_type
• data_type
• chunk_grid
• chunk_key_encoding
• fill_value
• dimension_names
• storage_transformers
• chunk_shape

The main case for me is consistency, and we should be consistent with Zarr v3. As Chris points out above, we are not even internally consistent within OME-Zarr.

I would deprecate all uses of camelCase and lowercase but still require that compliant implementations can read the old camelCase and lowercase keys through the transition. Start the transition ASAP before 1.0.