Topics discussed:

• The case for multi-resource views: a medication view fed from both MedicationStatement and MedicationRequest, or a person table drawn from Patient, RelatedPerson and Practitioner. The crux was insisting this is a UNION, not a JOIN — the view names the resource types it covers and each gets its own select branch; nothing is matched against anything. Logically it is one view, and splitting it into several ViewDefinitions with the same output columns loses that intent and leaves the combining step outside the spec, with no way to say that these three views feed one table.
• The case against, from someone who has implemented it: joining is complicated, there are many kinds of it, and this is generic functionality every downstream tool already has — the spec's job is to handle the FHIR part and emit something simple enough that any tooling can pick it up. If you have the machinery to union inside a ViewDefinition you have it outside one too, so implement unions of views first and find out what's involved. And it doesn't get you there anyway: when the branches don't share a schema — the date is on Statement but not on Dispense — you build machinery outside the spec regardless. OMOP also runs the other way, one Observation belonging in several OMOP tables. Left as a likely V2 feature, with the suggestion that someone actually attempt the OMOP transform on V1 to find out what is genuinely missing.
• The expected rows in the tests are JSON objects, and JSON object keys aren't ordered — most parsers don't preserve them — so the current format can't honestly assert a column order. Options: arrays of arrays, or state the correct order once and let each test framework decide whether to check it. Against relaxing: implementations need ordering to union results, and CSV consumers address columns by index. For relaxing: if every test has to preserve order, it's harder for someone whose runner only ever emits JSON, and the tests are supposed to help people implement. Someone also asked whether the ANSI SQL standard has already settled this, since the audience is SQL people. Taken to Zulip, possibly to a poll.
• The spec says a where expression's result must be Boolean — so what happens when the field isn't there at all, deceasedBoolean = true against a patient with no deceasedBoolean? The reference implementation throws. Three options: strict error, treat the empty result as false and drop the row, or truthiness. The argument against erroring is that the author may well know the field is always populated, and forcing everyone to write defensive FHIRPath to satisfy the engine only adds syntax — a warning would do. It was also noted this is a runtime requirement, not a compile-time one. The leaning was that the row simply doesn't appear, no error, on the grounds that databases want a Boolean here.
• Writing tests surfaced two gaps. Array indexing is missing from the FHIRPath subset although the tests already use it — treated as a spec bug, since indexing into an array sits at the same level as addressing an element by name. And getResourceKey/getReferenceKey are awkward to test: you want to assert the two agree without asserting the value, which is an implementation detail. The leaning was a self-referencing resource, so plain FHIRPath can compare them, rather than inventing test syntax — which is not a trivial addition, since it would mean carrying multiple resource types in the test data.