Materialise as a resource or just operations, three spec PRs reviewed, and the ballot notice going in — Jun 23, 2026

$viewdefinition-materialise — resource or operations?

Nikolai — argued for a resource: it has a lifecycle, an identity, metadata worth looking at, and a dependency graph — the same things that make Subscription a resource.

Gino — wary of the overhead of minting a new resource type, and leaned towards operations.

John closed off the third option

Hanging extensions on ViewDefinition or Library does not work, because those live on a different clock than a materialisation does.

So it really is resource versus operations, and Nikolai agreed to write both up side by side.

Either way, the fields are much the same

• What view it points at
• Status
• Table name
• Schema
• Optional freshness controls

Gino floated raising "infrastructure resource" as a category at FHIR-I, since Subscription would sit in it too.

PRs reviewed

• #369 — moves both async export operations off the old Bulk Data pattern onto the simplified FHIR async pattern. A status poll now answers with a 303 See Other pointing at the result, and the manifest itself is unchanged.
• #373 — fixes inconsistent naming
• #374 — constrains operation parameters to their profiles

Both were agreed to be uncontroversial.

A conformance test approved

For forEach nested through select inside forEachOrNull — worth having because an implementation can pass the unionAll version of that case and still get the select version wrong.