Hi Anca, Anca Paula Luca wrote: XWord is installable since December and it is available at: http://incubator.myxwiki.org/xwiki/bin/view/XWord/ The problem is that the it's deployment is not compatible with the common XWiki.org release process and infrastructure.

Hi Vincent, Thanks for the reply. See bellow: Vincent Massol wrote: This is not established. In terms of development XWord is ready for release. Manual publishing works fine, automatic doesn't. What we need to to is to see if OW2 can be used as a location for the clickOnce binaries and manifests. It also depends if you want CI before or after M1. This means that you cannot open in Word some specific pages that provide functionality to the wiki. Eg: The pages in XWiki, Stats or Blog spaces. Note: There is no api for identifying these pages. This was ok for XEclipse as it targets developers and wiki syntax editing, but in the case of XWord which is created for non-technical users, a method to protect these pages is required. Word can output html in two modes: filtered or not filtered. The filtered html size is about 10% of the not-filtered html, but it losses data from embedded elements(diagrams, shapes, expressions and charts). Additionally I created filters and adapters that are applied at different stages of the conversion. The steps are: Saving a document to the wiki: Word Supported Format -> WordML <-> HTML -> WikiSyntax Opening a wiki page: WikiSyntax -> HTML <- > WordML [-> Other format] The conversion from and into wiki syntax is done on the server. I can program against all the other data formats and set options on the transformation from one format to another. For this I'm using Word API or custom developed functionalities. IMO this has a better chance of success then a server oriented filter. Note that Word html is different from OOo html, so the filters that could be used for XWord are the filters implemented for the "Paste from Word" feature of the WYSIWYG. If we get these filters to provide high quality bidirectional saving and data preservation, then yes we can use then for XWord. XWord does not depend on a specific implementation for client-server communication. I can be easily changed. What is important is to have a fully featured API. I will create a separate thread for this. I'm only referring to making macro generated content read-only. IMO, this is not nice to have, it's mandatory, as without it, the user will damage every page that contains a macro. Marius: is this implemented on the server or on the client for the WYSIWYG? If it's on the server then it would be great to reuse it for XWord. :) If not, then I see no other option then to do something similar on .net. It's a collection of wiki pages that contain the services used by XWord. In the absence of a fully featured and actual api, velocity + groovy remains the most powerful way of extending or communicating with xwiki. See: http://incubator.myxwiki.org/xwiki/bin/view/XWord/ The html/wiki syntax is already done at the server. Sorry, but I'll give a -1 for Word html cleaning on the server, at least at it's current state.

Marius Dumitru Florea wrote: OK, thanks.

Vincent Massol wrote: Yes, first I also thought that view/edit rights should do the trick. But unfortunately, without macro support, edit right is too generic. For example it's ok to have edit right on a current page in the XWiki space end edit it in the wiki editor, but it's not ok to have edit rights and edit it with the wysiwyg/Word. See what I mean? What do you mean? The user should not be able to edit the macro in Word. What is wrong right now: The user is editing a wiki page with Word. This page contains a macro, let's say, toc. All he sees in Word is a list with links. When he will save the page to the wiki again, the toc will be overridden by the bulleted list. Yes, this should mostly go under xoffice.xwiki.org. Where do you think I should put the .net/vsto coding conventions, building, etc. Is it under dev.xwiki.org? By its' current state, I mean that it is only designed to work as an import filter. First: I need it to preserve embedded elements data. Second: I have the ability to force Word to output a different/better html then the one provided by copy/paste. I need the html cleaner to work well with this kind of output. Sure, I prefer to have a unified cleaner on the server. But there will always be filters/adapters on the client(not necesarely cleaners). For example: The 'src' and 'href' attributes have different values on XWiki and on a local html file used by Word. The user can open different edit sessions on multiple pages. Each session has an assigned html converter that uses filters for XWiki->Word and Word->XWiki conversion. Each converter has a number of dictionaries assuring the consistency of these attributes and the bijectivity of the operation. I prefer to have high cohesion on this and distribute it as less as possible.