MarkupStandardPlanB

This page used to be one of the proposals for a WikiMarkupStandard. It has since been superceded by WikiCreole, as agreed upon at WikiSym 2006.

Old Proposal

MeatBall:WikiMarkupStandard is a huge collection of alternatives.

I would like to propose a small subset. The “Suggestion B” I had on that page has been extended again, so I want to work a really small subset here, first, and give it a specific name: Plan B.

I’m wondering about supending wiki processing (nowiki tag, backquotes, tripple square brackets), naming external links [url text], [[url][text]], or [[url text]], indenting text, and preformatted text (whitespace or pre tag). There seem to be no clear favorites.

ElementExample and Comments
Paragraph Empty line separates paragraphs
Emphasis (usually italics)''emphasized words'' – an alternative like /emphasized words/ would be ok as well.
Strong emphasis (usually bold)'''strong emphasis''' – an alternative like *strong emphasis* would be ok as well.
Unordered lists Lines starting with an asterix followed by a space are list items. Nested lists, multi-line list items, and multi-paragraph list items are not requirements. Empty lines between list items may start a new list.
Internal CamelCase link WikiWord – traditional local links
Internal free link [[free link]] – some sort of free linking is required for scripts that do not have upper-case letters, eg. Chinese, Japanese, Arabic, Hebrew, etc.
External link http://example.com/ – named links are not a requirement, eg. [http://example.com/ example]

The important thing here is that I don’t want a wiki interchange format, I don’t want XML, I don’t want HTML, I don’t want schemas, DTDs, validation, parser models, or anything like that.

We are only trying to do one thing:

  1. Trying to make it easier for newbies to contribute to several wikis.

That’s it.

The markup standard’s mission is to simplify the <textarea/> bit. The WikiInterchangeFormat can get into cascading complication. The only reasonable thing to do is standardize one markup element at a time, rather than the whole thing.

Personally, I prefer cheating. The UseMod syntax has found its way onto the most significant sites. Wikipedia uses it, and now WikiWiki has changed its unordered list syntax to match ours. Conversely, the UseMod syntax is almost entirely derivative from other major sources (e.g. WikiWiki, FoxWiki, MoinMoin, EverythingTwo) as well, which is perhaps why it is a popular one.

It’s no surprise that the worst elements of UseMod’s syntax are things we developed ourselves. For instance, the definition list syntax is bizarre as well as the nowiki tag. – SunirShah

I have noticed that everyone who proposes a solution proposes their own WikiSyntax. ;)SunirShah

Hehe, certainly true in a way. We need to start somewhere, though. Emphasis, internal camel case links, and external links are the same in WikiWikiWeb, however. That leaves unordered lists and internal free links as new items. The unordered list is shared by UseMod, WikkiTikkiTavi, MediaWiki, and Kwiki. The internal free link is shared by UseMod, MediaWiki, TwikiClone.

Might I suggest copying or moving this discussion or a summary of its results back to the MeatballWiki page. It’s hard to make a standard if everyone is talking in different places. – SunirShah

I like it.

I like the idea of a really simple subset, too, with a few alternative. It would be great if we could agree on SOMETHING in this area.

Btw, it might do to have a WikiMarkupStandard workshop at the wiki symposium (although i wouldn’t personally be interested in attending that one, yet i think a lot of others would)… workshop proposals are due this friday.

Moving the discussion is fine with me.

Are WYSIWYG controls practicable in the mid-term? If they are, wiki syntax could turn out to be irrelevant as long as the user interface conforms to some well-known expectations. SunirShah convinced me of that on the WikiChannel. So I decided to no longer try and push this. Instead, I’ll keep my eyes open for some WYSIWYG control we could slap onto an Oddmuse website.

Alex, I think this is a very good idea, and an approach that could form the basis of an interchange format. What I’d suggest is taking the subset you have and considering it a Core module, then encapsulating each of the additional (i.e., commonly-supported but “non-essential”) wiki markup features as “modules,” with specific syntax language definitions for each module, just as you’ve done above for the core. You might note that I divided the XHTML DTD into modules (see Modularization of XHTML for details), such that you could use the “abstract definitions” found in the W3C Recommendation as the module boundaries. Those Abstract Modules are very similar to what you’ve done above – you could even use their table format as a way of expressing the modules. Now, the wiki Core module would definitely be a subset of the XHTML Core set (which is itself made up of Structure, Text, Hypertext and List modules; you’d want to consider the Structure module as part of core, but subset the Text module perhaps), but for the additional feature modules I would recommend using the names and boundaries as found in the W3C spec.

The advantage of this is that we’d have an accepted set of module boundaries, an existing set of names for the modules, and an existing set of DTD modules to correspond with the wiki modules. People could then (in theory, anyway) build XHTML DTDs to match any subset of wiki features. Even if there never ends up being an XHTML-based wiki interchange format, this could still be a practical way to go about doing this. And I’d be willing to help if you decided to do this (if you needed any help deciphering the W3C spec or writing up the module “specifications”). I’m not suggesting we need to make this enormously formal or complicated, just pointing to an existing modularization for the same set of document semantics. Basically, trying to make your life easier. It was an enormous amount of work for me at the time…

Just as an exercise, I’m going to try to do this on PlanBWikiModules.

Feel free to do that, Murray. I’m probably not going to contribute, however. As I said above, I’m really not all that interested in an interchange format – I’m interested in a markup for users. Something real people can use right now. XHTML, validation, spec – that’s not what I’m after. Maybe later, when WikiMigration is more important. Until now OddWiki seems to be the only place where WikiMigration turns out to be a real issue; I find that astonishing. Maybe we need to think about wiki proliferation again. Is there a human tendency not to split? Is there social pressure not to split? Or are there technological barriers? An interchange format would only make sense if this was the major obstacle.

Alex, perhaps you’re misunderstanding my intent. I’m not trying to build an actual page interchange format, just define abtract “modules” that set boundaries for support, and suggesting a common set of names for those “modules.” So at a minimum, if two wiki are trying to intercommunicate (i.e., exchange content), there’d be a Core set as you have described. Then, as people decide to add features, they might decide to use the boundaries set up by this modularization exercise to describe the features added that go beyond the core. The modularization just provides groupings of elements, and names for these groupings. If at some point an actual interchange format comes along, it could be developed along the module boundaries, and then anyone who’d developed their tools and protocols along these lines would have a much greater chance at compatibility. One could then ask a question like: “in addition to Core, do you support the Basic Tables Module and the List Module?” That’s about all I’m trying to do right now, just some low-hanging fruit. It just might seem grand because I’ve dropped in the semantics from XHTML - note that most of these are not relevant.

I don’t think that WYSIWYG is going to become ubiquitous anytime soon, Alex. It takes forever for new features to percolate through all of the hundreds of competing wiki engines. The WYSIWYG idea has been around for awhile, and lots of people (I think..) would have liked to see it for awhile, and yet here we still are.

In addition, there are times when you’d like to use text files to express things. Maybe you are working on something to post to the wiki later in a text editor, maybe you are using Lynx, maybe you don’t feel like using your mouse and would rather just type. Also, there are other places besides wikis where a standard way to express these things would help; for instance, I’ve been using wiki syntax in EasyLatex? so that I can do italics and bolds in LaTeX documents faster.

So, I think a WikiMarkupStandard is still very relevant. And I think MarkupStandardPlanB is the best proposal I’ve seen yet.

If you haven’t seen it, try editing this page: http://www.home.org.au/javascript/keypress.html

It’s fast and almost wysiwyg. IIUC, it uses Ajax, or something like it.

Randy Kramer

See MeatBall:WysiwygWiki for a list of controls. Plone and PHP Nuke already use epoz for their wiki front-ends.

I don’t dispute that WSYIWYG is out there in various forms, but it’s not ubiquitous. A WikiMarkupStandard will not become irrelevant until non-WSYIWYG wikis are rare. To repeat: even if both WSYIWYG and non-WSYIWYG wikis become common, a WikiMarkupStandard would still be relevant; it’s only when non-WSYIWYG wikis are no longer mainstream that a WikiMarkupStandard may not be so important.

A quick suggestion: don’t allow raw external links. Insist on named ones. As I understand it, by doing so you help the visually impaired by pushing people to add a descriptive title to their links. (If some way of forcing people to use really descriptive links could be found, that would be even better.)

Define external redirect: EasyLatex

EditNearLinks: WikiWikiWeb MediaWiki WikiMarkupStandard WikiWiki MoinMoin EverythingTwo FoxWiki SunirShah UseMod TwikiClone WikkiTikkiTavi LaTeX MeatballWiki

Languages: