cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Suggestion for XHTMLSerializer
Date Mon, 08 Aug 2005 23:18:33 GMT
On 08.08.2005 23:10, Vadim Gritsenko wrote:

> XSLT serialization (as per spec Eric quoted) provides a way for "one way 
> 1:1 transformation" of xml into the desired view format exactly in the 
> same way as batik transforms svg into png. XSLT has more capabilities, 
> one even might say that it allows for arbitrary xml transformations - 
> but another will say that's exactly the transformation he needs for his 
> view.

 From the pipeline's POV it's not 1:1 as the serializer decides to which 
output format the XML is serialized, so it is 1:n, so the output is also 
not predictable for the pipeline.

> TraxSerializer does not force you to put your final view xslt transform 
> into the serializer. And I'd even discourage you to do it - as it, in 
> some scenarios, reduces possibilities of reuse - but in some scenarios 
> it'd be advantageous to add small xslt based serialization instead of 
> writing yet another java serializer.

Yes, I'm not forced to use TraxSerializer. Maybe I should withdraw from 
this discussion because it leads to nearly nowhere. Let's just add this 
component to Cocoon's codebase.

But IMO the codebase is already to big. There are so many components 
based on problematic approaches (SourceWritingTransformer, 
DOMSessionTransformer (both with side effects)) or widely unused (why is 
the TraxGenerator still in trunk after more than 2 years?). Why shall we 
add another component that's problematic (at least in my POV, see above)?

Joerg

Mime
View raw message