Thanks Gregory Dubois-Felsmann, I agree with basically all of those issues. There's a choice here between having a single RFC with both backend docgen changes + frontend text updates, or the path that I was originally aiming for with one RFC for the backend Felis-ization (with minimal content change), then afterwards do another RFC with substantial text updates.
I'd be happy to discuss these options, but let's do it next week after the lsp review.

I'd be OK with splitting it, too, but we'd at least need a "black box warning" at the top of the document about the need for other updates, I think. More next week...

I pushed some new changes that address the most urgent of Gregory Dubois-Felsmann's comments. I've replaced the first section which described the old schema files with some text on the new Felis-based tools, removed the Enterprise Architect references, updated the stale links for SciSQL, and added a line at the start of the tables which shows the cat SHA1 that was used. I put some text in the README also as a quick guide for how to update the document with a new schema.

With that, the TODO items I propose to defer (and ticket) are:

• Deciding what to do with the diagrams
• Description of ADQL, updates to the UDF discussion, possible mention of qserv_*
• Exposure and Visit tables re: Gen3.
• Checking if the provenance model is still relevant

Does that seem like a reasonably passable state for an RFC, Gregory Dubois-Felsmann?

This looks good to me, and I think it's a big step in the right direction. Gregory Dubois-Felsmann, please comment on Colin's note above – as this stands after Colin's most recent changes, is this in your opinion now ready for RFC?