> 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 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 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. 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 :-). 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. It's not a virtual serializer, it's a full serializer component that can only be used as a serializer in a virtual serializer. Regards.
