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 Sat, 06 Aug 2005 18:14:53 GMT
BURGHARD √Čric wrote:
>>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 certainly miss something, but i don't see the point. I don't see how this
> could be used to break the actual pipeline design. With the XSLSerializer i
> write
> <match pattern="...">
>  <generate src="..."/>
>  <serialize type="xsl" src="serialize/xhtml.xsl"/>
> </match>

I agree with Joerg here; by providing the author with the ability to use 
any .xsl for serialization, you're allowing the serializer to control 
not only how the model is serialized, but to modify the model itself 
(which is the role of transformers).  This essentially removes the 
distinction between transformer and serializer, so if a serializer is 
just another transformer why have it at all?  That's how it breaks the 
pipeline design.

It seems what you'd want instead is to enhance the XML/XHTML/whatever 
serializer(s) to accept parameters to control all the XML serialization 
options authors might want.  For example:

<serialize type="xml">
   <param name="cleanup-namespaces" value="true" />
   <param name="replace-entities" value="true" />
   <param name="indent" value="true" />
   <!-- etc -->

Anything that modifies the actual model should go before the 
serialization stage as a transformer.

Now, if it turned out that the best/most efficient way to implement the 
above serializer was with an encapsulated XSLT file (not modifiable by 
the author), then by all means do it that way, with the possibility of 
changing the implementation later if something better came along.

> I know this is a serialization, and i know that the serialization is
> controlled by the xslt processor. As a pipeline architect i know that it
> should serialize to xhtml, and as an xsl programmer i know where to look to
> find the implementation details. I don't have to be a java programmer, and
> absorb all that sax stuff and avalon life cycle to make my own serializer
> which do some really complicated stuff efficiently like entities
> replacement (with xslt2.0).

You shouldn't have to be an XSLT guru either.  All you should have to 
know is the sitemap configuration vocabulary.

> You cannot prevent someone to do more complicated stuff (that just removing
> ns) with this serializer, as you can cannot prevent someone to do bad and
> complicated things with a pure java serializer, but with the former at
> least i cannot produce a corrupted sax flow, which is better i think. 

But providing an XSLSerializer greatly lowers the bar for doing those 
more complicated things.  Lowering the bar encourages abuse.

> So as
> an hardcore designer, i could even say that it's better to remove all the
> java serializers and keep only the xsl one, but as an open source
> enthousiast i will just say, please accept this poor litle xsl serializer
> in the cocoon family :-).

Good luck re-implementing the svg2png or fop serializers in XSL. ;-)

> As a beginner with cocoon, i was always disapointed when i put <xsl:output
> indent='yes'/> in my stylesheet, and saw that the result was not indented
> at all. Now that i know a little more on pipeline design, i really think
> that the xslserializer could make all the experienced xslt programmers much
> more comfortable with the serialization process in cocoon.

This much I agree with; if you come to Cocoon for the first time as an 
experienced XSLT developer who is used to being able to use xsl:output 
to control the output serialization format, it can be very confusing. 
But as long as the same capability is offered by the serializer, and 
it's well-documented, then it's not much of a problem.

View raw message