On Mon, 26 Mar 2012 13:56:59 -0700, Daniel Kinzler daniel@brightbyte.de wrote:
On 26.03.2012 22:28, Amgine wrote:
Are we talking about mime types for articles?
Yes, pretty much. Though technically, the mime type would only describe the serialization format (e.g. "application/json"), not the data model (e.g. "wikidata entity record") - both bits of information are needed. But essentially, yes: pages will have types, and types have handlers for displaying, editing, etc.
Otoh this means that HTTP content negotiation is not going to work, or rather, it will only work to pick the the preferred serialization format for a given content. If the client doesn't know the content model, the data is going to be gibberish to it, no matter how it is serialized.
Which is why I propose that per default, any code or client unaware of the possibility of content that is not wikitext, will receive the equivalent of an empty page when requesting content of a page that isn't wikitext. No harm done that way.
-- daniel
Non-wikitext data is supposed to give extensions the ability to do things beyond WikiText. The data is always going to be an opaque form controlled by the extension. I don't think that low level serialized data should be visible at all to clients. Even if they know it's there. Just like database schemas change, I expect extensions to also want to alter the format of data as they add new features.
Also I've thought about something like this for quite awhile. One of the things I'd really like us to do is start using real metadata even within normal WikiText pages. We should really replace in-page [[Category:]] with a real string of category metadata. Which we can then use to provide good intuitive category interfaces. ([[Category:]] would be left in for templates, compatibility, etc...).
This case especially tells me that raw is not something that should be outputting the raw data, but should be something which is implemented by whatever implements the normal handling for that serialized data.