The below would give one path from Xml to Yaml configuration. It would still require some big-bang changes, since some functionality simply cannot be supported in the new system, but it should make the transition a lot easier. Since this woudl take a lot of coding, we had better agree on goals and process before we start.

Apart from the transition proper, are there proposals to change or add functionality to the goal?

Transition path

1- Write function to read XML configuration file and output equivalent yaml file. It does not have to be perfect, as it only for one-off use and remainig errors can be fixed by hand.
2- Write joint HardwareObject class with both old and new functionalities
3- Transform all config files, switch over to new class, and fix all problems
4- Mark undesired functionality as deprecated and remove uses of it
5- Remove deprecated functionality and tighten up restraints on the HardwareObjects class

New HardwareObject class

The new class should have the internals and functionality of the yaml-configured class, with the old functionality supported as far as possible.

Yaml-type functionality

1- All properties and contained objects to be accessed by Python obj.attr syntax # NB Properties behave that way in XML-configured classes already.
2- Requirement for all properties and roles to be pre-defined in the class code to be temporarily relaxed, and replaced with warnings.
3- name property
4- name equal to role name in containing class
5- properties all_objects_by_role, all_roles, and procedures
6- replace_object function
7- Placeholders for init() and _init() functions

XML-type functionality

All XML functionality should eventually be deprecated. Meanwhile:

Full support

1- Object behaves as a list of contained objects (obj[i])
2- get_property and get_properties functions
3- get_object_by_role function # NB currently searches recursively for matching role in contained classes. This seems weird and unnecessary, but we can support it pending deprecation.

Unnecessary - can be removed

1- set_property function # Used only in loading machinery
3- add_object, add_reference, resolve_references, and set_path functions # Used only in loading machinery
2- get_roles function (easily replaced by all_roles)
4- get_xml_path
5- set_name

Unsupported - problems

Any function relying of the 'name' (== filename) of xml-configured classes cannot be supported

1- Object behaves as a dictionary of filename:contained_object
2- get_objects, has_object , and objects_names functions # rely on fileneames
3- name() function # replaced by property
4- user_file_directory and set_user_file_directory # Check - what does this do anyway?
5- Having contained objects as attributes might in theory cause name clashes with pre-existing attribtues This is unlikely to be a big problem in practice.

mxcube / mxcubecore

Transition from Xml to Yaml configuration #871