RFC-4: re-sync the axes schema description with the RFC text - #584
Open
vboussot wants to merge 1 commit into
Open
RFC-4: re-sync the axes schema description with the RFC text#584vboussot wants to merge 1 commit into
vboussot wants to merge 1 commit into
Conversation
The `axes` description in orientation.yml still stated that orientation
"MUST be defined for all the axes of type space" and that "the type of
each orientation MUST be the same and the value MUST be unique".
Neither sentence matches the RFC text. The proposal makes orientation
OPTIONAL per spatial axis with no completeness requirement, defines a
single valid type ("anatomical") rather than a self-consistent one, and
constrains the values through the mutual exclusion rule on anatomical
axis pairs. The model itself already treats orientation as optional and
nullable, so only the prose was out of date.
The description now states the rules the RFC states: orientation is
optional on spatial axes, forbidden elsewhere, its type comes from the
vocabulary defined here, and two axes must not describe the same
anatomical axis. The `orientation` slot description also records that an
absent orientation and a null orientation are equivalent, per the
"Default Value" section.
Generated artifacts regenerated with `pixi run gen-all`; the JSON Schema
changes only in description strings and remains structurally identical.
Contributor
Automated Review URLs |
thewtex
approved these changes
Aug 20, 2026
lubianat
added
documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
axesslot description inrfc/4/orientation.ymlstates two rules that theRFC text does not:
Against the current
rfc/4/index.md:orientationis OPTIONAL and no completeness requirement is stated, so animage may orient only some of its spatial axes. A limb scan, for example, can
give a proximal/distal direction for one axis and leave the medio-lateral
axis undefined.
typeis defined,"anatomical". Requiring the declared types toagree with each other accepts metadata that uses a type the RFC does not
define.
axesMUST only have one of the set { left-to-right, right-to-left } or
{ anterior-to-posterior, posterior-to-anterior } or the remaining values."
The model structure already matches the RFC, since
orientationis optional andnullable. Only the description was out of date, and it propagates into
orientation.schema.json,orientation.py,orientation.tsandmarkdown/,where implementers read it as normative.
The
orientationslot description now also carries the equivalence added in254c1b2: an absent orientation and a
nullorientation mean the same thing, andwriters should omit the field rather than serialize
null.Generated with
pixi run gen-allinrfc/4, then theorphan: truefrontmatter was restored on the markdown pages, which
gen-markdowndoes not emit.Running the generators on an unmodified tree produces no other diff. The JSON
Schema changes only in
descriptionstrings, so no document changes validity.Found while aligning RFC 4 validation in ngff-zarr
(fideus-labs/ngff-zarr#613), where the removed sentences had been implemented
as constraints.