Dear Developers, I've been following this conversation from the shadows, but I had one thought that they be relevant.
I think everyone agrees that we want to avoid reimplementing the internal logic of a LyX document. While thinking about what might be the best way to implement a converter, it occurred to me that it might be worthwhile to implement the converters as clients that are able to use a LyX server session. For export, the server could load a document, provide data about inset and paragraph contents, and the client could then convert the logical representation to docx or odf. For import, the process might work in reverse. The importer reads in the data from the document, translates it to a logical format that could be consumed by the server, and the server creates a new document. Document internals remain internal to LyX, while the server-client communicate over a well-defined protocol to interactively build the document. If I understand the LyX server pipe, it is already possible to retrieve information about insets, citations, cross-references, and other document components. Moreover, there are only a few properties for a particular type of inset (ID, text, meta, etc.), which provides a manageable way to handle output data. Might it even be possible to export the data for a particular inset in a serialized key/value format? This would allow for insets without a good output format to main their data as DOCX/ODF metadata which could be faithfully translated back during import. As I've followed the pandoc conversation, I've been concerned about the introduction of another dependency. If the import/export tools can be kept to LyX and some processing script, that seems easier to maintain than a complex chain of tools and external dependencies which we don't control. Just my 0.02. Cheers, Rob
