Sounds like we could make the reference attribute a list, I.e. reference="moving,label"

Jim, do you know why it was chosen for the first place to define the transform-transformable 1-N relationship in the transform?

It's unusual in XML (you should store simple keys in an attribute instead of some text that you have to parse), unusual in Slicer (parent transform node ID is stored in the transformable node, not vice versa). Adding an "attribute list" requires additional (although simple) parsing, consistency checks (warn the user if the same transformable node is listed as reference in multiple transforms), and makes it more difficult to add attributes to the relationship (e.g., if we want to specify an additional reference node for resampling then the "attribute list" could become quite complicated: <transform1 reference="moving1,resample:fixed;moving2,resample:fixed" vs. <moving1 transform="transform1" resample="fixed").

I think it would be better to deprecate definition of reference in the transform (allow it, but print a warning) and move the reference attribute to the transformable element.

The XML for command line modules is independent of Slicer concepts. There is not meant to be a one to one mapping of parameters and node types. Rather the concepts in the XML were meant to be general enough to be used in a variety of application harnesses.

I don't understand your first example of how complicated things could be. I don't foresee that.

I also don't think the "resample" attribute is the right concept.

You are correct to point out that we are not properly representing transformations in the CLI or even within Slicer. Transformations should explicitly reference what coordinate frames they map between. We attempted to do that with the current reference attribute. But it is really only halfway.

Then there is a second concept that you are trying to capture which is how the transformation should be used, I.e. The transformation should be "applied" to a given set of volumes. Again, this is a bit implicit in how we use the current reference attribute.

We did not factor into the CLI design the one to many, many to one aspects. We should revisit this. I never really liked how Slicer approached it at the node level either.

I would also like to repurpose the reference attribute to be used to tract provenance (so we can tag an output as being derived from a (?) specific input.

It is a good idea to revisit how we model transformations in CLIs, how we indicate the coordinate frames they map between, and how indicate which data should be managed by that transformation.