On Dec 23, 2009, at 10:46 AM, Krzysztof KosiĆski wrote:
Hmm. I am not sure I understand this. What I was thinking about was this:
[SNIP]
What I thought about is to remove this link, and not store XML in memory at all. Saving would be similar to rendering: we would ask each object to generate its XML representation, and write it to the output file. One benefit of this is that we can change the element that is being written easily, and we can solve the flowtext issue (the flowtext object would "render" to a switch containing both Inkscape editing data and normal SVG 1.1 text).
Yes, the aspect of having each and every class/object do it's own serialization is what breaks modularity. And trust me, the MS Word format is so poorly implemented that even Microsoft can't keep backward compatibility for long.
What we probably need is an in-memory tree that has runtime functionality and then a separate set of classes to do reading and another to do writing. So we can just feed a tree to a SVG11Serializer or a SVG12Serializer, etc. (Of course, given the complexity of SVG 1.2 and all the 'modules', we would probably have that serializer behind facade and factory patterns)