Topics discussed:

• The ticket asking for extensible format bindings is sitting with FHIR Infrastructure, and Graham wants a couple more months on it. The objection, as Lloyd framed it, is that there are two ways to describe an operation: OperationDefinition and profiling overlap, OperationDefinition doesn't have everything profiles have — additional bindings among them — and nobody wants to repeat all of profiling inside it. Nikolai's complaint comes from having written a validator: an extensible binding means nothing to him, so it validates nothing, and it still doesn't tell a client which formats are on offer. Both directions push an implementation into minting its own value set — the one that adds a format, and the one that only supports Parquet and needs to say so.
• How you hand a set of views to $export got settled by one argument. Nikolai had implemented local references only and wanted to cap the options at about three, because library, bundle, absolute URLs and inline bodies is too many ways to do one thing; John wanted it dead simple, found even the minimal Library container contrived, and said so. Then he made the point that decided it: you shouldn't have to write ViewDefinitions into a server before you can export from it, because it may well not give you permission to write them. So supply them inline — and Nikolai's answer was that Parameters is already a container, so you just repeat a view parameter with the resource inside, exactly as evaluate does. Not the ultimate solution, John said, but an escape hatch that always works, and a client script can fetch those bodies from a package or a library or anywhere else it likes.
• John made the point that it isn't only about formats. Asked for an example of a proprietary format, Nikolai's real case turned out not to be a format at all — their output is a table, or a database view, which might be an output type rather than a format, nobody's sure. John drew the line that matters: a file format you fetch over HTTP is one thing, but a Postgres URL, a JDBC connection or a Kafka topic is a whole protocol, with its own auth story and its own dialect, that the client has to understand.
• John raised Graham's older idea as an escape route: an operation that just answers can you execute this view, yes or no, with the parsing errors — because you will never describe every FHIRPath function you support in a capability statement. Nikolai pointed at the feature-query draft Gino and Graham had started for that exact reason, and suggested SQL on FHIR could be one of its first customers, asking for supported export formats as a feature. His motive is agents — he wants everything discoverable so an MCP server can make a plan — and John wasn't convinced that matters, since his own MCP server simply tells the model to write Spark SQL and hands back plain text.
• On a query resource, Nikolai argued around 90% of ANSI SQL works everywhere once the tables are flat, since the differences were mostly in unrolling nested data, which flattening removes; what's left is function names, so let one query carry several dialects the way data vendors already ship three. Arjun Sanyal was more cautious — they looked at defining an ANSI subset two years ago and he's still not confident, because the hard part is how an author knows what's in the subset while writing, and that will always be a bit heuristic. His preference is a simple resource with slots so it can be explicit and incremental, leaning on translators like Trino that have already worked out a portable subset in practice.