
On 4/26/06, MenTaLguY <mental@...3...> wrote:
On Wed, 2006-04-26 at 15:11 -0400, bulia byak wrote:
I just don't see why that simple solution might be inadequate.
Just to pick one issue:
The more we store complex structures as flat attribute strings rather than XML nodes, the more of the tree machinery (parser, AST, updates, etc...) we have to redo for that special case.
SVG paths use attribute grammar and work just fine.
Why? Because they are flat.
XML is good for hierarchical structures. I do not foresee any hierarchy in a chain of sequentially applied effects, each with its own parameters. The attribute may become long, but d= is often long too, so that's not a problem.
As for updates, updating only one of a chain of effects may potentially be useful, but this looks a lot like premature optimization to me, at this stage. It's much better to optimize this via a smart PathEffect class which only rebuilds path if it's given params different from those it had before. And at first, it will be perfectly OK to just rebuild the whole chain whenever the attribute changes.
So, I remain opposed to the approach involving non-SVG child elements. IMO it's a case of overengineering, and given the general fragility of our XML tree, it's much more trouble than it's worth.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org