xml-dev - Re: SAX2: marrying SAX and DOM

[David Brownell <david-b@pacbell.net>]

> > > >     Event handlers should be passed a DOM node instead of
> > > >     positional parameters.
> > 
> > Seems to me that this is exactly what you'd get if you
> > listened for the right type of mutation events on the
> > root node of the DOM tree as it's being populated.
> > 
> > No new API needed -- DOM L2 has such callbacks today.
> 
> That's a good point, is the SAX API needed if a similar API exists?
> <me ducks="1"/>

;-)

Of course, that assumes you like DOM for such purposes, AND that
the DOM construction is transparent enough to ensure you can actually
do things like register for those event notifications.  The latter is
stuff that W3C hasn't touched, and I'm not sure I look forward to their
getting around to it at last.

And in any case, I agree with David Megginson on this:  keep SAX and
DOM separate.  SAX is lightweight, DOM isn't.  I want to choose if/when
to pay DOM costs, and to be able to use SAX features easily.


> The biggest difference I think would be that SAX (generally) would use
> "unattached" nodes in a push, start/end, mode.

Why unattached?

When I worked with a few such APIs, I ended up liking the model of
walking a partially constructed tree.  The point of having DOM was to
see the "context", including inherited attributes (like "xmlns*" and
all of the "xml:*" ones we've yet seen) and structural contexts.

With aid of a helper thread, it can be made to look more like a DOM
L2 "node iterator" that fleshes itself out in the background.  "Async
load" as it were.  Basically a glue class (or two) -- APIs that aren't
SAX, and aren't DOM, but use both.

- Dave




***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************