Should `dataInput` of `ClusterTree` be named "taxa"?

[MordorianGuy]

https://github.com/CompEvol/beast2/blob/67dd40a56650490702f2616b56bcfc27a0b6e6fa/src/beast/base/evolution/tree/ClusterTree.java#L68

The "taxa" xml-input name confounds my user's eye since it takes Alignment objects. Should it be renamed to "data" or "alignment"?

P.S. One more point. By default, the BEAUti assigns the first partition as the input. It is not apparent and not expected behaviour. Maybe the unfiltered alignment would be better?

[rbouckaert]

@MordorianGuy you are right that data or alignment makes more sense -- however, for reasons of backward compatibility, it is not easy to change this. All BEAST v2.7.x compatible XML should still run on BEAST v2.7.y for y>x. There are a few more inconsistencies in Input names (e.g. start as capital in IsLabeledNewick in TreeParser, and these should be the same names: BeautiSubTemplate.suppressInputs BeautiConfig.suppressPlugins)

It can be achieved by adding an extra Input and deprecating the old one, or creating a new type of input that is known by more than one name (taxa and data for example), or perhaps some other mechanism for redirecting the Input values to the original Input. Not sure what the optimal solution is to remain both backward compatible and allow introduction of input name changes.

[MordorianGuy]

@MordorianGuy you are right that data or alignment makes more sense -- however, for reasons of backward compatibility, it is not easy to change this. All BEAST v2.7.x compatible XML should still run on BEAST v2.7.y for y>x. There are a few more inconsistencies in Input names (e.g. start as capital in IsLabeledNewick in TreeParser, and these should be the same names: BeautiSubTemplate.suppressInputs BeautiConfig.suppressPlugins)

It can be achieved by adding an extra Input and deprecating the old one, or creating a new type of input that is known by more than one name (taxa and data for example), or perhaps some other mechanism for redirecting the Input values to the original Input. Not sure what the optimal solution is to remain both backward compatible and allow introduction of input name changes.

Thank you for your answer!

Yes, you are right: the backward compatibility is hard. I have thought more about something like regex switches between versions applying to parsed XML based on the version attribute of the beast tag. If we definitely know what we changed between specific versions, we may apply these changes consequently to adjust an old XML to new standards. At least if we talk about simple renaming.