What happens if both /nirs(i)/data(j)/measurementLists and /nirs(i)/data(j)/measurementList are both present

[rob-luke]

As asked in the in person meeting

[rob-luke]

As an end user, if both fields are present they should contain the same data and you could load either.

[samuelpowell]

We should surely enforce that only one is present?

[dboas]

I like the idea of having the validator enforce that only one be present. BUT This could be annoying for the user, many of whom will not be skilled enough to fix their snirf file if it had both. But I could go either way. Who has strong feelings one way or the other?

…

Sent from my iPhone On Sep 14, 2024, at 4:10 AM, Sam Powell ***@***.***> wrote:  We should surely enforce that only one is present? — Reply to this email directly, view it on GitHub<#155 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHFCP5F7FNKDR77SKHYQOY3ZWPVQTAVCNFSM6AAAAABOFIKXZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJQHEYDKMRUGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[samuelpowell]

@dboas if we specify that only one should be present, then compliant software will never write both to a file, and hence the user will never encounter this problem, right?

[dboas]

Your logic convinces me Sam 😊 From: Sam Powell ***@***.***> Date: Thursday, September 19, 2024 at 4:18 AM To: fNIRS/snirf ***@***.***> Cc: Boas, David ***@***.***>, Mention ***@***.***> Subject: Re: [fNIRS/snirf] What happens if both /nirs(i)/data(j)/measurementLists and /nirs(i)/data(j)/measurementList are both present (Issue #155) @dboas<https://github.com/dboas> if we specify that only one should be present, then compliant software will never write both to a file, and hence the user will never encounter this problem, right? — Reply to this email directly, view it on GitHub<#155 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHFCP5GOCCJS3HMFDKI4FZLZXKCGBAVCNFSM6AAAAABOFIKXZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRQGMYDENZRGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sstucker]

Because the above conclusion did not make it into writing in the specification, I did not write the validator this way. Will support whatever you decide and put into the spec itself.

[dboas]

@samuelpowell
how do you suggest the specification language indicate that only one be present?
Presently they both indicate that they are required if the other is not present.
I am not sure how we would want to write it so that the validator can parse it properly.

@sstucker , given you just worked on updating the validator to handle this one of the two must be present condition, do you have an idea of what language we could use to make it clear that only one should be present so that it is clear to the human, and clear to the validator?

[samuelpowell]

Presently they both indicate that they are required if the other is not present.

It might be a touch enigmatic but surely this is sufficient insofar as it is logically consistent and I assume parseable?

[dboas]

Sam is right. The validator could handle this and throw an error if both are present. We could clarify the language in the spec to indicate to the human that we mean that only one can be present.
@sstucker , could we change
Presence: required if measurementLists is not present
to be
Presence: required if measurementLists is not present, but should not be present if measurementLists is present.
without messing up the validator?

Of course we would do similar for the measurementLists Presence requirement.

[samuelpowell]

@dboas @sstucker for the purpose of simplifying parsing, perhaps the human readable part could be parenthesised, e.g.,

Presence: required if measurementLists is not present (but should not be present if measurementLists is present)

[dboas]

@samuelpowell and @sstucker ,
@sreekanthkura7 pointed out to me that he is pretty sure that Stephen's validator is using the coding in the SNIRF data format summary. He needs to verify this and will confirm for us here. But Stephen could also verify if he beats Sreekanth to it.

If this is true, Sreekanth and I were thinking that we can code this language of one or the other being present, but NOT both at the same time, but using '*abc' where 'abc' is some letter as opposed to what is presently defined as '*n' where n is a number is this says that atleast oneof the sub-fields must be present must be present. We could instead be mores distinction and instead use '**n' or '**abc' or '@n'

Any thoughts on this?

[samuelpowell]

I think this is true @dboas and indeed an exclusive OR operator such as you propose makes sense. Maybe ^ is a good option given it is a (bitwise) XOR operator in C etc.

[dboas]

I like this idea.
@sreekanthkura7 is meeting with the maintainers next Monday. He will review with them and then likely implement this and move forward on implementing the validator.