[xwiki-devs] [Discussion] Designing the new Rendering/Parsing component/API

[Sergiu Dumitriu]

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