cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Suggestion for XHTMLSerializer
Date Sat, 06 Aug 2005 10:06:39 GMT
On 06.08.2005 11:03, BURGHARD √Čric wrote:

>>>I wrote a much more powerfull solution: the XSLSerializer, which let you
>>>control the serialization through an xsl stylesheet (an so use the
>>>xsl:output tag as well as some template rules to make final cleanup like
>>>namespace deletion or href contextualization). I need to do some cleanup,
>>>and i will submit a patch.
>>This is definitely the wrong approach and will probably be not accepted
>>for the official Cocoon codebase. The transformer influencing the
>>pipeline is like a component controlling the component container.
>>Additionally it makes no sense letting an intermediate transformer set
>>the serialization method for the end of the pipeline. What about an
>>I18nTransfomer after your stylesheet? Your approach also reduces the
>>reusability of the stylesheet as it is tied to a specific output format.
> In fact, you must check the source code, this the actual approach with the
> XMLSerializer. The serialization is done with the xsltprocessor but with an
> empty stylesheet. The serialization is controlled with the output
> parameters which are taken from the sitemap configuration blocks (tag names
> are in fact attributes names of xsl:output). So, if you look closer, the
> XSLSerializer is in fact an obvious evolution of the actual XMLSerializer:
> 1. what are the reason of enforcing the serialization method to 'xml'
> whereas xsltprocessor can do much more (no need to rewrite code in
> specialized serializer (XHTML serializer), it's already done),
> 2. why just giving an empty stylesheets to the processor instead of a more
> sophisticated one which could help for example to get rid of alien
> namespaces.
> And obviously, i'm talking about final transformation/serialization. If want
> to localise my templates, i could write some templates and use efficently
> the xsl:index to implement i18n:text and others in the final
> transformation, but i'm using the i18n transformer BEFORE serialization.

1. I was talking about the concept, not implementation details. And from 
that POV a stylesheet should not influence the pipeline. IMO It's plain 
wrong to set the output format in the stylesheet.

2. But yes, I was missing the most important point in your approach 
thinking that any stylesheet in the pipeline can have influence on it. 
If you encapsulate the stylesheet in the serializer like it is done now 
as you wrote there is no problem with it. But from what I understand you 
want to provide "public access" to it, meaning that anybody can change 
the stylesheet to adapt the output. Here the approach gets wrong again - 
how will you prevent doing more stuff in the stylesheet than just 
serialization with some cleaning up? It is made to easy ... The standard 
tasks like "getting rid of alien namespaces" can be encapsulated. You 
should not provide any access to the stylesheet. And then it should not 
be called XSLSerializer, but something like 
MoreSophisticatedXMLSerializer - however you will call it.


View raw message