Skip to content

Conversation

@btbest
Copy link
Contributor

@btbest btbest commented Jan 16, 2026

I guess I had some comments about RFC-3 :)

@github-actions
Copy link
Contributor

github-actions bot commented Jan 16, 2026

Automated Review URLs

@btbest
Copy link
Contributor Author

btbest commented Jan 16, 2026

(Note for maintainer: please squash when merging)

@lubianat lubianat added the rfc-3 label Jan 16, 2026
@jni
Copy link
Contributor

jni commented Jan 23, 2026

Thanks for your comments @btbest!

I'm not 100% sure why case-insensitivity is important though? I would rather postpone that decision to a future spec change, if needed.

Definitely on board with unique names though...!

@btbest
Copy link
Contributor Author

btbest commented Jan 23, 2026

I'm not 100% sure why case-insensitivity is important though

I consider axis naming to be human, and humans don't think of "frequency", "Frequency" and "FREQUENCY" as different names.

On second thought, I think requiring lower case is probably bad: cost is potentially high (vendors might not like having to map their custom axes to a lower-case version for OME-Zarr) and benefit low (prettier metadata I guess? marginally simpler for implementations).

I still think requiring case-insensitive uniqueness is probably good: cost is zero (just add a suffix; you're using a non-standard axis name anyway) and benefit is moderate (developers won't have to decide whether "x" and "X" are different axes or the same; users should see more interoperability between tools). In particular, for the single-letter case, I consider it a benefit that this would forbid using lower- vs upper-case naming according to an existing convention for expressing transformations. If it turns out sensible to lift this restriction for RFC-5, it would be less painful to keep the restriction now and ease it when it makes sense, rather than the other way round.

Requiring case-sensitive uniqueness would also be fine. At least we'd have a standard. Developers can know what to expect and choose to be strict or permissive at their own risk.

@d-v-b
Copy link
Contributor

d-v-b commented Jan 23, 2026

I still think requiring case-insensitive uniqueness is probably good: cost is zero (just add a suffix; you're using a non-standard axis name anyway) and benefit is moderate (developers won't have to decide whether "x" and "X" are different axes or the same; users should see more interoperability between tools).

I think the spirit of RFC3 is to not tell people what to name their axes. And if developers want to aggregate across datasets that use mixed-case names like "X" and "x"`, those developers can make the names lowercase before doing the aggregation. So I second the idea to push this to a later spec change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants