Daniel Kinzler wrote:
To put it briefly: I want to remove the assumption
that MediaWiki pages
contain always wikitext. Instead, I propose a pluggable handler system for
different types of content, similar to what we have for file uploads. So, I
propose to associate a "content model" identifier with each page, and have
handlers for each model that provide serialization, rendering, an editor, etc.
It's an ancient assumption that's built in to many parts of MediaWiki (and
many outside tools and scripts). Is there any kind of assessment about the
level of impact this would have?
For example, would the diff engine need to be rewritten so that people can
monitor these pages for vandalism? Will these pages be editable in the same
way as current wikitext pages? If not, will there be special editors for the
various data types? What other parts of the MediaWiki codebase will be
affected and to what extent? Will text still go in the text table or will
separate tables and infrastructure be used?
I'm reminded a little of LiquidThreads for some reason. This idea sounds
good, but I'm worried about the implementation details, particularly as the
assumption you seek to upend is so old and ingrained.
The background is that the Wikidata project needs a
way to store structured
data (JSON) on wiki pages instead of wikitext. Having a pluggable system would
solve that problem along with several others, like doing away with the special
cases for JS/CSS, the ability to maintain categories etc separate from body
text, manage Gadgets sanely on a wiki page, or several other things (see the
link below).
How would this affect categories being stored in wikitext (alongside the
rest of the page content text)? That part doesn't make any sense to me.
MZMcBride