Hi! I am one of the few Developers of MoinMoin the WikiEngine that (insert advertising here) > 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. It is very clear that changing Wiki markup is a pain. Situation for "small" wiki engines is not better as we may not have 1.000.000 pages but several thousand instances all around the web and lots of admins that will have to convert their wikis without deeper knowledge of the engine. So in fact noone will do large steps. So if we talk about standards I expect it will be standards about wiki engines that already have very simmilar markup. But this does not mean we should limit ourself to small step at the beginning, but we should be aware how difficult it might get. May be there is a chance to make finding some standards easier. I don't know about other engines but in MoinMoin there are parts of the markup that is very unlikly to change. Things that cannot really improved. We would perhaps simply ignor the standard before changing them. There are some other parts thatwe did that way because someone wanted that feature that is not widly used. Lets say somthing like Superscript. So we would consider changing this to comply a standard. An there are even things we are considering to change but did not do yet. I would suggest that additional to the syntax of the markup the wiki engine developers state how likely some markup is to change. We could perhaps simply use background color in the spredsheet. I suggest the following schema: Level 1 (green): Don't care if it is resonable. (Feature not yet implemented or planning to definetly change it) Level 2 (yellow): We might change this but it should be simmilar to our old markup. (like "*** list item" to " * list item") Level 3 (orange): We might change some implemetation detail. (like not requiring whitespace at the begin/end of headings) Level 4 (red): hell freezes before we change this. (like supporting CamelCase) Of cause these statements can only be a first impression. --------------------------------------------------------------------------- The next thing I would like to state that I still have the feeling that we don't still know what exaclty we are doing here. I am missing the goal of the working group. There are people talking about compatibility and moving markup between engines. I think this is impossible. If we want to move data between wikis we should use a parsed and defined format. This still has limitations as the foreign users we not be able to read "failed" markup, but is much more likly to be implementable. I have some thoughts about this but I think this should not be part of this working group right now. > 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. Agreed! > 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: I think we should start somewhere. Further interoperation between wiki engines is a very insteresting topic and I would very much appreciate if we could use the working group as a forum to discuss this. But right now we should only concentrate about issues that might have an effect on the markup. > * 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. We are introducing an MoinMoin wide solution with an central black list of URLs with the upcomming version. But we do not have any experience yet. > * 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 > wiki. We plugin extentions is by wrapping external programms with 10-20 lines of Python code. I don't see an really easier solution. But a common syntax would make sense, IMHO. > * Cross-wiki transclusion. This is a really hot topic. (I recommend http://xanadu.com/ for everyone interested). Main problem I see is not the is not the last modified stamp but the ability to offer a rendered piece of a page. > * Copyright metadata. Yes, lots of small wikis simply ignore the copy right laws. > * 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. There is Wiki XML RPC invented by the JSPWiki people. (http://www.ecyrd.com/JSPWiki/Wiki.jsp?page=WikiRPCInterface2) It might have to be extended a bit to be useful... > 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. Agreed! If this working group really works and has some impact on wiki development it is too valuable to just stop it. Florian Festi