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

[Peter Jentsch]

Hi Jan, 

sorry for responding late, work and life and everything else have been
keeping me busy. 


Am Mittwoch, den 05.01.2011, 16:32 +0100 schrieb Jan Holesovsky:
> Hi Peter,
> 
> Jan Holesovsky píše v Út 04. 01. 2011 v 11:13 +0100:
> 
[...]
> > 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.
> > 
Thanks!
 
> > 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
> > 
Done.
> > Purpose documentation: Can you please add a brief description of the new
> > classes in the header?  Just something like:
> 
Done.

> I looked mainly at the parts that are about defaulting to your
> implementation, or the Java xslt filter, and it looks good to me, so I'd
> push it as soon as you let us know regarding the license :-)
> 
> One more nitpick that I spotted is that you use { and } differently to
> the rest of the code base (we use opening { on a new line, and skip
> { and } if an if/for/while has only one command), would be great if you
> can change it too; but of course that is not a blocker for pushing your
> changes ;-)
> 

That's 10 years of Java. I now discovered Eclipse offers 4 different
formatting styles for source code and the GNU style seems to almost fit,
so I'm just formatting using that now.

> Also, is there a special reason for ListenerList l = m_listeners; on few
> occasions?  Didn't you want to use a reference?
> 
Again, Java. I changed it to be references now. 

> Thank you a lot,
> Kendy
> 
Hey, thanks!

I'd propose to proceed as follows: 

- Replace FlatXML Export with a pure XML Filter implementation based on
the SDK example.

@Gioele: my take on the flat xml export is that it's not meant to be
read by humans, but to be fed to some xml processor (like an xslt
transformer for example). So I'd suggest making the XSLT based flat xml
export an extension. But then again I've never been working with flat
xml export, so I might be ignorant of the most important usage
patterns ;-) What do you think?

Then...
- Come up with a better idea to control which implementation is being
used

- Add a libxslt based xslt validation service. 

I've dug a little bit deeper into the existing xslt filters and 3rd
party implementations of xslt transformations for OpenDocument and found
that the wordml/office 2003 xml export uses an xslt 2.0 script (although
I didn't check to what extent xslt 2.0 features are actually beeing
used. It may well be possible that the script can easily be rewritten to
use libxslt's EXSLT functions. But it might as well be not ;-)
As long as I don't figure wether that's possible with reasonable effort
it doesn't make sense to touch the Java implemented Saxon extension
functions.

Text Encoding Initiative (TEI) also uses XSLT 2.0 for their filters
since 2009, so maybe we'll have to keep the java/saxon implementation
around for a while. But maybe it'll be possible to make it an extension,
so the default filter implementation shipped with LibreOffice doesn't
require Java at all. 

And, ah, the patch. I'll prepare that... Ok.

So, thanks again for having a look at the code, and I'm looking forward
to further hacking on this :-)

Cheers, 

Peter



> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice