On Wednesday 23 July 2008 08:04:59 am Steve Litt wrote: > On Tuesday 22 July 2008 11:32, rgheck wrote: > > Steve Litt wrote: > > > I don't know how it will be after LyX goes XML, but right now at 1.5.3, > > > converting my LyX code to something else by parsing the LyX native code > > > would be trivial. This is probably teaching Grandma to suck eggs - but There is a very good set of XML utilities available in Linux which alloy you easily parse and transform .xml files into almost anything you want (using xslt, sax, and friends. In openSUSE it is called xmlstarlet and comes with the installation CDs or DVD. These should make it easy to translate to and from LyX (when it finally goes fully XML).
John O'Gorman > > > > My understanding is that, whatever happens with the LyX file format, we > > want it to remain possible to do the sort of simple scripting we all > > like to be able to do. The XML business is really just a matter of > > replacing things like this: > > > > \begin_layout Standard > > this. > > \end_layout > > > > \begin_layout Standard > > \begin_inset CommandInset bibtex > > LatexCommand bibtex > > bibfiles "/tmp/bib" > > options "plain" > > > > \end_inset > > > > > > \end_layout > > > > with things like this: > > > > <layout name="Standard"> > > this. > > </layout> > > > > <layout name="Standard"> > > <inset type="bibtext" latex="bibtex" bibfiles="/tmp/bib" options="plain" > > /> </layout> > > > > Just as easy to parse, I hope. Maybe even easier. > > > > That's not anything actually agreed or implemented.... > > It's not as easy to parse, but it's reasonable. If that's the extent of the > XMLization of LyX, it should still be somewhat tweakable with Vim, Perl, > etc. > > The real problems come in when they do things in XML that would be > denormalization in a database. Store the paragraphs one place, and then > store the *number of paragraphs* somewhere else, so if you add a paragraph > and forget to increment the number, your doc no longer opens. > > Or treating the XML file like a relational database, where you have a list > of styles with numbered IDs one place, and then have those numbers applied > to paragraphs somewhere else. This is an excellent programming technique, > but for the guy just trying to casually go in and tweak something, or > casually trying to programmatically generate LyX data, it can be daunting > indeed. Personally, I love having my style defs in the layout file and > using the style names as their identifiers. > > Then there's this habit of people like OpenOffice, where the native format > is a Zip file unzipping to different directories, each containing XML files > and other types of files. Yeah, I just dare anyone to generate OpenOffice > on the fly. > > I suggest that whatever you decide, you document the XML structure. I don't > mean document as in "it's open source, read the code". I mean document as > in "Here is the data hierarchy, here is the high level data design, here > are our reasons for doing it this way, here are the data interdependencies, > here are some tips for building LyX files programmatically and tweaking > them either programmatically or with an editor. And here is a tutorial on > building and tweaking LyX files without the LyX front end. > > I'm busy these days, but if you keep me in the loop I'll do at least a good > chunk of that documentation. > > One more thing -- if you're going XML and don't want to reinvent the wheel, > you'll be using someone else's XML parser. Please, please, PLEASE, don't > make it some parser with tons of dependency so that the guy with a 2 year > old distro can't compile LyX because of the XML parser. We already have > enough problems with Qt dependencies. > > Thanks > > SteveT > > Steve Litt > Recession Relief Package > http://www.recession-relief.US
