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.
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 .