Over on GrahamLally commented :
I'm still trying to figure out a lowest common denominator for simple, structured access to data along these lines. (See [| http://www.exmosis.net/node.Building_Blocks | Building Blocks]), and the main thing that an HTTP front-end offers is, well, the "H" - hypertext, linking. I suspect some cross between Markdown (but with tables), and a vim plugin to jump from file to file might fulfil my needs, although obviously my plans are much, much bigger than that ;) Personal wikis are good, but I do like vim for editing... – GrahamLally
Which got me thinking. In writing SdiDesk I've obviously been trying to separate the data-store part from the bit the user editing bit. And program-wise, I think I've succeeded fairly well. But the ideal would obviously be some kind of page-store that could be accessed through any editor. The problem is that wiki is nothing but a few hacks. It's hard to know what's essential in wiki.
Is it the meaning of the markup? Except that many people want to translate between one markup language and another. Where bold is the difference between ' and *, that's not an issue. But when the markup has more structural information, it's more problematic. For example, what defines a link? And where is the target? When I say WikiWord in one wiki it's a link to a page with the same name. In MediaWiki it isn't.
So let's go back to the idea inspired by Graham : that we could have a general page-store editable through different front ends. The problem is, who's responsibility is it to define that PythonLanguage is a link to a page? Or that [****[hello world]] is also a link? Is it the editor's? Or is it the page-store? And if or other takes the responsibility, how
The "markup translatability" intuition is that there should be a lower-level representation of "links" which any particular flavour of parser can recognize and render as it prefers.
The "independent editor" intuition is that editors should be constrained by some lower level representation.
Of course, where this is leading is some kind of lower-level more formally marked-up substrate - almost certainly in XML bleeaachhh!! :-( which will kill the spirit of the thing entirely.
Hmmm ... it's a tricky question. Somewhat related to DoesAbstractionScale?
See also :
More thoughts later, but see [User-Controlled http://www.exmosis.net/node.User-ControlledWikiFormatting User-Controlled Wiki Formatting] too. I think that was more about the fact that the user has ultimate control, rather than having to rely on a "product" to determine the language (e.g. Mediawiki vs Kwiki or whatever). Of course, the "success" of wikis is not just their "usability" (indeed, wiki use is still, IMHO, for a niche audience), but the ease with which the software itself can be written - hence the abundance of wiki software, but also (a downside) the abundance of wiki formats. Having an XML sublayer would probably kill the development of some wikis, as would some kind of standard format. Choice vs Consistency, as always... – GrahamLally