Topics discussed:

• The open question is whether $viewdefinition-materialise becomes a resource or stays a set of 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 was 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, and optional freshness controls. Gino floated raising "infrastructure resource" as a category at FHIR-I, since Subscription would sit in it too.
• PR #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 and #374 constrains operation parameters to their profiles; both were agreed to be uncontroversial.
• A conformance test was 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.