David Gerard wrote:

On 04/07/07, Chuck Smith chuckssmith@gmail.com wrote:

...

After a year of diligent effort, a group of nearly 50 dedicated users and developers are proud to release WikiCreole 1.0. Creole is designed to be a common wiki markup language which augments existing markup to enable wiki users to transfer content seamlessly across wikis, a boon to novice and expert users alike.

How well does it do the round-trip from MediaWiki syntax and back again?

WikiCreole is a feature-reduced markup. Features which may help with such conversion, such as the proposed extension/plug-in syntax, have not been included in WikiCreole 1.0. Also, WikiCreole does not reference HTML or CSS, unlike MediaWiki which allows a broad range of filtered HTML attributes, including a minimally filtered style attribute. WikiCreole can be converted to HTML, but the converse most certainly isn't true.

So in a nutshell, not well at all.

The most plausible proposal is to allow WikiCreole in new MediaWiki installations. An alternative parser could be provided, and the user could select it on install. We could use the traditional parser for processing internationalised UI text, some of which is wikitext.

-- Tim Starling

On 7/4/07, Jay R. Ashworth jra@baylink.com wrote:

1. do they conflict (IE: must any given page be *either* one or the

other)

Definitely. You can glance over the spec at http://www.wikicreole.org/wiki/Creole1.0. They do provide a "placeholder" syntax that could theoretically be used to allow preexisting MW pages to be edited in WikiCreole without breakage, but only if you're content to not edit any part of the page that their syntax doesn't cover, e.g., anything contained in raw HTML tags. If you are, you could theoretically allow round-tripping.

2. are the unambiguous markers that would identify which one a user was

working in?

Not inherently, although of course those could be added in any particular implementation.

3. if 1 is true, then why, again, was the decision taken to create a

new markup that conflicts with MWtext, given the installed universe? :-)

The idea is to get all wiki software to use the same markup, not to do anything specifically for MediaWiki. Frankly I have to question whether there's any benefit in this, given that a) probably almost no one will have occasion to use more than one wiki package more often than once in a blue moon; and b) wikimarkup is pretty horrible anyway from a technical perspective, as I've complained about in the past, and if you're going to break reverse compatibility it should be for WYSIWYG. But hey, if people want to spend their time on it, that's their business. Just don't ask me to write the MediaWiki support and I'm fine with it. :P

On 7/4/07, David Gerard dgerard@gmail.com wrote:

Heh. At work, I deal with most of the wiki engines anyone has ever heard of. Let me assure you: *all* the various wiki markups are horrible, and I don't think any of them were "designed" per se. MediaWiki's is, I understand, provably impossible to put in EBNF, which is why the parser documentation is the parser code ...

I imagine that it's possible to put all of it in EBNF if you had unlimited lookahead, although I don't claim to be any kind of expert on language theory. Of course, you'd have different grammars for different content languages, and different grammars depending on what options the wiki chose (e.g., aliases for the image and category namespaces), if you wanted to parse it all properly and not just treat images, categories, links with namespace, links with no namespace, and interwiki links all the same, for instance. WikiCreole at least sidesteps that, but at the cost of losing features (no namespaces, no categories, no templates).

I would hope WikiCreole would pay attention to being well-formed as a language, at least to the extent of being EBNFable, and extended with a view to remaining so ...

Well, searching wikicreole.org for EBNF leads to zero hits, and BNF gives one unrelated hit, so I can't admit to much optimism in that regard. A cursory look at the standard reveals tidbits like "a line starting with ** (including optional whitespace before and afterwards), immediately following any list element on a line above, will be treated as a nested unordered list element. Otherwise it will be treated as the beginning of bold text." That doesn't sound promising to me, but hey, I don't know much about formal language theory.

It also requires that [[http://www.example.com]] be parsed differently from [[http:/haha I tricked you]], which (like MW markup) requires an arbitrary amount of lookahead depending on available protocols. Furthermore it doesn't specify which protocols are to be supported, so potentially the grammar could even change within a single wiki package if differently configured (this is the case for MediaWiki's $wgUrlProtocols, for instance).

So I suspect that hasn't been a major goal of the project. I'm not even sure it's realistically possible, sticking with purely wikitext-style markup, unless you want to invent a fantastic menagerie of creatively interspersed punctuation marks for every variation of markup, which would of course need to be memorized by rote. Then you could do things like say that [! !] or God knows what is an external link, for instance, doing away with the need for lookahead at the URL protocol; use something different for bold and lists; etc. MediaWiki uses three different markups for internal links, external links, interwiki links, image inclusions, category inclusions, template inclusions, and direct media links, for instance. If you wanted to use seven different markups for that instead, it would be more easily parseable but probably harder to remember and more confusing to look at. It would be interesting to see someone try, though.

On 7/4/07, Michael Daly michaeldaly@kayakwiki.org wrote:

David Gerard wrote:

...

MediaWiki's is, I understand, provably impossible to put in EBNF, which is why the parser documentation is the parser code ... But it's not actually worse than any of the others. Though possibly it has more odd bits bolted on the side.

I was thinking about this recently (while considering documention of an extension). Would it be possible to split wikitext into the bits that are EBNFable and the bits that are not - then come up with an EBNF alternative to the non-EBNF and deprecate the latter?

Sure, lovely. Someone just has to do that and write a replacement parser, then we can talk. :) In practice there's probably going to be too much resistance to changing the markup that drastically, regardless of whether anyone wants to do it. The grammar could, however, be improved significantly from the current state by only tweaking edge cases, which could give you a semiformal but rigorous grammar (whereas now we have no grammar at all).

But someone still has to put the effort into not only defining the grammar as best as possible, but writing a replacement parser for it before we'll get anywhere. They don't need to have any fear of rejection, as long as it's reasonably reverse-compatible: all the developers would be delighted to get a semiformal language definition and accompanying parser, and I have little doubt we'd incorporate it into the software. The problem is that nobody that I've heard of has put together more than a rudimentary grammar, nothing suitable to actually replace the parser.

On 7/5/07, Jay R. Ashworth jra@baylink.com wrote:

On Wed, Jul 04, 2007 at 09:03:06PM +0100, David Gerard wrote:

...

MediaWiki's is, I understand, provably impossible to put in EBNF, which is why the parser documentation is the parser code ... But it's not actually worse than any of the others. Though possibly it has more odd bits bolted on the side.

Well, yeah... but if you order the semantic bits in MWtext, and arrange them in, say, order of popularity...

I wonder how far up the tree you can climb before everything falls apart? :-)

The real substance of my question, though, was "what was the underlying justification behind creating a "new all-singing, all-dancing wikitext syntax a) at this late date, b) which is not a proper subset, at least, of the wikitext syntax in broadest use?" -- either by number of pages, or, I would venture to speculate, number of installations.

Cheers,

-- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

One day i had this crazy idea of creating my own wiki engine from scratch (although it never materialised to anything) - when planning syntax I came to the conclusion that the best number of characters to use for each style of formatting was 3. It is both relatively unused (compared to single and double character sequences), easy to remember (3 is the magic number), and it is easy to see if you have malformed your syntax. Thanks, MinuteElectron.

Frankly I have to question whether there's any benefit in this, given that a) probably almost no one will have occasion to use more than one wiki package more often than once in a blue moon;

I'm strongly in favor of a common markup standard. MediaWiki may be the leading wiki engine on the web, but it is only one wiki engine in the workplace. At work, at SAP, each day I have to deal with MediaWiki, Confluence, Socialtext, Twiki, and some other random engines. Switching back and forth between the syntaxes is a huge pain. I avoid it as much as possible, to the detriment of getting my work done.

Dirk

On 06/07/07, Thomas Dalton thomas.dalton@gmail.com wrote:

I don't understand. Why did you do this? What purpose does it serve? What significant improvements does WikiCreole have over MediaWiki syntax?

I presume that it is hoped that one day WikiCreole became a standard. If so, that would allow people to convert material between different wiki engines with ease. At the moment I gather it's pretty ad-hoc and painful to convert between different engines.

In the field of spoken languages, people have tried creating a language to make communication between people using different languages easier (Esperanto being the best known). None of them have taken off, because it involves everyone learning a new language, and there is no point everyone doing that. When people who speak different languages wish to communicate, they speak English, since it is the most used language. English is not as easy to learn as Esperanto, but people have a much greater incentive to do so since there are actually people that speak it.

Wiki syntaxes are no different.

Of course a machine language is completely different to a human language (constructed or natural). A small example: - in human language we can invent new words and expressions at will and if they "catch on" they will be widely understood. in a machine language new expressions can only be designed in (top down).

Just because human language can't be standardised doesn't imply that machine languages can't.

regards Brianna user:pfctdayelise

On 06/07/07, Thomas Dalton thomas.dalton@gmail.com wrote:

The main question is this: If I was writing a wiki engine and wanted it to be compatible with other wiki engines, why would I implement Creole instead of, say, MediaWiki syntax?

It's easier? ;)

Rob Church