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. > > 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
