> Are you suggesting this exact model be the in-memory model? The data model, yes, though not the visual model. Sanity [1], which uses this specification, uses

> Are you suggesting this exact model be the in-memory model? The data model, yes, though not the visual model. Sanity [1], which uses this specification, uses it for its rich text content. Sanity is a document store with a collaborative, real-time editing UI similar to Airtable, but self-hosted and open source. When you're editing some text in the rich-text editor (which uses ProseMirror internally, last I checked), the editor is working directly on this data model, and produces patches against this data model that get synced with other clients. Similar to OT, except it uses a simpler git-like approach to rebase patches and converge the state. There's another, less obvious reason it's JSON. In Sanity's document store, every document is a structured object that is read and written as JSON. Inside each document, Portable Text fields are also stored as JSON, not as a string or a binary blob. This content also is indexed and queryable. For example, let's say you're creating a wiki app; each wiki page is a document, with a title, body, and so on. The body is a Portable Text field. With this, you can find all wiki pages that link to another wiki page by running a query such as *[references("richard-feynman")]. You can do things like extract images, get the first paragraph, etc., all using the query language. All technically possible with XML, of course, though I personally wouldn't want to go there. (Disclosure: I work on Sanity's content store tech, but I don't work on Sanity itself.) [1] https://www.sanity.io https://www.sanity.io