[Libreoffice] [PATCH] De-Java-ise flat XML export

[Jan Holesovsky]

Hi Peter,

On 2011-01-03 at 21:06 +0100, Peter Jentsch wrote:

> I'm attaching a patch I somehow managed to patiently pull out of git :-)
> 
> As I'm new to C++, libxslt, git and a few other things involved in
> creating the patch I feel it must be full of warts and cause random
> crashes, but it seems to work and might be useful anyway.

Thanks a lot - looks great on the first sight :-)  Let me look a bit
better (unless somebody else volunteers to do a deeper review?) now.

Before pushing it to the master branch, I'd like to ask you for 2
things:

License: Please, do you agree to license under the MPL / LGPL / GPL
combo, as recommended in
http://cgit.freedesktop.org/libreoffice/build/tree/COPYING.NEWFILES

Purpose documentation: Can you please add a brief description of the new
classes in the header?  Just something like:

/**
The Reader class has to be a separate thread because of this and that.
*/
class Reader: public osl::Thread
{
...
}

[So - don't describe the obvious facts, just higher level / design
decisions.]

> Basically, the patch provides an alternative service implementation
> to be used by XSLTFilter.cxx. Use of the libxslt implementation can be
> triggered by adding "libxslt" as second parameter to the "UserData"
> configuration of an xslt filter. This second parameter is currently
> unused for xslt filters. 
> 
> To completely remove the java dependency for xslt filters, the
> xsltvalidation service would also need to be replaced by an
> implementation based on libxslt. 
> 
> Also, the Office 2003 XML export filters use a saxon extension
> implemented in Java, which needs to be replaced by a libxslt extension
> if Office 2003 XML export should be supported without Java, too. 
> 
> The flat xml export could be implemented as a pure C++ xml Filter
> indendendently of the xslt filter, as proposed in the SDK examples, I
> suppose, and I'd like to do that next. 

In fact, this perfectly fits as the documentation - so I think it would
be enough to paste most of this mail to the appropriate places.

> I personally like the idea to make the implementation to use
> configurable, instead of completely removing the Java based xslt filter
> implementation. 

The problem then is that we would have 2 things to maintain; so I think
it is better to go with your implementation, and get rid of the Java
implementation for good.  [But of course, short term we can live with
both, no problem with that.]

Thank you a lot,
Kendy