cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <>
Subject Re: Suggestion for XHTMLSerializer
Date Sat, 06 Aug 2005 14:30:41 GMT
Joerg Heinicke wrote:

> 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.

I believe what was discussed is very close to a "virtual serilizer". Is 
this a virtual component? If yes, then we call here about : "virtual 
serializer". A virtual serializer has optional transformers followed by 
a Serializer. See:

Some initial discussions about how to implement virtual components:

I hope this helps.

Best Regards,

Antonio Gallardo

> Joerg

View raw message