RFC5 - de-duplicate allowed ways to specify named coordinate system

[dstansby]

Currently in the scene metdata in RFC 5 there are two ways to specify a coordinate system with a name and no path. Either as

• 'output': ...
• 'output': {'name': ...}
• (or 'output': {'name': ..., 'path': null}).

This is a bit annoying for implementations because there are three different options to consider for metdata that has the same meaning.

If it's not too late, I'd like to propose choosing one of these options for describing a named coordinate system without a path. I would propose removing the option to simply have 'output': ... outside a JSON object, because 'output': {'name': ...} is a similar structure to when path is specified and therefore each case can share parsing code.

[dstansby]

Agh, even more confusion, in “coordinateTransformations” metadata it says:

MUST contain the field “output” (string)

Having different ways to specify input/output fields depending on where they live (scene or image metdata) makes validation much trickier, so I would advocate that the input/output fields should always be one of:

'output': {'name': ...}
'output': {'name': ..., 'path': ...}

no matter where they are, and plain 'name: ...` should not be allowed.

[will-moore]

To clarify, the "two ways" to specify a coordinateSystem (as an input or output of a coordinateTransformation) is:

"output": "myCoordinateSystem"

or

"output": {"name": "myCoordinateSystem"}

Do I understand correctly? Since all three of your options have name in them, which is confusing?

Currently, both of those options are allowed in https://raw.githubusercontent.com/jo-mueller/ngff-spec/refs/heads/update-RFC5/schemas/coordinate_transformations.schema (which also allows "output": {})
but https://raw.githubusercontent.com/jo-mueller/ngff-spec/refs/heads/update-RFC5/schemas/scene.schema only allows an object and 'name' is required: "output": {"name": "myCoordinateSystem"}

[dstansby]

Do I understand correctly? Since all three of your options have name in them, which is confusing?

Yes, sorry, I'll update my original post, thanks for the correct examples!

[will-moore]

Thanks, yes - I would agree that this proposal makes sense from a parsing/validation point of view.

I think the desire to allow simple "input": "s0" is for when we have datasets[n].coordinateTransformations[0].

Current RFC5:

          "datasets": [
            {
              "path": "0",
              "coordinateTransformations": [
                {
                  "type": "scale",
                  "scale": [0.1, 1.0, 0.5, 0.5, 0.5],
                  "input": "0",
                  "output": "intrinsic"
                }
              ]
            },

Proposed by this issue - bit more verbose and slightly strange that name from "input": {"name": "0"}, corresponds to the path at "path": "0"

          "datasets": [
            {
              "path": "0",
              "coordinateTransformations": [
                {
                  "type": "scale",
                  "scale": [0.1, 1.0, 0.5, 0.5, 0.5],
                  "input": {"name": "0"},
                  "output": {"name": "intrinsic"}
                }
              ]
            },

But for parsing/validation this is probably easier to have the same rules for all coordinateTransformations

[jo-mueller]

Yeah....I thought of this as well and I think this is a reasonable suggestion as it removes context-dependence and makes schemas much easier to write/read.

I'd only specify then that in the dataset transforms, I'd rather use the path field and not the name field:

"datasets": [
  {
    "path": "0",
    "coordinateTransformations": [
      {
        "type": "scale",
        "scale": [0.1, 1.0, 0.5, 0.5, 0.5],
        "input": {"path": "0"},
        "output": {"name": "intrinsic"}
      }
    ]
  },

...but that would probably require relaxing the constraint about which of name/path MUST be provided in which context 😬

[will-moore]

On the other hand, if I'd read the RFC spec carefully and hadn't tried to use an object instead of a string (and the schema at https://raw.githubusercontent.com/jo-mueller/ngff-spec/refs/heads/update-RFC5/schemas/coordinate_transformations.schema was to enforce that and not allow object), then I wouldn't have had so many issues at ome-zarr-models/ome-zarr-models-py#392

Now I have fixed that and @dstansby made some updates, may we're in a better place?

It does feel kinda late to make another change to what was agreed at the hackathon (without running it past everyone again)?