Topics discussed:

• Brian Kaney's case against minting a query resource: the complaint about base64 assumes someone will edit SQL embedded in JSON, and nobody will. You can't even put newlines in JSON, so you're escaping either way, and a real query he pulled up runs to about a thousand columns on one line. His alternative is to keep first-class .sql files where your SQL tooling and your agents work, add annotations, and let a small tool compile them into the corresponding FHIR Library. Library already reaches measures, questionnaires, plan definitions and activity definitions — everywhere FHIR points at logic — so a bespoke resource buys you an intermediary you then have to stitch back to a library that was doing the connecting anyway.
• Nikolai Ryzhikov's actual objection, he said, was never base64 — that was aesthetics — it was parameters. Once it turned out Library has parameters out of the box, plus dependencies through relatedArtifact and a canonical URL, he was largely sold. John Grimes liked it too. Gino Canessa put the real question back on the table: it was never the encoding, it was a blob versus a structured artifact — do we force Library as the structural model, or have something that represents just the query and build libraries up from those?
• Gino's worry about annotations is that the group keeps promising you only need to know SQL, then layers things on top. If the spec doesn't define the annotation syntax, every tool invents its own and they drift apart the moment an IG published with one tool's annotations meets another's. He'd rather use SQL's own parameterised literals — partly because passing values as parameters rather than rewriting query text closes off a lot of injection surface. Which standard, though, is unclear: Gino thought @, Brian said that's SQL Server, and Nikolai pointed out the question mark isn't ANSI either — it's an ODBC and JDBC convention that SQLite also uses. Left open, with "maybe we do need our own" hanging in the air.
• Library.type turned out to have an extensible binding — in R4 as well, which surprised Brian — so SQL on FHIR can define a query library code and a profile on Library, and repositories can filter for queries. That went in as the concrete next step, with Brian offering the draft. Arjun Sanyal's reminder: whatever gets built should hold for a query in any language, not just SQL. Library's existing $evaluate is less reusable than it looks, since Gino noted it's named for CQL and lives in the CQL guidance rather than core.
• Dialects in a MIME type parameter got a genuine disagreement. Brian and Arjun read it as fair game — parameters are optional, every language has a parser for them, and whoever registered application/sql is unlikely to object. Gino wasn't convinced: parameters are defined by the MIME type's registrant, this one doesn't define any, and he thinks that does break the rules. Left to investigate, with an extension as the fallback, and no suffix trick available since SQL isn't suffixable the way +json and +xml are.
• John Grimes brought a clarification that closed cleanly: the shareable profile makes you declare a column type and error if the returned type doesn't match — but FHIRPath doesn't always have a FHIR type, so a string literal is a FHIRPath String, not a uri. The answer: error when there is a FHIR type and it's wrong, and don't assume the implementation knows more than that. Deeper checking belongs in a separate validate tool. Nikolai thought such static analysis was tractable and shareable; Gino noted it means traversing the FHIR object model and every extension definition, which is not nothing.