cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Milan <>
Subject RE: [Moving on] SAX vs. DOM part II
Date Wed, 26 Jan 2000 22:39:35 GMT

-----Original Message-----
From: Stefano Mazzocchi []
Sent: Wednesday, January 26, 2000 3:28 AM
Cc: John Milan; Clark C. Evans; Ted Leung
Subject: Re: [Moving on] SAX vs. DOM part II

> Donald Ball wrote:
>> points well taken. i have my opinions, and i know that they're right, but
>> i see your point. so ignore my suggestion of supplying layers with

> I agree with scott. The DOM may not be perfect but _lots_ of people are
> trying to address the problems we are facing now and Apache is -NOT-
> (and probably should never be) a standard body of any kind. 

I believe the DOM should be maintained as part of Cocoon to leverage the
work of lots of people. Furthermore, it's not as if Apache exists in a
vacuum. Whereas Apache cannot officially address standards body issues,
Scott, myself, and other W3 members certainly can. It won't necessarily
be a smooth process (and what is!:), but DOM will evolve-- iterators and
filters are a step in the right direction, and they've already
got DOM level III requirements going.

Plus, as far as irony goes, would anyone really want a scenario where Apache
creates a YATBXA, and Microsoft adheres to standards?

> This work
> simply requires very different skills, and, let's be honest, it's a
> black art of politics and compromises. Something I _TOTALLY_ hate.

> There are very very very few people that can be spec leads, great guys
> and awesome developers at the same time.

> And I'm not between them, that's for sure: of course, I'm a dork! :)

Well, you're a well-spoken dork, at least :)
>> so far, it seems that pier's suggestion of SAX preferred for transport
>> between layers/filters, with the option of DOM access at the layer/filter
>> level is winning the voting. if so, what's the next series of steps to
>> take?

> I'd like to hear more comments from John. Do you think something like
> the outlined above could fit with what you have or what you have in
> mind?

Yes, I believe so. I share Scott's concern that including support for both
complicates the architecture, but some of the demands we will be making on
this system are complicated. For instance, at the 10,000 foot level, we
require read, 
write, and query ability. We don't require that every page support these
abilities. In some cases read and query is fine, in other cases we must have
write. In my mind, this translates to: "In some cases SAX is fine, in other
cases we must have DOM."

Finally, to throw one more loop on the coil, I believe there might be a
of DOM and SAX as the request is handled and turned into a response (I
on this in another email). Therefore, any SAX=>DOM and DOM=>SAX support is
mandatory. Now, this certainly opens a door for performance issues-- 
but I want enough rope to hang myself.

John Milan

View raw message