I suggest to make the parameter "acquisition/gradient" (or "acquisition/drivefield/gradient") optional. There are devices, that do not have a gradient (e.g. MPS) or a highly inhomogeneous gradient field (e.g. single-sided devices), whose gradient field cannot be expressed easily. Furthermore, even for devices that have a homogeneous gradient field, it may be switched off and the whole FOV may be used as a measurement chamber as in an MPS.
For all the above cases, the gradient would have to be [0. 0. 0.], but this would not be true for e.g. single-sided devices.
Furthermore, I suggest to make "acquisition/drivefield/fieldOfView" optional. If the gradient is non-optional but Zero, then the FOV has an extension that might be vague. Therefore, it should not be noted.
Last, "acquisition/drivefield/fieldOfViewCenter" should be optional. As it is directly linked to "acquisition/drivefield/offsetField" and "acquisition/drivefield/gradient", it may only have a valid values if both gradient and offsetField are known.
I suggest to make the parameter "acquisition/gradient" (or "acquisition/drivefield/gradient") optional. There are devices, that do not have a gradient (e.g. MPS) or a highly inhomogeneous gradient field (e.g. single-sided devices), whose gradient field cannot be expressed easily. Furthermore, even for devices that have a homogeneous gradient field, it may be switched off and the whole FOV may be used as a measurement chamber as in an MPS. For all the above cases, the gradient would have to be [0. 0. 0.], but this would not be true for e.g. single-sided devices.
Furthermore, I suggest to make "acquisition/drivefield/fieldOfView" optional. If the gradient is non-optional but Zero, then the FOV has an extension that might be vague. Therefore, it should not be noted.
Last, "acquisition/drivefield/fieldOfViewCenter" should be optional. As it is directly linked to "acquisition/drivefield/offsetField" and "acquisition/drivefield/gradient", it may only have a valid values if both gradient and offsetField are known.