On 01/13/2010 01:36 PM, José Matos wrote:
- how to proceed in the mean time?
+ using an iterative approach we will have a file that will be xml-ized by
parts
I think the incremental approach will actually be much less intrusive
than it might at first seem, and some of it, not necessarily all, could
perhaps be done starting now, even if we were in feature freeze. I've
done major changes to the LyX-file representation of certain
insets---e.g., the entire InsetCommand hierarchy---and it's actually
quite painless. You change the read routine; you change the write
routine; you write some lyx2lyx; you are done.
The real question I have is whether the incremental approach, though I
have suggested it myself, is actually workable. I was just thinking, for
example, how easy it would be to change the format of InsetCommand-type
insets to XML, and that maybe I'd make a patch, just to prove the point.
But then I thought: How will these XML insets be parsed? There's a whole
ton of code in InsetTabular that does XML reading and writing, since the
file format of InsetTabular is at least XML-like, if not true XML.
Perhaps that could be moved to support/ and used in the interim. Or can
we use an XML parser just to parse the parts that have been converted to
XML, once we find them? Anyway, I'm not clear about this. Maybe the
first suggestion, of moving some custom code to support/, makes the most
sense. Then when we have a real XML format, we can get a real parser.
- what to do with math?
Aren't math insets strangely simple? I.e., all of the form:
\begin_inset Formula $here lies a LaTeX formula$
\end_inset
or:
\begin_inset Formula \[
here lies a LaTeX formula\]
\end_inset
If so, then just something like:
<inset type="formula" display="true">here lies a LaTeX formula</inset>
seems like enough. The math itself of course hasn't been XML-ized, but
maybe that's a different goal.
rh
