Major new MIME types must be registered with the IETF and the IANA. To come closer to the InterWiki idea, we somewhen need a StandardWikiMarkup? (still discussed as 'WikiMarkupStandard' here), and use this as reference, when registering text/wiki as general text format for the WorldWideWeb (which gained such much succes only because it is based upon the text/html everybody has agreed on).
Also we should try to register 'text/wiki' so we won't wake up someday up and see something like:
- or even worse further attempts to base the Wiki text idea on lousy and overcomplicated XML legs. I'm very afraid of text/wiki+xml. -- MarioSalzer?
But what Wiki format are you wanting? There seems to be one for each major engine, and variants within each. You can't standardise without a standard. I suggest we roll this page back into WikiMarkupStandard.
Negotiation between whom? Where is the pressure coming from to create such a standard? Who are you creating this for?
Good question. I'm not an expert, but AFAIK you only need MIME type if you are transmitting material on a network. Wikis currently transmit data in HTML form; when you edit a page the wiki text is embedded within a web page. For the notion of this mime type to make sense, you'd need to create a WikiWebBrowser?, than downloads wiki text and displays it either as rendered or plain, and allows edits.
Some wikis support RawMode; these use text/plain at the moment.
I was thinking about what applications would require a standard markup, and the answer is simple. We have been talking about building secondary applications on top of the existing wikis for a long time, such as the TouchGraphWikiBrowser, a WYSIWYG wiki editor, a WikiGateway, and so on. These things are infinitely more complicated due to the rule differences. While TextWiki attempts to solve this problem brute force, it's only written in PHP, and so on and so on. While I am in general against forcing people to use one mark up or another, we might be able to simplify the process. I'm not against XML, personally, provided it is done very intelligently. -- SunirShah
MarioSalzer?: True, there isn't yet one browser that could display Wiki text. But the reason for this is, that there is no WikiMarkupStandard and no MIME type for it - not the other way. I'm pretty sure the Mozilla camp would quickly come up with a plugin for Wiki text, if there WAS such a standard and MIME type for it. And there are also good reasons for having an additional format for the WWW service (like there are good reasons for PDF, Flash and CSS besides or on to of HTML). Just imagine, how the MIME type "text/wiki" differs from "text/plain" - Not much, but that Wiki text IS a hypertext format and could be used in browsers. It's more than unlikely that Wiki text will replace HTML in browsers, nor won't nowadays` Wiki text to HTML transformation engines disappear if we had a MIME type and standardized markup. Think of this: text/wiki is a variation of text/plain, but clearly mimics multiple features of text/html - while keeping easy to read and write even for newbies.
Even if we only could negotiate on the fact that each WikiWord makes a hyperlink and that two and three apostrophes mark text as italic or bold, then just these three facts would be the standard. But that's still different enough from text/plain to allow a MIME type.
And after all there are good reasons to get this, especially for interchanging pages. And this is already happening (not only with those Win32 based Wiki notepads). For example the Linux doc project already uses Wiki as a cheap alternative to DocBook? (to be later converted into this).
And, btw, a MIME type registered with the IETF didn't need to negotiate on THE ONE markup, but could still allow for multiple variations (while currently on WikiMarkupStandard only the adoption of one is discussed). I'm already working on a RFC ("every stupid can write one" as I recently read), which will clearly favour one markup but allow or recommend to implement alternatives and variations. And even if that text/wiki MIME type ever comes, this means no pressure on WikiEngines to adopt it - there's no reason to do so. And sure only few would, because there are good reasons for the different Wikis to keep with their (sometimes weird) markup, if it helps discussing their subjects (for example a Wiki discussing Wiki markup would allow HTML tags, while a Wiki for discussing HTML markup would only allow Wiki markup).
MarioSalzer?: Sounds interesting, but I have no idea how this could look. So its probably best to go with the usual excessive textual documentation. Eventually it was ok in this case to describe Wiki syntax by a collection of regexs instead?
MurrayAltheim: Sunir mentioned above that I have recently started up a proposal for a wiki MIME type RFC, not realizing that anyone had anything in the wings. As someone with an SGML/XML background (I wrote the modular XHTML DTDs for the W3C Recommendation), I can't say that I think it's either advisable or necessary to agree on a single wiki syntax. That kind of attempt at standardization is coercive and corrosive to community. And it wouldn't work. The MIME registration does not need to advocate a single syntax. For the purposes of MIME, it only need state what kinds of things *might* occur in a wiki document. We know what those things are: plain text and possibly some HTML-like markup. That's all that's necessary from the MIME standpoint. Now, from the wiki community standpoint, we probably want a bit more, like being able to:
On my [WikiMime] page I describe this in a bit more detail. Basically, the only thing the MIME RFC need do is suggest a first-line-of-file identifier, as we see in perl or shell scripts. This allows a sniffer (or a person looking at the file) to identify that it's a wiki document, and optionally an identifier for the syntax. The only *requirement* of the RFC is that people wanting to identify a specific document as wiki text (for purposes of MIME) include "#!wiki" as the first line of their document (with other parts of that line optional), e.g.:
#!wiki "Ceryle Wyki" http://purl.org/ceryle/wyki/1.0/
The URL might point to a syntax specification, but it needn't. It's only there to state which syntax is being used. The quoted string is the optional, human-readable version of the URL. If people gradually began moving towards a common wiki syntax, fine. But the RFC would be neutral about that.