It’s just data

Wikiwiki, What?

This panel did not result in any bloodshed.  Which is a bit unfortunately, really, as I believe that the panel format works best if there is some controversy.  Unfortunately, each of the participants were too damn agreeable.

However, it was a good session in that a number of people who didn't know much about wikis got a flavor of what wikis are, and those that have used wikis before got a number of questions answered.

One key problem that we identified was the wiki syntax - both from a learning curve point of view and from a wiki tool lock-in perspective.  It would be really nice if we could define a unified inport/export syntax that tools can use, either to PUT data to a wiki, or to migrate data from one wiki to another.

An obvious candidate would be (X)HTML, as every wiki provides some form of export to (X)HTML today.  The problem is import: one should not have to implement a renderer comparable to IE or Mozilla to do a credible job.  A profile or subset is called for.

Ari Steward expressed an interest in working on such a profile and implementing it on his wiki.  I could do the same for MoinMoin, and perhaps if we could get a few other proof points, adoption would snowball.

If we could then get blog client tools to produce this same markup, then editing a wiki page could be as editing a weblog entry.

The folks at have started working this: RFCWiki.
They're even planning to submit this to the IETF.

As for weblog tools implementing such syntax: if out of this effort comes a unified format, we'll be sure WordPress supports it. :)

Posted by Michel Valdrighi at

Yes!  Please ...

This would be wonderful as converting existing wiki content to a new wiki's format is at best a drag and at worst prohibitive.  It also makes experimenting with new wiki software significantly harder as you don't really get to have a good feel for how it works with your content without significant work.

As a side note, the folks over at Meatball have put a lot of thought into what an ideal wiki syntax should look like.

Posted by Adam Shand at

Michel, call me a cynic if you like, but somehow I think that getting people to agree on an exchange format is considerably more likely than getting people to agree on a common wiki syntax.

Case in point: a design point for Ari is the ability to cut and paste email into his wiki and have it display exactly as you would expect.  I don't recall the specifics anymore, but I got the distinct impression that this led to some unique requirements.  If I see Ari tomorrow, I'll ask him to elaborate.

Posted by Sam Ruby at

I've only briefly experimented with Wikis, installing one at work for a documentation system.  But in my brief experiences, I've wished for a common import/export format as you described above, Sam.  The different wiki packages that I've looked into had such varying syntax that I was required to learn something new for each one.  That just doesn't work well when using many different wikis across the web.  I'd really prefer that they all shared the same syntax.

Posted by Scott Johnson at

Needless to say, we (Meatball) are working on a WikiMarkupStandard. In actuality, however, we favour a WikiInterchangeFormat.

Posted by Sunir Shah at

The discussion on the #SXSW IRC channel during the session was quite good and covered a few interesting ideas. About data entry, some people wanted WYSIWYG front-end, some preferred Textile or Structured Text. I'm wondering if Mozile and Wiki make a good fit.

I guess the further along people go to making wiki editing simpler and easier, the closer and closer we get to Tim Berners Lee's original vision of the Web.

As for the idea that XHTML may be a good export format for a wiki, have a look at Danny Ayers' XHTML to Wiki conversion using XSLT.

Posted by Isofarro at

I actually think that Wiki Markup is a serious problem as-is, and a big hurdle in making them more acceptable.  It is just a less crappy way of doing markup than HTML.  I am all in favour of XHTML as an interchange format (and JSPWiki will support import/export over Atom when the time comes), but the cognitive problems of the Wiki Markup still remain.  We should not burden the users with having to learn a new markup, or a markup at all.  Whether there's just a single markup or multiple markups does not matter, even one markup is too much.

We really should concentrate on building WYSIWYG wikis.  I think something like HTMLArea-style components combined with XHTML import should really work.  Of course, things like diffs will become somewhat more complicated than what we are used to, but hey - you know the old adage: "you write it once, the user uses it a thousand times."

Posted by Janne Jalkanen at

Well, I tried to stir up some controversy via the #sxsw channel, since I was in another session at the time. But you already know that I've got concerns about wikis from an information architecture and usability standpoint, since I've not been shy about complaining on m2m. :)

Posted by Liz Lawley at

Count me in. I agree that an interchange format is a better idea than trying to standardize on a wiki format (which has been tried half a dozen times), and I agree that the format should be a subset of XHTML. The format can probably be defined simply by ripping stuff out of the XHTML 1.1 Strict DTD.

Posted by Leo Simons at

Wiki syntax standard?

The tikiwiki people (among others) are working on a standardized syntax for Wiki text. This would be a Good Thing to have, not only to move data between wikis, but also as a general data-entry format for structured content. Via......

Excerpt from Bertrand's weblog at

If we look at Wiki as a documentation system, then we'll naturally focus in on the markup language. And we certainly do need to fix the issue of markup. I'm all in favor of WYSIWYG editing, but I'd actually rather use a heavy-weight front end, something like OpenOffice to give me all the efficiencies of a robust word processor, and let it serialize to a Wiki. Sure, keep web based editing as a backup, but let's having something efficient for power users.

On the other hand, if we look at Wiki as a platform for collaboration, then there are a slew of areas we would want to address. When I brainstormed improvements with other Wiki users, we derived five areas of improvements: efficiency of use, effectiveness of use, adoption, use models, and expansion. You can see the in depth list in the brainstorm picture. (Efficiency is roughly equivalent to usability, while effectiveness is roughly equivalent to functionality.)

A word processor is an efficient way to write for a whole number of reasons, mainly having to do with the maturation of the tool over the course of twenty years. Unless I had specific reason to use Wiki, I'd rather write a book in a full-fledged word processor than in Wiki.

Tools like MindManager are way more effective than simple text documents for the rapid capture of brainstorming output. Even the kludgey draw tool in TWiki is used extensively at HP. Graphics are effective in communication and collaboration in ways that text is not. I think improvements to Wiki that enable more effective communication via graphical expression will be a killer differentiator.

Adoption would indeed be greatly aided by a WYSIWYG editor as an alternative to wiki markup, but in my experiences at Bainbridge Graduate Institute, it turned out that aesthetics was the largest barrier to adoption.

We could expand Wiki usage by looking at use models. At HP, we frequently wiki together during meetings in real-time using NetMeeting or WebEx. This works well in the corporate environment where we have those tools, and not so well in the academic environment where we don't. 

And finally, providing expansion through, among other things, a mechanism to add structured content types (i.e. discussion, task lists, etc.) to fit within a Wiki would expand in the ways that a Wiki is used productively. There's nothing that can't be done on an unstructured page, but first you have to get people to grok the conventions that lend implicit structure to the page.

Interestingly enough, I'm against excessive structuring between pages -- I think the relatively flat name space of Wiki actually aids contribution to the Wiki because you don't have to think too hard about where to put new content. But having structure within a page can be valuable.

All of this is to say that if we look at Wiki as a true collaboration tool, we are just in the earliest stages of its evolution. One of the panel questions was about the mainstream success of Wiki. I don't think it will go mainstream the way it is today. But as we address the whole system, I think we'll create something new - something based in Wiki and yet radically different looking, that will achieve mainstream success.

-- Will

Posted by Will Hertling at

Well, while most of the guys out there are seeing and insisting on XHtml output, I tend to go for a more general format than XHtml as the "main" output format and I have my reasons...
As we're going on, the demand for having more rich features on WIKIs increases. One of the main ones are "exporting" to different formats (such as RTF, PDF, DOC, and so on...). (X)Html was the first of this line but as I mentioned more are comming. As we in Confluence are supporting plain XML and PDF output format too. RTF and Word Doc can be the next...
Well, for supporting all these output formats (which XHtml is definitely the primary one), just going from Wiki-->Xhtml-->XSL-FO or Wiki-->Xhtml-->RTF is not the best solution and sometimes we get into problems having all output types synchronized. The above mentioned paths are not always straight forward.

I believe that having the Wiki rendering engines to output XSL-FO or DocBook can be the best as there are many converters (XSLT and so on) for going from them to other formats such as XHtml, PDF, RTF and so on... Hope I can see this implemented one day in future :-) Or maybe I start to come up with one myself ;-)

Just My 0.02$! What do you think?


Posted by Armond Avanes at

There, I've updated MeatBall:WikiSyntax so that it is much more comprehensive. Expect this to rationalize into a real theory of syntax processing in the near future.

Posted by Sunir Shah at

"a more general format than XHtml as the "main" output format" -- Hmm. Let me think. Ehm. No. Seems like you missed the point (or I'm missing it, probably just as likely :D). I think we need to focus not on the input format or the output format, but on something which can be interchanged easily and is understood by all parties participating in that exchange. XML is a good choice for an interchange format because it is used everywhere and just about any self-respecting language knows how to read and write it. XHTML is a good choice because it is XML, used everywhere, and has just about all of the common parts of the wiki format built in. Everyone understands <em/>, <strong/>, <h1/>, <hr/>, and those are precisely the basic concepts of wiki markup.

Posted by Leo Simons at


LOL!  Note the panelist named Sam Clearly this had nothing to do with  this panel. Right on target.  I do believe that the panel format works best if there is some controversy..... [more]

Trackback from Sam Ruby


Three flavors of wiki exchange

There's been an ongoing conversation about wiki standardization. The conversation includes proposals for three different types of wiki exchange. Standards...... [more]

Trackback from BookBlog


re. kludgy draw tools, here's another:

SVG Wiki Whiteboard

Posted by Danny at

I think it's not possible to work out a standard for wikis, there's too much different software, too many different developers and at least too many different wiki-webmasters out there ....

Posted by Ben Bluestack at

the more the explanation is probably the more black, Replica Hermes Belt in other words, the image and reputation loss is irreparable, only money Compensation)

Posted by gucci belt replica at

Add your comment