cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <>
Subject Re: [Moving on] SAX vs. DOM part II
Date Tue, 25 Jan 2000 04:40:03 GMT
Donald Ball wrote:
> I concur. We need SAX for fast transport between layers and DOM access
> routines for use by layers if the layer prefers to work in DOM. How hard
> could this be? The algorithm seems to be pretty simple.

It's fairly trivial if you convert a whole pack of SAX events (from
startDocument() to endDocument()) into a FULL DOM tree. It gets a little
bit trickier (just a little bit), if you want to have only fragments of

I have this document:

<image width="100" height="100" background="#000000">
  <layer method="multiply" opacity="100%">
    <text x="10" y="20" color="#ffffff">
      Print this!
  <layer method="multiply" opacity="100%">
    <text x="11" y="21" color="#999999">
      Print this!

I can imagine that the <image> and the <layer> stuff are handled
directly using SAX events, but I want to pass a DOM fragment (an Element
and all that is included into it) to the object handling the <text>

I'm about to complete it, and the implementation will be in CVS

> If a layer knows
> that it's going to be accessed by DOM, then it could just catch incoming
> SAX events and store them in a list. If and when DOM access occured, you'd
> wait for all SAX events to com in and then either just scan through the
> list looking for nodes or turn the list into a tree. Events would be sent
> out either as incremental processing was done (for SAX processors), or the
> node tree would be serialized as SAX events once DOM processing was
> complete (unless you know the next layer wants DOM access, in which case
> you could maybe just pass on the DOM object.

Yep... The only thing is that both processors (the idea was to call them
Filters, am I right?) are DOM-based, we'll end up building two DOM trees
for the same stuff. The biggest problem (right now) seems to be XSLT,
but I bet that Scott will come up with something nice...

> (sorry to be so pedantic, but I'm trying to convince myself as much as
> anyone else)


> Although, you know, it's not DOM that my processors might want so much,
> anyway, but a _good_ tree-based API. Personally, I think DOM is a poorly
> designed API and that one could do much better (hell, we could even come
> up with the new de facto replacement for tree-based XML API).

I share your opinion on the DOM API, I wouldn't did it in that way, but
those are personal ideas. Anyway I do understand that right now DOM is a
standard, and it's more or less supported everywhere. Designing another
would be overkilling, and the task of porting already built components
from DOM to "our nice dom" would be a too big task.
The best thing is "just stick with SAX" :)


-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<>    <>
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <> --------------------

View raw message