On Wed, Apr 10, 2013 at 7:46 PM, Pavel Sanda <sa...@lyx.org> wrote: > The project listed in GSoC intended 3) and perhaps fix 1. It wouldn't > be wise to create completely new export routines and my hope is that > routines in 2) can be reused in large part with perhaps few switches.
It might well be wiser to drop all the docbook and XHTML code, re-write it in XSLT and use XML as a go-between: it's much less C++ code to maintain that way. However, it is a trade-off, and it adds a language to know, and more files to maintain that might not obviously break the way C++ can sometimes obviously break when you make changes in one part of the system without corresponding changes elsewhere (but then, you can't really count on that, and you still have to test). > LyX->XML is very different issue, there was no intention to have LyX > exporting to XML, but to have LyX using XML as its native format. > This issue was discussed many times, slightly controversial > though I would think that most devs agree that one day we should > have this. > This would, however, be again native thing in C++, not pythonic > conversion. Where Nico's converter can be used one day as > a part of LyX is as a part lyx2lyx routine converting old > frozen .lyx format to the new XML one. Ah, yes, that was the argument: XML should be the native format. And LyX should load and save XML. If you want to work on native XML support, my script will give you some idea as to where .lyx deviates somewhat from XML concepts, so you can do something about it. Basically LyX mostly has layouts and insets that contain layouts and insets, and so on, and the containership is strict in most cases, the way it has to be in XML, but in some cases LyX has only markup instead of containership (e.g., sections) (this is OK) and markup with no proper "end tags" (text styling) (this is nOT OK in XML). To the extent that the .lyx format reflects the internals of LyX (and I think it does), you can start to see what changes you'd have to make to LyX to use XML natively. Or you could embed a native .lyx<->XML converter not unlike my python-based one and leave LyX mostly unchanged. > The pathway .lyx file --(python_beast)-->XML/whatever is somewhat > explosive material, has been flamed many times and I won't > repeat all what we have against it, read archives. > I seriously doubt you will find anyone willing to mentor this. Oh, hey, I don't remember that much drama. > If I haven't daunted you yet :), the critical part in my opinion is > to find out who is really willing to mentor 3 and what is exactly > to be done... My advice, Adrián: don't follow my advice here, because I'm not a LyX developer; you need to talk to them. Nico --
