On Wed, Dec 26, 2012 at 5:54 PM, Pavel Sanda <sa...@lyx.org> wrote: > Nico Williams wrote: >> future XML document conversions based on XSLT, I think once you familiarize >> yourself with XSLT you'll agree with me that it's much better and easier to >> use XSLT than to write C++ to do the same task. > > I no way I wanted to trigger religious war about the best language. My point > was that all we currently do WRT exporting to TeX or ASCII or XHTML or DocBook > is written in C++ within certain structures and logic. So if we are to export > to another, say XML, format we should stay within these concepts and not to > introduce different toolchain, for each new format. Reasons - maintenance > cost, > robustness, uniformity of code.
I don't care if you use Python (my approach) or C++. I want XML that is faithful to .lyx. Docbook is NOT useful to me. Neither is LyXHTML (and I've tried, and I've explained why they are not). I wanted to come to you better than empty-handed. I wanted to bring a proof of concept. I was hoping that my proof of concept would lead to something better than "try Docbook". I've also spent a while on lyx-users and posted there, asked questions, ... > We are on completely different ground if we start discussion about using XML > as > native format. I'm sceptic that your approach would be used, but that was just > IMHO, we use pythonic lyx2lyx creature right now after all. At the moment > there is no one who really works on this goal and as you could see yourself > there are even people who are against. I'm not proposing XML as the native format. > If I'm allowed to comment on your goals from inside-LyX perspective > my summary of the thread would be: > > 1. If the goal is the RFC-editor try DocBook route with specific insets > and some fixes in LyX code allowing metadata/biblio tweaks; in no way it > has > full power but it may be enough for RFC content. No, it doesn't. I've tried. I need more metadata than Docbook knows. Please either be much more specific about how to make Docbook meet my needs or accept my explanations for why it won't do. > 2. The goal is full round trip for XML. This is a sub-goal for various reasons. For example, so I can offer a method for importing *existing* xml2rfc source documents into LyX and then use LyX to do the remaining editing, then back to xml2rfc for final typesetting. (Of course I also want to do LyX->Lyx, expanding metadata in the process, to do final typesetting as well.) I also want to round-trip through XML for 3-way diff/merge purposes, but this is farther into the future. Everyone seems to agree that the minimal existing diff functionality in LyX sucks, so I'd think that the ability to apply existing XML diff/merge algorithms/tools would be attractive. > a) Creating tools using XSLT stuff to .lyx<->XML (thats what you do if I > understand correctly). Yes; see above. > My guess is that the final ouput is github project under your admin wings > and we provide support via configure.py or similar. I can live with this. I'd also like to see some rules for .lyx incremental evolution that make breakage of my script less likely (I filed a ticket for this; the rules are simple and not onerous, IMO). > If you are lucky then you gain enough people to let it flourish if you > are > not then it's non-compatible zombie after 10 years like we saw with > another > .lyx->X convertors. Sure. Except I would say you (the LyX community) would be the lucky ones. I'm only contributing this. Others will be the ones benefiting the most (I'll benefit too, that's true, but others will benefit more). > b) Changing .lyx to be native XML. I think the only way how to get 100% > faithful > and stable/robust conversion. That might well be nice, but I don't need this and I'm NOT asking for this, much less offering to implement this. lyx2xml should be useful for thinking about XML as a native format, but that's only a tangential matter for me. > You are entering minefield with many corpses around from past years, > prepare > for flames and ton of work with possibility that you would dump all you > did > up to now or even later... I'm bringing what I think is a fresh perspective. After the break (after New Year's) I hope others will consider it. In the meantime I'll be happy with configure.py support for my converters. Thanks. > Time for a beer :) Or wine :) Nico --
