Sorry for the late reply, I didn't see your mail.
"HTMLParser: I think all parsers above need to support HTML since the wiki syntaxes can be mixed with HTML"
I don't understand this. What does manually entered HTML have to do with wiki parsing?
Because in wiki content user can introduce HTML.
Yes, but HTML should be left as-is. I don't see why it should be parsed. Do you have a use-case for parsing HTML together with the wiki syntax into a DOM?
To summarize we need to decide on the topic of whether we want to display wiki content in the user's preferred syntax or not. To be honest I also like that a lot since this is not something you find in other wikis but I'm worried about 2 things:
A) feasibility. Aren't there always going to be lots of incompatibilities? Macros can be generic and work for all syntaxes so that's not an issue but what about links for example. XWiki's link syntax is richer than most other wiki's link syntax. For example if there's a reference to a another xwiki db in the link (otherwiki:SomeDocument) then what's going to happen when viewed with, say, a mediawiki syntax?
We either have to extend all the syntaxes, or to restrict the users only to use the common subset among all syntaxes. Or something in the middle, extend where possible, but trim all the things that don't have an equivalent in one of the syntaxes. The best thing would be to try to extend all syntaxes.
B) Complexity. Every user is going to be using his favorite syntax and thus when users talk together, copy/paste snippets on xwiki.org for example, they're all going to be in different syntaxes.
C) Included documents. What syntax will they use? #include will copy the content, and let radeox process it later, along with the includer document. We can put the included document inside a {syntax:$idoc.syntax} block. D) A common practice was to use velocity to generate wiki syntax that Radeox would process, or to generate (radeox) macro parameters using velocity, like the {rss:${userobj.feed}}. What happens if we dynamically change the wiki syntax? Velocity can't know about that. And with such fragmented code, it will be very hard to dynamically change the syntax to the current user's preference.
Maybe these 2 points aren't going to be an issue but I'd like to make sure they're not since this is an important decision and what we gain from implementing it is not so high in my opinion when compared with the option of deciding the syntax at the level of the page or the whole wiki.
Actually if there are performance issues it might even be possible to combine both: * the page is edited in the default syntax (the one configured at the page level or wiki level) * there's an export option to export in a different syntax, same as exporting in PDF, RTF, etc.
What happens after the export? The user edits that version in an offline tool (XEclipse, for example), then he can reimport the changed document, which will be converted back to the original syntax. I'd rather have a "convert" button, which will try to convert the document to another syntax. If there are things that can't be converted, then warn about this, and offer a Yes/No choice to the user, allowing him to force the converted syntax, or abandon the conversion. Hm, talking about XEclipse, maybe we can leave the "edit using XYZ syntax" as an XEclipse feature, not present in XWiki platform. This way we'll remove the stress from the server, as the conversion could be performed on the client.
Thanks -Vincent
And a question on wikimodel, what if there's a feature we need but doesn't have an equivalent in the WikiDOM? Sergiu -- http://purl.org/net/sergiu