The SVG representation is completely stored in the DOM. Every read or write access is done via DOM. Only to write or load an SVG file, the parsers and writers convert DOM to SVG or vice versa. The XML editor shall also use DOM, which reduces the editor complexiticy a lot. Internally, every DOM setter invokes a libsigc++ event, whose callback is defined in the event dispatcher module. Then, a renderer function (updateRendering or so) is called. A parameter containing a reference to the changed element ensures, that only the required area is updated.
Blue: already implemented, but not ready
Black: not yet working
Red: can be done later
The w3c standard makes it possible to distribute the lot of work, because the DOM implementation is predefined. The developers just need to decide which conventions are used, e. g. for getters/setters.
1) implement the DOM
1) standalone SVG/CSS writer/parser module according to the w3c functions
1) modify renderer
2) event dispatcher (only a few ones are required to work)
3) merge everything together and make compilable
4) switch the rest to the new architecture (everything in the category “manual editing” + preference handling)