20 Sep
2007
20 Sep
'07
5:14 p.m.
Sorry for the late reply, I didn't see your mail.
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?
"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.
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