Topic on Talk:JADE/Implementations

MCR seems like a good fit for page-level judgments (and perhaps for users, too). Making it also work for revision level judgments or diffs would perhaps be possible, but a bit of a stretch.

But I see no reason that page level judgments couldn't use MCR to directly integrate with the page, while revision level stuff is stored elsewhere, be it as a separate page, or using an entirely different mechanism. The same ContentHandler could be used for all interaction with the content.

I wish that MediaWiki already had appropriate paths and storage for both human-generated (editable, versioned) and machine-generated (replaceable, maybe transient) metadata. MCR is a nice step towards that goal, and I can see why it's appealing to use it for... what it's intended for!

I'll sit with the idea for a while and try to come up with a thorough exploration, but so far a few issues jump out:

• Bad idea to have a completely different storage path for one special case, because it complicates all JADE logic.
• Clients will either have to face this same complexity (e.g. when making an edit to raw judgment page content), or we'll hide it in an API. That's fine, but there's no need for an extra API until the MCR twist is introduced.
• JADE events can be emitted by watching the Judgment namespace, but with the page-judgment MCR proposal we would have to add a feature to changeprop to match on slot. Also okay, but it seems like a waste.
• We already know that nothing else will fit into this mold, so it's really a one-off while the rest of JADE will grow to include additional entity types that don't benefit from MCR.

What would make me happy is if MCR grew to become appropriate for all JADE types, then it would be an obvious win.

I'm warming to the idea of using MCR inside of the Judgment namespace, doing something like Judgment:Diff/123, with slots damaging and goodfaith. It's blocked on general stuff like task T199121, task T189220, and maybe adoption questions, but these will all be closed in a matter of time. What I like the most is that slots allow us to separate data from the dissimilar schemas, while keeping a single talk page for all judgments on an entity. We could have alternatively accomplished the first part by further normalizing by title, i.e Judgment:Diff/123/Damaging, but then the talk pages are diluted between "Damaging" and "Good faith" although this should clearly be a single conversation in simple cases.

Other characteristics of MCR slots are a great fit as well: serving the latest slot-revision content as current data, having history grouped by schema, being a small and unchanging set of schemas, even the separate ContentHandlers is intriguing.

One thing you could help me understand is how I might pull together data from all slots into a single page view in this scenario. I'm sure other MCR integrations have needed something equivalent, would you point me to an example? (Maybe I should follow the life and times of WikibaseMediaInfo's MediaInfoView class? I'm lost at `view-factory-callback`...)

Also, does it make sense that I wouldn't keep anything in the main slot? Could I even disable the main slot until we find a reason to define its semantics?

(Maybe I should follow the life and times of WikibaseMediaInfo's MediaInfoView class? I'm lost at `view-factory-callback`...)

Never mind about that, I see it's for Wikibase presentation and not relevant to my question.