Alex Vergara Gil wrote: >> Do you mean a native LyX file format which would be the primary format, >> or an auxiliary format for interfacing with external tools? > > I mean xml as primary format.
Well, I wanted to know what Richard meant, but your opinion is welcome as well;-) > If you have xml as primary format you doesn´t need anymore to change the > format, just the content which can be dinamically added as xml is self > descriptive, so you doesn´t have the problem of format changing, new > features can be added as new self described objects. So a conversor must > handle only with xml objects, and of course older versions may not be > fully compatible with new features but they would still be able to read > most of the files created with newer versions. Moreover a converter can > handle insets, figures, etc in a more robust way if they are grouped into > xml objects. I mean the objects it can interpret it can handle with them, > and those who cannot well put as text or metadata as you wish, but it > would still be readable. OK, so you mean by static something else than I thought: A format that has some standard ways how the contents is formatted, but it would not forbid new stuff, e.g. a new inset. This is something we have more or less already (of course not in XML, but an inset is inbetween \begin_inset and \end_inset, its parameters use a standard form as well etc). This is of course possible and desirable. My point is that any converter which should be part of a reliable export or round trip must be written for a specific version of the LyX (native or intermediate) file format. This is also true for XML based formats. They make it easier to handle unknown stuff gracefully and have a lot of other advantages, but if you want to really understand stuff and export it to a different format, then you need additional knowledge which you only have if you know the version. Let me give an example: Suppose an inset has a parameter named "foo" which can take two different values: "0" and "1". Now some LyX developer extends the inset so that it can be used in different ways, and this requires to tweak its parameters. The result is that the parameter "foo" can now be one of the four values "a", "b", "c" and "d". The old value "0" is 1:1 equivalent to "a", the old value "1" becomes either "b" or "c", depending on another setting, and the new value "d" has no equivalent old value. Now assume that this is an important inset that is converted to some object in the output file of the converter. If the converter now gets the new format, how should it know how to handle the new values? Of course it could ignore them and assume some default, but this would result in a less accurate conversion. If you feed it the correct file format version, then all goes well. Therefore I am pretty sure that any conversion which would operate on a file produced by LyX (native or intermediate, XML or not) needs to be written for a specific version of this file format, and if the format evolves there should be a way to convert the newer versions into the one expected by the converter (either using something like lyx2lyx, some XSLT transformations or whatever is suitable). Otherwise you need too much guessing, and this does not work (the tex2lyx predecessor reLyX proved that). Georg
