Last modified: 2014-11-08 00:44:49 UTC
The multipart content model should support a "main" part containing wikitext, and several "attachments". The different parts would be bundled together in some kind of envelope structure, using something like JSON, XML, or mime/multipart. Only the main/text part of the content should be exposed via EditPage and action=edit. Some other parts can be accessed/edited via EditPage and action=edit by requesting them specifically. Some parts, depending on their content model, may not be editable via the text based interfaces. Note that exposing only the textual "main" part via action=edit breaks the assumption that it is possible to grab a revision's content, modify it, and save it. The revision's content would be the full blob containing all parts (unless requested otherwise).
I think we have something similar to this in MassMessage: a JSON content model that contains and displays displays wikitext, and a structured spamlist. (example: <https://test.wikipedia.org/wiki/Yay_mm-ch!>).
It seems that we want a "multi-part" content model should be either completely visible & explicit, which would mean it can't be edited directly using the "normal" EditPage, and reading and editing via the API would require the client to understand and process the multi-part wrapper data structure. Or it should be completely transparent, exposing only the "main" (typically wikitext) content even when editing using EditPage, or even when asked for revision content via the API. Any "extra" parts would need to be requested explicitly. This means core could has to know about this special kind of content model, and implement special handling for it in several places. I think it would be good to have both: a basic multi-part model, as well as a "transparent" multi-part model, built on top of the "normal" one.
