MeatballWiki | RecentChanges | Random Page | Indices | Categories

In absence of a better idea for a page name. This is both a critique and a modest proposal to improve WikiMarkupStandard.

Critique and motivation

WikiMarkupStandard, by consolidating existing practices, it is poorly structured (to say the least). This is all well, as far as it goes, except when you think of all useful applications that can be made with wikis. At work, I started using wiki for documenting architecture, then I realized what a neat idea to use Wiki as repository. If I could snap my fingers I would have had my installed wiki (MoinMoin) support DDL for databases, a few other structured notations, and many other things. Other applications: there are collaborative content open source creations for teaching chess to kids, a wiki would be perfect, except that there's no wiki syntax for chess diagrams. There is a syntax for go diagrams at the well known GoWiki?. All these syntaxes may interfere with each other, if we chase after all the peculiar characters.

And there's no need to repeat the lessons of Html, when people started complaining that valuable data was lost like the needle in the haystack, amongst the sea of poorly structured HTML pages.

What can be done.

As I am working to get a the first cut of Wiki:WikiChangeProposal out, my approach is as follows: the parsed page is EssExpressions?. This universal data structure is best suited (in my opinion) to provide structure to wiki content. Now since Wiki:WikiChangeProposal is targeted initially to programmers, I'll go with an EssExpressions? notation similar to Lisp/Scheme, some programmers might even enjoy it in a geeky kind of way. The major adjustment to usability is that large portions of text won't be written as Lisp string literals. When and if I'll have the time, I'll write a few regexps to converts a minimal syntax (for example the C2) into EssExpressions?. This can be used to ease the transition or to import some existing content.

So I was thinking that WikiMarkupStandard could do the same: define a core extensible DataModel? for the conent of a wiki page, which should be abstract and all WikiEnginers? can either use that model internally, or provide export/import function centered around it. This core data model can contain, for example (in ML notation)

 type external_url = Http of string | Email of string
 type wiki_link = Internal of string | InterWiki of string | External of external_url
 type link_element = { label: string option          (* is optional *)
                       , link: wiki_link }
 type text_element = Text of string | Link of link_element
 type text = text_element array
 type paragraph = { content: text ,  (* ... other options related to formatting, etc * ) *)
 type page_element = P of paragraph | H of header | L of list | T of table | TC of table_of_contents | I of image ...
 type wiki_page = page_element array

Once this core model is clear, the concrete notation can be very different (depending on various design constraints related to a particular engine), yet engines will be able to interoperate with relative ease as long as they have the same core data model. This model will also ensure a relatively better picture of what the concrete syntax is supposed to mean.

Analogy: this has been done retroactively in the evolution HTML => XML => XML InfoSet?. Now there's at least one alternative notation for XML trees http://okmij.org/ftp/Scheme/xml.html .


MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions