1) We'll be able to import all syntaxes. 

2) An XWiki instance will use a single syntax at a time. Once the database is created using that syntax it won't be possible to change it (except by doing an export and reimport).

We also need to decide what syntax we use by default OOB. I propose we use the current xwiki syntax for some time and then switch to the Wikimodel one (Common Syntax) later on.

3) All pages will be able to be exported to any syntax. Some elements have no equivalent in other syntaxes and when this happens a warning will be displayed and the elements in question ignored.

4) Mikhail has agreed to modify wikiModel to add macro block recognition.The syntax isn't fully defined yet but it'll be something like:

{xxx param1=value1 param2=value2}

...

{/xxx}

(param1='value value' and param1="value value" will also be supported)

This means we'll be able to have a common syntax for xwiki's macros and also for groovy code:

{groovy}

...

{/groovy}

And also for HTML blocks:

{html}

...

{/html}

5) We need to decide if we want:

A) No velocity block but document properties/metadata to tell xwiki to render the page using velocity. A user putting velocity code in a page will have to check a box somewhere to say that this is a velocity page.

Pros:

* Slightly easier to enter velocity code

Cons:

* Exception case compared to groovy, macros, etc

* User must not forget to check the checkbox saying the page contains velocity code

OR

B) Velocity blocks same as what exists for groovy/macros/html, namely:

{velocity}

... velocity code with wiki syntax allowed

{/velocity}

Note1: For B) we would allow putting wiki syntax inside the velocity block. Technically we'll apply the velocity rendering and then re-apply wikimodel on the result.

Note2: For backward compatibility we can have a config flag (xwiki.compatibility = 1) that automatically adds the {velocity}{/velocity} marker around the whole page. The only downside is that it'll be as slow as it currently is (actually it'll be faster since wikimodel is going to be faster than radeox)

Pros:

* Speed. Since we know the blocks that use velocity we can cache all the wiki syntax not inside the velocity/macros/groovy blocks which will speed up considerably the rendering of pages

* Consistency with macros and groovy blocks.

My preferences goes to B) and I'm proposing to use that.

6) Mikhail is going to add support for recognizing XML tags in the wikimodel parser so that onOpenXmlTag()/onCloseXmlTag() events are called in listeners). This is needed for point 7 below.

7) We need to allow intermixing velocity/HTML and wiki syntax easily.  For this our listener (the code that listens to {velocity} events) will evaluate the content using velocity and will call wiki model again on the resulting code. Since wikimodel requires HTML to be in a block ({html} for us) we'll use a different wikimodel listener that intercepts the onOpenXmlTag/onCloseXmlTag so that it'll output XML tags with no modifications (the standard HTML listener generates &lt; and &gt; for < and >). This will allow writing:

8) Documents are stored in textual format in the DB (i.e. as the user sees them). Portions of them will be cached after they're rendered for the first time (see option B above for the best caching option).

Are you ok on these points and especially about using the 5B solution?

Anything else I've forgotten?

If we agree, then my next steps are:

* Understand the wikimodel API in more details

* Understand the doxia API too (it's a "competitor" to wikimodel). The reason is that I'd like to see two implementations to ensure that the XWiki Interfaces can be implemented using different implementations so that XWiki is independent of the underlying rendering/parsing framework used. Jason Van Zyl is also interested in implementing the doxia part for XWiki in the future.

* Propose a XWiki API

* Propose an integration path

* Implement it using WikiModel

Thanks

-Vincent