Topics discussed:

• A visual ViewDefinition builder needs two things the spec does not currently give it: somewhere to keep views, and something to run them against while you iterate — a REST API to store and list ViewDefinitions, and an operation to evaluate one against sample data in a loop. Whether any of that belongs in the spec was the open question. The position taken was that if ViewDefinition is a canonical resource, ordinary FHIR CRUD plus a couple of operations mostly covers it.
• CRMI — canonical resource management infrastructure — is being built out for CQL artefacts, but it is really about any canonical resource: CRUD and search, plus an operation to get the dependency graph of a canonical and an operation to package it. If ViewDefinition is canonical then CRMI applies more or less as-is. The pattern worth borrowing from SDC is the role split: a repository role that serves ViewDefinitions and an engine role that runs them, so one builder can talk to any implementation.
• On 1.0 timing, the remaining blockers came to two column-ordering issues and three test issues, with everything else editorial. End of July was proposed so it lands ahead of the September connectathon, with the line to give people who ask being simply "over the summer".
• Should the prose be more formal, more standards-like? The answer was no — the informal, readable style is a feature, and plenty of good specs are written without heavyweight jargon. What it does need is consistency: use must and may the same way every time, remove ambiguity, add a glossary, and stop non-goals appearing in two different sections.
• A rename proposed for the "Implementer Guidance" section to something like "Processing Model", because the current name reads as optional advice when the section is actually the semantics — it goes straight into how a view is evaluated, and the heading undersells that it is part of the spec proper rather than a set of tips.