cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <>
Subject Re: Suggestion for XHTMLSerializer
Date Sun, 07 Aug 2005 14:54:13 GMT
BURGHARD √Čric wrote:
> If you look at the core components, no one follow such a hard constraint.
> Some serializers do radical transformation (svg2jpeg, links, ...), while
> some transformers only do very light transformation (encodeurl, i18n, ...).
> If you take the links serializer for example you will find that the output
> is radically different than the input (and this is a serializer). If you
> take the svg2jpeg serializer you will see that the ouput is just a "view"
> of the input, because apart the file format "radicalisation", a lot of
> information disappear during the convertion from vectors to bitmaps. So i
> could perfectly do a silly xsl serialization that only display the root tag
> name of the input (it still a view of my input) and call that a
> serialization.

I was not familiar with the LinkSerializer, so I took a quick look at 
it.  Your point is well taken here; this serializer appears to be an 
anomaly.  It acts like a transformer, but happens to do out.println() as 
its output instead of SAX events (to be fair, it actually *does* produce 
SAX events as well, but those events appear to get swallowed.)

I'm getting a tad off-topic here, but IMO this "serializer" would be a 
better fit, and far more useful, as a transformer.  For instance, what 
if I wanted to serialize the extracted links as a PDF document instead 
of text, or run another transformation on them before serializing? 
Having the link extraction transformation and serialization combined 
together does not allow this.

As far as svg2jpg, I don't see your point.  Every last bit of the SVG is 
taken into account when producing the bitmap representation.

View raw message