I agree that's hyronical to play with a powerful database-built project, and to have no access nor encouragement to organize our data as should be organized. But - we do use normal pages as data repository too, simply marking some specific areas of pages as "data areas". More, we use the same page both as normal wikitext container and "data container". Why not? Alex brollo (it.source)

I'm generally in favor of this plan. I haven't looked over the specific code experiments yet but the plan sounds solid. A few notes: * over time we'll want to do things like migrate File: pages from 'plain wikitext that happens to have an associated file' to 'structured data about a file'. This will be magnificent. * I wouldn't overmuch emphasize things like "oh you could have pages in markdown or tex!", though it does sound neat and all. :) * we need to make sure that import/export round-trips things consistently, including for "non-wikitext" stuff. Either that means making import/export content-aware, or shipping the serialized form through the export XML? As for timing; Daniel's hoping for something in the neighborhood of an August deployment. I think if we keep things minimal that should be feasible; it's somewhat similar to the migration of Image stuff with MediaHandler classes. I'm a bit uncertain about the idea of 'multipart' pages, though attached data YES YES in some clean way is needed. -- brion On Mon, Mar 26, 2012 at 7:45 AM, Daniel Kinzler <daniel(a)brightbyte.de>wrote;wrote:

On 26.03.2012 18:18, Alex Brollo wrote: Because it is not sufficient. There is no way to query such data efficiently, and there is no standard web API to access this data, not URLs to reference it (without the text around it). The proposal allows for structured data as page content, as well as any other type of page content, and it also potentially allows multiple types of data to exist as part of the same page (using some mechanism of "attachment" or "multipart"). -- daniel

On 27/03/12 01:45, Daniel Kinzler wrote: For the record: we've discussed this previously and I'm fine with it. It's a well thought-out proposal, and the only request I had was to ensure that the DB schema supports some similar projects that we have in the idea pile, like multiple parser versions. On 27/03/12 09:37, MZMcBride wrote: These questions are all answered on the notes page that Daniel linked to. The answers are yes, no and yes. -- Tim Starling

On 27.03.2012 00:09, Platonides wrote: Indeed - when I asked Chad about that, he said "ask me again once the dust has settled". I'd be happy to have this in git. Or... well, maybe I'll just make a patch from that branch, make a fresh branch in git, and cherry pick the changes, trying to keep things minimal. Yea, that's probably the best thing to do. -- daniel

On 27.03.2012 00:37, MZMcBride wrote: Not formally, just my own poking at the code base. There is a lot of places in the code that access revision text, and do something with it, not all can easily be found or changed (especially true for extensions). My proposal covers a compatibility layer that will cause legacy code to just see an empty page when trying to access the contents of a non-wikitext page. Only code aware of content models will see any non-wikitext content. This should avoid most problems, and should ensure that things will work as before at least for everything that is wikitext. A diff engine needs to be implemented for each content model. The existing engine(s) does not need to be rewritten, it will be used for all wikitext pages. No. The entire point of this proposal is to be able to neatly supply specialized display, editing and diffing of different kinds of content. Indeed. A few classes (like Revision or WikiPage) need some major additions or changes, see the proposal on meta. Lots of places should eventually be changed to become aware of content models, but don't need to be adapted immediately (see above). Uh, did you read the proposal?... All content is serialized just before storing it. It is stored into the text table using the same code as before. The content model and serialization format is recorded in the revision table. Secondary data (index data, analogous to the link tables) may be extracted from the content and stored in separate database tables, or in some other service, as needed. It's more like the transition to using MediaHandlers instead of assuming uploaded files to be images: existing concepts and actions are generalized to apply to more types of content. LiquidThreads introduces new concepts (threads, conversations) and interactions (re-arranging, summarazing, etc) and tries to integrate them with the concepts used for wiki pages. This seems far more complicated to me. Imagine a data model that works like mime/multipart email: you have a wrapper that contains the "main" text as well as "attachments". The whole shebang gets serialized and stored in the text table, as usual. For displaying, editing and visualizing, you have code that is aware of the multipart nature of the content, and puts the parts together nicely. However, the category stuff is a use case I'm just mentioning because it has bee requested so often in the past (namely, editing categories, interlanguage links, etc separately from the wiki text); this mechanism is not essential to the concept of ContentHandlers, and not something I plan to implement for the Wikidata project. It'S just somethign that will become much easier once we have ContentHandlers. -- daniel

On 27.03.2012 09:47, Alex Brollo wrote: Yes. Basically, the ContentHandler proposal would introduce native support for this kind of thing into MediaWiki, instead of implementing it as a hack with JavaScript. Wouldn't it be nice to get input forms for this data, or have nice diffs of the structure, or good search results for data records?... Not to mention the ability to actually query for individual data fields :) -- daniel

On 27.03.2012 11:26, Antoine Musso wrote: Sure, fine with me :) Though I will likely make a new branch and merge my changes again more cleanly. What's there now is really a proof of concept. But sure, have a look! -- daniel