Another option of course is an "overall light weight, read only, optimized
for speed not flexibility" DOM. This is something high on our list of
things to do. Certainly it wouldn't be spec compliant, but for many of
these types of apps, it wouldn't matter and speed and memory usage would be
far and away the most important concerns.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 03/22/2000 09:58:47 AM
Please respond to [EMAIL PROTECTED]
To: "'fop-dev@xml.apache.org'" <fop-dev@xml.apache.org>,
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: SVG goes to DOM
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.
