The second sitting of Milestone 1 — Delta, Iceberg and the shareable-profile question again — Aug 28, 2024

Table formats — what Delta and Iceberg add on top of Parquet

Delta, Iceberg and Hudi are all a metadata layer wrapped around Parquet — Delta adds a transaction log, so you can update a table repeatedly and time-travel back to earlier versions, and it supports merge semantics.

The catch: the transactionality is per table; there are no multi-table transactions. The whole category sits in the gap between dumping files on storage and running a relational database.

Tagging structure carried over from the first sitting

Reserved tags now align with profiles — shareable, tabular, experimental — so each tag links to the profile it refers to. The FHIRPath subset moved into the shareable profile, and the test report groups results under those headings, with the boundary functions and join under experimental as things intended for the required subset later but not part of the normative release.

Why the FHIRPath subset isn't stated in the ViewDefinition part of the spec

It mirrors FHIR's own model. Base Observation is generic and permissive; to actually use it you profile it down to a sensible set of codes and values, which keeps the base stable and lets you tailor per use case.

Likewise here: any FHIRPath is fine in a ViewDefinition, but the subset is what makes a view portable to another implementation, so it belongs in the profile that says so.

The metadata-fields PR — closed, not merged

Stripping the metadata fields the profile copies from ancestor resources. The duplication exists because ViewDefinition is a logical model, not a real FHIR resource; if it is ever promoted, those fields should arrive by inheritance instead.

Also noted: the functional model page is orphaned, with nothing in the spec linking to it.

FHIR Shorthand conversion for the example ViewDefinitions

Around ten ViewDefinition examples for common resources still need converting to FHIR Shorthand. The upside: the IG build validates them against the ViewDefinition logical model as part of the build, so mistakes like a string where a code belongs get caught.