> I was not wondering, I saw your request exaclty as a "virtual > serializers" usecase. This is something we want to address for cocoon 2.2. >
Ok ;-). So 'Is this a virtual component ?' was not a question (i'm joking). Thanks for (re)joining this discussion. > I believe, I understand your point: "Process the lastest tranformation > with the (X)HTML serializer". It is OK. Note that ,as Joerg said, : "It > is only an implementation matter". Something that the virtual serializer > need to address. I am sure this will save us "one SAX event generation > step" in this special case. Yes of course. On our project, 90% of the pipelines are of that kind (finished by an xsl transformation). But it's not only to save one sax event generation which is, as joerg pointed out, an implementation detail. I'm not talking about implementation details but about xsl processor roles in the pipeline model of cocoon. In the xslt spec, you can read: "A processor may output a final result tree as a sequence of octets, although it is not required to be able to do so". For those processors which claim to conform to serialization feature, i see no reason to consider them only as transformers. xsl:output is optional but is part of the language and clearly defined in the specs. The method attribute is said to take many values, but xml,html,xhtml and text is a minimal subset. This feature is very well implemented in saxon8 (4 serializers in 1), it's normal for me to use it instead or with the regular serializers. For now, the XSLSerializer is the only way to do it. If we are agreed that transformation is a subset of serialization (i could serialize to sax but i could never transform to jpeg), then it will be clear for you as it is for me that xsl must be at least as expressive in the serialization world as it is in the transformation world. That's why you should not restrict an XSLSerializer to an internal stylesheet or to some 'well-choosen' parameters. > Agreed (see above). On the other hand, I think the suggested > XSLSerializer will requiere a XSL file with a <xsl:output> instruction? > How we will be able to reuse this XSL file in a tranformer? Thinking 5 > seconds, I see 2 posible solutions (I don't like none of them): > 1-Copy&paste the XSLT and remove the <xsl:output> tag for tranformer > usage. 2-Let the XSLTranformer ignore the <xsl:output> tag. > Can you have a better solution for that? > Currently in cocoon the xsltransformer implement 2. I find normal that xsl:output has no meaning in a transformer since it's related to serialization (again the idea of subset). What i found annoying is that there was no way for xsl:output to express itself. > I read you are tired of this discussion. Me too. It is not the best way > to discuss this topics by exchanging mails. But this is the only way we > can discuss right now. Please don't think we are just trying to reject > your suggestions at any cost. It is not the case. We are trying to give > you more information about how the things works, the next planned steps. > We are open minded and what we want the best for cocoon. ;-) > Yes me too (open minded i guess). Writing in english is a good exercise but a frustrating one too. I thank everybody for this discussion (joerg, jason, ...), forgive me all for my lack of patience ;-) Regards.
