Topics discussed:

• Bashir Sadjad objected to the Parquet on FHIR draft's non-goals section: it listed query writer experience as out of scope, but a query that fails because a field is missing isn't a matter of taste. Arjun Sanyal agreed the error condition is a top-level requirement — what he'd meant to rule out was massaging the schema so queries read more nicely to non-experts, which he argued is SQL on FHIR's job, not Parquet on FHIR's. Bashir also wanted the plain case in scope: someone who wants a Parquet file out of a FHIR system and their own SQL over it, with no ViewDefinition anywhere.
• John Grimes explained why the draft splits a comprehensive schema from a focus schema. Comprehensive serves the raw-SQL user, but it forces whatever builds it to know all of FHIR and to take a haircut on capability — recursion has to stop somewhere — while focus has no such limit and zero loss, and is what a runner sits on. The point is that converting between the two is cheap, so the split costs nothing compared with tools inventing incompatible schemas. Bashir thought the draft's recursion depth of six was huge; John said Pathling uses three, that it should be hard-coded rather than a parameter, and that he doesn't know the right number.
• Nikolai listed what an API actually has to do: discovery through the capability statement, asynchronous bulk export, synchronous evaluation for debugging a view, authoring — pointing a ViewDefinition builder at any runner, the way Brian's FHIRPath lab switches engines — and a black box that takes a set of views plus queries and hands back results. The last one is the one he cares about: hospitals shouldn't have to know there's a bucket to download from before they can report a metric.
• Brian Kaney walked through the other end of the life cycle: publishing views as FHIR packages through the IG publisher, identifying them by canonical URL and version rather than the logical id a server happens to mint, and pulling a whole set down with CRMI's $package on an ImplementationGuide. He'd also drafted an $execute operation following CRMI's knowledge-artifact semantics, so it looks like the CQL and measure operations people already know. Nikolai said run was the better name, since the thing is called a runner; the Binary in Brian's draft was only there because ViewDefinition isn't a real FHIR resource yet and the tooling complains.
• Steve Munini described running views on top of $export, which needed only one extra viewDefinition parameter to inherit since and type. What he'd found users want is the job now, on a cron, or continuously — and continuous needs an as-of date to mean anything. Nikolai pointed at the part nobody has solved: once the result is a pile of files in a bucket, updates and deletes have nowhere to go, so you can't just keep appending pages of new data.