No 2D or 3D consistency required in the sourcePos-detectorPos pair specifications
Also related to this, I think that nothing prevents from having for example only sourcePos3D and detectorPos2D (i.e. one is 2D and the other 3D) based on current notations, could that be an issue? That would make a new symbol requiring presence if another field is present even more necessary.
| `sourcePos2D` | * Source 2-D positions in `LengthUnit` | `[[<f>,...]]`*¹| | `sourcePos3D` | * Source 3-D positions in `LengthUnit` | `[[<f>,...]]`*¹| | `detectorPos2D` | * Detector 2-D positions in `LengthUnit` | `[[<f>,...]]`*²| | `detectorPos3D` | * Detector 3-D positions in `LengthUnit` | `[[<f>,...]]`*²| `*ⁿ` in the last column indicates that at least one of the subfields in the subgroup identified by `n` is required
Originally posted by @HanBnrd in #163
Hi.
I was recently checking the validator (https://github.com/BUNPC/pysnirf2/pull/54) and it seems that the constraint is already included in the validator. Currently, a file will be valid if either (1) sourcePos2D and detectorPos2D are present or (2) sourcePos3D and detectorPos3D are present.
I am wondering if we need to include a new symbol for that or if we should include a sentence to clarify that if sourcePos2D is present, then detectorPos2D should also be. in practice, i dont really expect to see file having detectorPos2D but not sourcePos2D or a weird combination of sourcePos2D and detectorPos3D, as it would not make any sense.
Overall, I am afraid that adding too many symbols might make the specification harder to read.
Hi @Edouard2laire! Yes this is correct, the validator is already checking this. And I saw you also created a PR to prevent some warnings that shouldn't happen, which is great!
The validator is not actually using symbols from the specs, and all the conditions need to be hard-coded. It would be good indeed to chat at the next meeting about what symbols we feel are required going forward.