[WMS] Thoughts on standards

  • From: Erik Moeller <moeller@xxxxxxxxxxxx>
  • To: wiki@xxxxxxxxxxxxx
  • Date: Wed, 06 Oct 2004 05:38:24 +0200

Hello friends,

I am one of the many people working on MediaWiki and Wikipedia. Here are
some general thought on standards, and on this effort in particular.

1) Any major change of the standards on a huge site like Wikipedia is
hard to implement given user resistance. There are minor details that
can be improved and made more consistent, of course.

2) A few people on the MediaWiki development team are working on a
wikitext->XML->HTML parser. This strikes me as the more immediately
useful approach. If all wiki engines become capable of rendering the
same XML code, then conversion between wikis becomes trivial. (Just
using XHTML and namespaces for wiki-specific markup may also be an
option, but may be more confusing.)

Beyond that, I believe that we should try to distinguish different
"groups" of standards and standardize within these: the UseMod-likes,
the TWiki-likes, and so forth.

I hate to say it, but CamelCase is a big barrier. CamelCase links cannot
be usefully automatically converted. How is the program supposed to know
that "MicroSoft" is "Microsoft" and not "Micro Soft" or "MicroSoft"?

3) I think this effort right now is too narrow. The markup syntax is not
the only aspect of wiki tech that we need standards on, and not even the
most important one. Here's a few I can think of:

 * WikiSpam. There have been discussions about a shared blacklist but
   IIRC nothing has come into place yet. Here we need to mostly agree
   on who will be allowed to make additions to the blacklist. To make
   it wiki-like, a cross-wiki way to review the contributions by one
   IP address would be good. Still we need to be aware of the spammers
   trying everything they can to get off the blacklist - at least some
   barrier to entry may be desirable.

 * Extension standard. I'm not just talking about the syntax. Many 
   extensions (graphs, latex, etc.) work according to the same scheme:
   get some input from the wiki, generate some output. It would be nice
   to be able to take an extension of this type and plug it into any

 * Cross-wiki transclusion. We all know about InterWiki links, but what
   about transcluding content from one wiki to another? This could work
   like this:


   would transclude (dynamically include) the "Goals" section of the 
   markup standard page in a wiki. Of course that content should be
   cached. For this it is necessary that all wikis send last-modified

 * Copyright metadata. Most of the smaller wikis have no copyright
   information at all, let alone machine-readable metadata in a format
   like RDF. This also extends to copyright on pages. Wikis which do not
   use a free license or the public domain should at least provide some
   way by which newly created pages or individual contributions can be 

   This is absolutely essential for transclusion. The transclusion
   mechanism must be able to check whether it is legally allowed to do
   what the user tells it to do.

   Having no copyright statement on individual pieces of content is bad,
   bad, bad, because *everything* is copyrighted by default. This is a
   bug in the copyright system and the only way to fix it is to give
   people an easy way to take their stuff out of that system.

 * In a similar vein, page import and export including page histories.
   Again, XML would be useful here. MediaWiki already has the export,
   the import was still beta last time I checked. Note that MediaWiki
   XML just puts the wikitext into one element.

 * Certification. I believe it will be generally useful to have a
   process by which we can certify that a wiki engine complies with
   standards X, Y, and Z. This will make choosing a good wiki a lot

   In a wiki-manner, this process should be open and consensus-based:
   no consensus, no certification. Here it helps to use what we call
   "actionability" on Wikipedia. If an objection to certification is
   not actionable, it can be ignored.

There's more, obviously. My point is that we shouldn't limit ourselves
to working together in only one field. Now, I agree that we should first
focus on addressing the markup situation, but we should make our mission
statement broader than that so that this effort will lead into a new era
of cooperation among wiki developers.



Other related posts: