cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricardo Rocha" <>
Subject RE: [Moving on] SAX vs. DOM part II
Date Mon, 24 Jan 2000 08:32:58 GMT
Stefano Mazzocchi wrote:
> Ok, but what is this discussion about?

> Niclas Hedhman wrote:
> Exactly!!  The biggest 'problem' with Cocoon is that its purpose is not
> exactly specified.

Pier Paolo Fumagalli wrote:
> IMVHO the purpose of Cocoon is very well specified. Cocoon is an XML
> publishing tool, and by "publishing" I mean the act of creating
> web-sites (regardeless wether on-line, through HTTP, or off-line,
> shipped on a CD-ROM, and regardeless wether your browser is a cellphone
> or acrobat reader).
> What you're asking, to bring Cocoon in the EMail world, basically, is,
> IMVHO toally wrong. This idea wasn't born without a deep research. We
> (Stefano and I) were the one who proposed EMail Servlets, and understood
> how their model was wrong. We faced the same issue while designing
> JAMES, the Java Apache (E*) Mail Server.
> . . .
> Before going on, anyway, I would like to hear comments from all you
> others out there, because, if the majority of you agree that "this is
> the way to go", I will have to accept it.

I completely agree with Pier Paolo.

While Cocoon does have the potential to be used for a wide variety
of web-based applications, I think its web publishing nature may
become "polluted" by trying to make it fit too many, possibly
conflicting requirements.

That said, there's a lot in Niclas' proposal that makes sense and is
consistent with preserving Cocoon's identity while providing stronger
support for application development.

A point where I tend to disagree with Niclas (unless I have missed
his point) is in the convenience of applying multiple successive XSLT

> I find a lot easier to make small XSLT sheets that each do a single
> simple thing, than trying to incorporate all transformations in a single
> sheet. It also makes stylesheet re-use and establishment of XSL
> libraries easier. Therefor I have the multiple stage XSL
> transformations as a basic feature.

[Btw, this description fits the mechanism used for applying XSP libraries
and I find it acceptable in the context of (one-time) code generation]

When it comes to document processing, though, such an approach
can become prohibitively costly. We can always retain the reusability
and modularity of multiple, small stylesheets and yet achieve good
performance by means of stylesheet inclusion/importing.

A related and very interesting direction Scott Boag has pointed out
is that of stylesheet compilation: if we translate stylsheets into
bytecodes the "prohibitive" cost I mention above would become less
of a problem (I'd stick to stylesheet inclusion/importing, though!)

This last consideration also has important implications in the area
of XSLT-based dynamic XML generation: you always require at
least 2 passes for that. This is probably the only case where you'd
forcefully have 2 XSLT passes: one for dynamic XML generation
(using extended elements and functions) and one for presentation.

View raw message