Create table of groups/dataset with the reason for their existence

[Neumann-A]

For discussions about adding or removing groups/datasets it would be good idea to have a table of each dataset/group which says why it was included and how the dimensions was choosen.

This also answer the question in the FAQ:

• Why was group/datasets XYZ in the MDF?

and also makes discussion and reasoning about fields in MDF easier and understandable for newcomers.

[hofmannmartin]

The why might be easier to express in the context of different use cases.

[tknopp]

+1 that you are volunteering to improve the specification. I will not retrospectively explain, why we did it this way.

[Neumann-A]

The why might be easier to express in the context of different use cases.

Maybe MDF should define the contex of those different use cases better and what groups are needed in those use cases. I am still strugling with the fact that /measurement/, /calibration/ and /reconstruction/ are all optional fields.
What kind of MDF file or use case do I have if I only have non-optional fields?
Does it even make sense to have those non-optional fields then?
what kind of file do I have if only the /calibration/ group is present?
Why do I need the group /acquisition/ if I only have the group /reconstruction/? (Thats actual a valid use case for MDF if I just want to exchange only reconstructed images) (a lot of questions for the FAQ #84 )
In my opinion MDF needs some kind of optional-if or required-if.
A lot of those optionals thus feel like a hack (we sometimes need the data and sometimes not and thus simply declared it all optional)
Maybe MDF should specify when a field is optional and when it is required.

I will not retrospectively explain, why we did it this way.

Believe me it will spare you a lot of unecessary discussions if you have proper reasoning for everything (or at least you are able to shorten it a lot). It also helps in convincing other people that MDF is a format with a good fundation and a stable baseline (so they might start using it).

[MandyA]

I don't get your point.

1. It is not intended to store measurement, calibration and reconstruction in one file. That is why the fields need to be optional. There are many reasons why this is better. Although, you can store them in one file if you like.
2. We have defined a lot paramters optional to be not too restrictive.
3. The non-optional fields are intended to define our data - at least the most crucial paramters. This is of course important for reconstructed data as well. If you have reconstructed data without any knowledge of the sequence, the scanner, etc. its wortheless ;)