Affine transformations specification are not decoupled from their input and output spaces

[LucaMarconato]

I want to point out that affine transformations like

{ "type": "affine", "affine": [1, 2, 3, 4, 5, 6] }

require "input" and "output" to be specified to be parsed, otherwise it's not clear if it is for instance the affine transformation

1 2 3
4 5 6
0 0 1

or

1 2
3 4
5 6
0 1

This has two undesiderable implications:

• one argument for not having "coordinateSystems" inside "coordinateTransformations" in the storage is that one visualize a graph with coordinate systems as nodes and transformations as edges. But the affine transformation above implies that edges are not standalone objects and they can be instantiated only in the context of input and output nodes, since the same json storage would give two different transformations depending on input and output
• this makes implementation (still possible) but more laborious, because one can't decouple the instantiation of transformations and coordinate spaces. This holds especially for "sequence" transformations. In the following example all the functions have unambiguous dimensionality because they are constrained from the "input" and "output" specified by "sequence", but it is only possible to know this when constructing the composed transformation "top-down", not "bottom-up" by first constructing the inner transformations and then combining them into a sequence of transformations.

{
    "coordinateSystems": [
        { "name": "in", "axes": [ {"name": "i"}, {"name": "j"} ]},
        { "name": "out", "axes": [ {"name": "x"}, {"name": "y"} ]}
    ],
    "coordinateTransformations": [ 
        {
            "type": "sequence",
            "input": "in",
            "output": "out",
            "transformations": [
                { "type": "affine", "affine": [1, 2, 3, 4, 5, 6] }, // let's call this function f_1: "in" -> ...
                { "type": "affine", "affine": [1, 2, 3, 4, 5, 6] }, // f_2
                { "type": "affine", "affine": [1, 2, 3, 4, 5, 6] }, // f_3
                { "type": "affine", "affine": [1, 2, 3, 4, 5, 6] }, // f_4
                { "type": "affine", "affine": [1, 2, 3, 4, 5, 6] } // f_5: ... -> "out"
            ]
        }
    ]
}

My proposal it to be explicit about the shape of the affine transformation by adding inner parentheses. In the case above this could be solved by having [[1, 2, 3], [4, 5, 6]] and [[1, 2], [3, 4], [5, 6]] as value for affine.

Tagging @bogovicj

[LucaMarconato]

I have just noticed that the matrix MAY be specified as 2D array, so a solution is already supported, very good. I wonder if the 2D specification shouldn't instead be required.

[bogovicj]

Thanks @LucaMarconato Good point and nice argument to use 2D arrays rather than the flattened representation. I'll think about it a little more but will probably change the spec to move away from the flat arrays.