It seems that the validator does not throw warning when slice timing are different across runs.

Modified ds114 from the bids examples as follow:

• added a ds114/sub-01/ses-test/func/sub-01_ses-test_task-fingerfootlips_bold.json with

{
    "EchoTime": 0.05,
    "FlipAngle": 90,
    "RepetitionTime": 2.5,
    "SliceTiming": [
        0.0,
        1.0,
        2.0
    ],
    "TaskName": "finger_foot_lips"
}

to be very different from the values in the root JSON:

{
    "EchoTime": 0.05,
    "FlipAngle": 90,
    "RepetitionTime": 2.5,
    "SliceTiming": [
        0.0,
        1.2499999999999998,
        0.08333333333333333,
        1.333333333333333,
        0.16666666666666666,
        1.4166666666666663,
        0.25,
        1.4999999999999996,
        0.3333333333333333,
        1.5833333333333328,
        0.41666666666666663,
        1.666666666666666,
        0.5,
        1.7499999999999993,
        0.5833333333333333,
        1.8333333333333326,
        0.6666666666666666,
        1.9166666666666659,
        0.75,
        1.9999999999999991,
        0.8333333333333333,
        2.083333333333332,
        0.9166666666666666,
        2.1666666666666656,
        1.0,
        2.249999999999999,
        1.0833333333333333,
        2.333333333333332,
        1.1666666666666665,
        2.416666666666665
    ],
    "TaskName": "finger_foot_lips"
}

Running this

 bids-validator bids-validator/tests/data/bids-examples/ds114 --config.ignore=99 --ignoreNiftiHeaders

gives me code 38 warning:

1: [WARN] Not all subjects contain the same files. Each subject should contain the same number of files with the same naming unless some files are known to be missing. (code: 38 - INCONSISTENT_SUBJECTS)

But I think I would have expected a warning code 39: 'INCONSISTENT_PARAMETERS'

Spotted by @JacMatu in https://github.com/cpp-lln-lab/bidspm/issues/967

That would be a very expensive check. The normal check that should catch this is that the length of the SliceTiming array should match the number of slices in the third axis (code 87: SLICETIMING_ELEMENTS), but that won't work on examples where we do not inspect the missing NIfTI headers.

yeah the cost of such a check was my first thought as well.

I'd say that unless we one day decide to implement validation with very different "depth" levels this is probably not gonna happen any time soon.

I'd say that we should at least leave the issue open, so that people know about it but that this is not on the implementation agenda for now.

Okay. Hopefully the new title and labels will make it findable and the reason nobody's working on it obvious. I think a better approach might be to create a single issue with "deep validation" tasks.

are any other of those "deep validation" issues around?

I can't recall off the top of my head, but if we start an issue, there's at least a clear place to put them. Or maybe we could even do a mega-issue:

Issue types

Surface

• [x] File naming

Shallow

• [x] Sidecar validation
• [x] Header-sidecar consistency

Deep

• [ ] Data contents

Abyssal

• [ ] Parameter consistency

This would take even more effort, though...