Description

This pages discusses what needs to be done to merge the current XWiki Rendering (v2.0), Doxia and WikiModel all under the umbrella of the XWiki project but as a top level project that can be used independently of the rest of XWiki.

• Code name: XWiki Babel
• Ambition: Become the de facto standard on the web when looking for a Rendering Engine
• Need: Remove fragmentation due to the fact that these 3 projects are at different locations instead of working together on the same codebase and thus create the best Rendering Engine on the web

Design

• Top level projet directly under http://svn.xwiki.org
• Can be used independently from the rest of XWiki
• Keep the current XWiki Rendering interfaces and packages
• Reorganize modules in the same manner as Doxia does it: 

xwiki-babel/
  |_ babel-api/
  |_ babel-modules/
    |_ babel-module-xwiki10/
    |_ babel-module-xwiki20/
    |_ babel-module-confluence/
    |_ babel-module-jspwiki/
    |_ babel-module-latex/
    |_ babel-module-itext/
[...]

• Move wikimodel common parser helper classes in babel-api (I don't think we need a separate module yet for this)
• Offer 2 APIs:
  • streaming api
  • block (DOM) api (the current xwiki rendering one)

Migration Plan

• Start refactoring current xwiki-rendering to match the design above as closely as possible
• Create modules in sandbox to start with (see Design above)
• Move wikimodel + current xwiki rendering there and merge them
• Once we have all the existing tests passing, release it and move it as a top level project
• Refactor current xwiki-rendering module to use XWiki Babel
• Add Doxia code to XWiki Babel (To be done by the Doxia guys?)

Open Questions

• Do we offer a streaming API?
  • I think so but then we need to have a special Listener that generate XDOM and the Transformation (and hence the Macros) won't be able to to be used when using the pure streaming API (but that should be ok I think). We could offer a second Macro API though that would be implemented as Listeners though.
• We need to get rid of the current dependencies with the rest of the XWiki modules
  • Do we keep the dep on xwiki-component, i.e. do we keep a component model in Babel? Since plexus is pretty much a set of beans we could simply add setters and constructors and keep them as components at the same time maybe. Need to check the API is fluid.
    • VMA: I've started working on this and the current idea is to make the beans usable as both plexus components and as simple java beans.
  • XHTMLRenderer: need to separate the link/image/attachment support which could be done as extension points (overriden methods)
    • VMA: Almost finished
  • Do we put macro implementations in Babel? Most macros will require external dependencies but also deps on other XWiki components. I guess we could put those that don't require deps in Babel and move those that require important deps in XWiki Core.
• What License? Do we keep LGPL or ASL?

TODO list while comparing Doxia Sink with XWiki's Listener interface:

• Add back onEscape event?
• Add onHeader - Non content information
• Add onBody - Content information
• Add onDate, onTitle, onAuthor
• Add an beginSection/endSection event and rename current begin/endSection events into begin/endHeader done
• Note: in Doxia whenever there's a text the text() event is called (for example even for an image caption). Do we want this or not? I think we don't want this but not sure.
• Add back onLineBreak event?
• Doxia defines a pageBreak() event. Do we want it? Check if we should add semantic properties instead (as in wikimodel) and use that for page breaks maybe?
• Doxia defines a nonbreakingspace event. Do we want it? (check where it's used). Answer is probably no.
• Doxia differentiates between text() and rawText(). Check why
• Doxia has a comment() event. Do we want it? Answer: maybe. Or it could be implemented using semantic properties
• Add unknown() events support
• Doxia has named parameters. Do we add this or do we leave untyped parameters as we have? The idea is that Listeners can have a list of well known params to support if they want. I think it' best to add them.
• Macros work similarly in Doxia as in XWiki so that's easy to convert. There's the notion of basedir I don't understand for Doxia macros though.
• Doxia has a notion of text vs xml parsers. Not sure we need it though.