Topics discussed:

• The Parquet on FHIR draft listed query portability and query-writer experience as non-goals. Bashir objected: a query erroring because a field is absent isn't an ergonomics nicety, it's a top-level requirement. The distinction drawn in reply — making a schema pleasant to write queries against is SQL on FHIR's job, but not being able to know in advance whether your query will blow up is a different class of problem entirely.
• Underneath that sits a scope question: are there two implementation patterns here? One is Parquet as the substrate under a ViewDefinition runner. The other is someone who wants nothing to do with ViewDefinitions, just Parquet out of a FHIR system that they can point raw SQL at. The second was argued to be in scope and drew agreement, and the next draft is meant to make both patterns and their goals explicit.
• John's framing: the comprehensive schema serves the raw-SQL user, but its builder needs full knowledge of the FHIR spec and has to take a haircut on capability, since recursion must stop somewhere. The focused schema has no such limit and can be truly zero-loss, and suits runners. The important part is that the two are compatible and cheap to convert between — unlike the incompatible schemas different tools have each invented. Recursion depth stayed open: the draft said six, Pathling uses three, and six was called huge.
• Nikolai laid out API use cases: discovery via CapabilityStatement, bulk export, a synchronous real-time mode for debugging, and a black-box job where you post ViewDefinitions plus queries and get results back without caring what happened in between. The authoring case has a concrete payoff — a standard API would let the ViewDefinition builder point at any runner, the way FHIRPath Lab switches engines. He also flagged that bulk export kicks off via GET, which he argued breaks HTTP semantics for a state-changing operation; left for next time.
• Brian showed the publishing side: ViewDefinitions in a FHIR package via the IG publisher, marked as definitions rather than examples so tooling treats them as knowledge artifacts, distributed as npm tarballs through the FHIR package API, and referenced by canonical URL and version — because a logical ID is whatever that one server chose to mint and refers to nothing universally. $package on the ImplementationGuide pulls the whole set. His $execute sketch had to declare its ViewDefinition parameter as Binary, because ViewDefinition still isn't a resource and the tooling complains otherwise.