@ndaelman @jrudz , and also @ladinesa @himanel1 @mscheidg We were talking about a full refactoring of the section `run` into `data`. The idea is to slowly build the metadata schema for `data` maintaining the three main sections: `System`, `Method` and `Calculation`. The goal is to have **`normalize()` specifically in each of the main sections** (with specific defined functions inside), and tackle normalization there (instead of in `SystemNormalizer`, `MethodNormalizer` and all the potential list of normalizers for Calculation). Furthermore, in this refactoring **we will heavily clean-up the sub-sections and quantities currently deprecated, unused or wrongly defined** in the metainfo. Lastly, **we should also refactor the plugin projects structure** (as Pavel pointed out and as we know from the EELSDB parser, it is a bit confusing). An open question here: how much of the current parsers we want to maintain? IMO: we should deprecate some of them, as they are actually empty or only populating very simple metadata. _____ As a dynamic (we can modify this at will): - [x] Start with `System` and slowly build the quantities needed to define it. - [x] After that and add extensive testing, go into `Method`. - [x] Finally, we take care of `Calculation`. This is the most heavily refactored one. Some simple rules on developing: - Always add typing for passing arguments to functions. - Be as general as possible. One of the current problems on `run` is that some quantities are a bit restrictive because of the packing that was done before; in other words, keep as much as possible a clean class structures (e.g., avoid the `Dos` or `BandStructure` current structure). - Add extensive descriptions in the normalize functions. Be verbose on which quantities are _minimal_ and which ones are _extra_. - Always ask for feedback on some unknown quantities.