Re: DOM in SVG implementations

Chris Lilley wrote:
> 
> It would be very helpful for the Document Object Model (DOM) working
> group to know of all DOM implementations  - in particular,
> implementations of (perhaps part of) DOM 2 - that are available, in this
> case for implementing SVG.
> 
> I know what XML parser some implementations use, in other cases I do
> not. In some cases, the DOM is provided by the XML parser or by the CSS
> parser (in the case of DOM2 CSS OM), in other cases a separate component
> is used.
> 
> I am calling on all SVG implementors to let me know which parts of DOM 1
> and DOM 2 they implement, or plan to implement in the coming months, so
> that I can report this back to the DOM working group. Implementation
> feedback (this part hard to understand, not sure what that part is for,
> etc) would also be good at this time.
> 
> Responses should be sent to this list, or if desired can be sent to me
> privately at chris@w3.org.

Gill uses our own homegrown DOM implementation, Gdome. Our goals are to
be 100% core DOM1 compatible, and supply enough of the DOM2 functions
for our needs. Not all functionality is currently implemented. Gdome is
written in C (as is the rest of Gill - the SVG implementation page
incorrectly has it as C++).

My personal experience with DOM has been fairly negative so far. When I
started Gill, I was fairly enthusiastic about DOM, and took the approach
of basing the entire implementation around it. However, we ran into some
problems. The event model in DOM2 (last I checked) has serious
limitations that prevent it being really useful for the
Model/View/Controller pattern. Thus, we're looking at having to
implement nonstandard extensions to DOM2 so that Gill can have a clean
MVC architecture.

In addition, DOM per se has lots of potential garbage collection
problems and some other Java-isms. For Gdome, we added ::ref() and
::unref() methods so that nodes could be reclaimed by reference
counting. Further, Gdome is based on UTF-8 rather than UTF-16 encodings.
We've played around with CORBA bindings (including, for example,
translating the encoding), but at this point don't feel that DOM over
CORBA is a good solution, due to the distributed garbage collection and
latency problems.

Hope this is helpful.

Raph

P.S. I know the Gill webpage is a bit out of date. However, development
is still going strong. Right now, I'm focussing on making libart (the 2D
graphics engine powering Gill) more robust. I'll be giving a talk on
Gill at Linux Expo Paris 3 Feb 2000, if anyone is interested.

Received on Friday, 3 December 1999 12:00:17 UTC