SCHEMA: Update existence checks to consider empty lists

[effigies]

Fixes two issues found in real datasets:

1. stim_file columns with all n/a. This is already handled in a duplicated check: Guessing this got rebased out before pushing.

2. IntendedFor fields with an empty array ([]) as a value. Other reference checks suffer the same potential bug, so fixed at the same time.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.93%. Comparing base (bd08602) to head (f11fb28).
Report is 43 commits behind head on master.

❗ Current head f11fb28 differs from pull request most recent head 9467f62. Consider uploading reports for the commit 9467f62 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1747   +/-   ##
=======================================
  Coverage   87.93%   87.93%           
=======================================
  Files          16       16           
  Lines        1351     1351           
=======================================
  Hits         1188     1188           
  Misses        163      163           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yarikoptic]

but is it an issue really?
do we have some common requirement on why no empty lists or no columns full of n/a?

if not -- then I don't see why this particular attributes/columns are special.

[effigies]

These are responses to existing datasets. We can warn on empty lists if desired, but we shouldn't raise these errors.

[effigies]

From in-person convo, special-casing empty lists isn't great. The problem here is that the value could be either a string or a list of strings. exists() handles that fine, but exists() == length() would fail on non-empty strings.

One way to do this is to update the check to:

exists(sidecar.IntendedFor, "bids-uri") + exists(sidecar.IntendedFor, "subject")
== length(type(sidecar.IntendedFor) == "string" && 1 || length(sidecar.IntendedFor))

@rwblair Any opinions?

[rwblair]

Should the RHS of that equality be wrapped in a length? Otherwise it's good. It is complicated enough that we should probably have some unit tests to make sure it works how we think it does.

Simple but more verbose option would be to have multiple rules based on type of IntendedFor. One for it being a string and another on it being a list.

[effigies]

You're right, should drop that outer length

Maybe two rules is best. Was trying to avoid it, but it would be more readable IMO.