Steven Coffman wrote: If SVG is going to be DOM based, rather than treated as a special case form of XSL:FO, then that immediately says, "Xerces" to me. Should an implementation of the W3C's SVG DOM be part of Xerces? Does that allow us to do anything cool? Should it continue to be part of FOP? If so, how can we be consistant with the Xerces stuff?
-------------- I don't think that there should be any SVG specific code in the Xerces DOM implementation. That said, if you were able to create a SVGDOMDocument that could override the constructors of NodeImpl et al you might be able to allow anyone to create extended DOM's without cutting and pasting the existing DOM code. On kind of a related and not fully fleshed out thought, the xml-dev list recently had a discussion on pros and cons of SVG's use of long attributes for path data. One of the key performance issues that swayed the decision for the attribute form was that if the path was described as elements, the DOM grew so large that memory use and performance were unacceptible. In effect, the switch from XML representation to a "microparsed" representation was a way to "trick" the DOM not to fully expand the document to objects. The SVGPathData interface is then an attempt to gain some of the lost functionality. Basically, that suggested to me that if you were able to hint that at a certain place in the document, a flyweight implementation of Node were used (child content was held as a single string, flyweight implementations of Node, Attribute were mapped onto the string on use), you could have the best of both worlds, keep the XML representation and DOM access while avoiding the memory bloat of fully expanding the tree.
