Hi Vincent, Thanks for the reply. See bellow:
Vincent Massol wrote: > Hi Florin, > > On Feb 20, 2009, at 4:43 PM, Florin Ciubotaru wrote: > > >> Hi devs, >> >> Due to some critical bugs and missing features, the release was >> postponed for a long period. >> >> Still the development process is way ahead of what was intended for >> XWord 1.0 >> This is how the old roadmap looked like: >> http://dev.xwiki.org/xwiki/bin/view/Design/MicrosoftOfficeAddin#HFirstversion >> >> As you can see XWord 1.0 was intended to be an export to wiki tool and >> only XWord 1.1 should enable editing wiki pages. >> Sorry for not keeping you up to date on the mailing list. >> This is the new roadmap for XWord: >> - 1.0 M1 >> > > What is the release date planned for 1.0M1? > 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. > >> - Wiki Explorer - done >> - Attachment Upload - done >> - Attachment Download - done >> - Export word documents - done >> - Edit/Save wiki pages - done >> - Save pages with user specified syntax - done >> - Protect essential pages from editing - done >> > What is this? > 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. > > >> - Export using filtered html - done >> > > Isn't this already done by the Office importer HTML cleaner? We'd need > to find ways so that you can reuse this to prevent code duplication > (and it's a complex domain). > 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. > >> - Export with non-filtered html - buggy >> - Deployment and infrastructure - problematic because it uses >> ClickOnce. >> - 1.0 M2 - 2-3 weeks from M1 >> - Solve as many reported bugs >> - Improve html filters >> - Introduce the XML-RPC communication mode >> > > What is this? Any advantage of using XMLRPC vs REST? (I don't have a > preference but since we have both I'm wondering). > 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. > >> - Basic macro support(prevent the user from editing macro generated >> html) >> > > It looks like you'd be recoding what is currently existing in the > wysiwyg editor. While this is nice to have it in word, I'm wondering > what it's going to cost to maintain the 2 features. > 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. > >> - 1.0 RC1 - 1-2 weeks from M2 >> - Bug fixing >> - Stable and ergonomic UI >> - Remove the sever package and rely only on XML-RPC >> > > What is the "server package"? > 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/ >> - 1.0 Final - 1-2 >> - Rock solid UI >> - Production quality html output and wiki syntax conversion. >> > > If you succeed in using the server side version of html/wiki syntax > conversion tools then you'll get rock solid stuff with no maintenance > need on your side. > > WDYT? > 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. > Thanks > -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
