How to seperate attributes and entries in scan_info ?

If one looks a scan_info in the moment it is not obvious what are entries and what are attributes (in the sense of Nexus/h5). Here is an example from the instruments section in scan_info:

{'instrument': {'NX_class': 'NXinstrument',
                'transfocator_simulator': {'L1': False,
                                           'L2': True,
                                           'L3': False,
                                           'L4': True,
                                           'L5': False,
                                           'L6': True,
                                           'L7': False,
                                           'L8': True,
                                           'NX_class': 'NXcollection',
                                           'P0': True}}}

in this case only the fields 'NX_class' are be considered as attributes, all the others as entries. While working on meta-data related things with @denolf it became clear that we can not stick to the current logic ('NX_class' as key --> attribute) as there are also other keys that have to be used as attributes.

With the recent changes in silx there is now a standard how to transport h5-datasets and 5h-attribues in the same python dict. I would like to use this standard in bliss as well. Here is an example for an attenuator (from the merge-request !2054 (closed), that is currently somehow blocked):

The minimal set of meta-data fields would be

MyAttenuator
├── thickness: 123
└── type: something

to make it Nexus complaint there also have to be the propper attributes which would be in this case

MyAttenuator
├── @NX_class: NXattenuator
├── thickness: 123
│   └── @units: um
└── type: something

following what is done in silx there are two ways to transport this in a python dict:

attributes are identified by @ in the key

{'MyAttenuator': {'thickness': 123,
                  'thickness@units': 'um',
                  'type': 'something'},
 'MyAttenuator@NX_class': 'NXattenuator'}

attributes are identified by using tuples as keys

{'MyAttenuator': {'thickness': 123,
                  'type': 'something',
                  ('thickness', 'units'): 'um'},
 ('MyAttenuator', 'NX_class'): 'NXattenuator'}

as we have already a role for @ in beacon I would like to use the second proposal which translates easily into yaml 1.2 (example 2.11.) using ruamel:

MyAttenuator:
  thickness: 123
  ? - thickness
    - units
  : um
  type: something
? - MyAttenuator
  - NX_class
: NXattenuator

or more compact

MyAttenuator: 
   thickness: 123 
   ? [thickness, units]  
   : um 
   type: something 
 ? [MyAttenuator, NX_class] 
 : NXattenuator

like that the meta-data related information could easily be kept in the config. Also bliss.common.utils.dicttoh5 could be removed and the parsing of scan_info gets more simple (isinstance(key,str) --> entry, isinstance(key,tuple) --> attribute).

What do you think @denolf, @matias.guijarro and @pancino ?

To me it looks like once we decide to go for ruamel this is a real option. sticking to pyyaml instead would give something less nice (just for completeness):

MyAttenuator:
  thickness: 123
  type: something
  ? !!python/tuple
  - thickness
  - units
  : um
? !!python/tuple
- MyAttenuator
- NX_class
: NXattenuator