cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Suggestion for XHTMLSerializer
Date Tue, 09 Aug 2005 00:03:31 GMT
Roy G. Biv wrote:
> Forgive me for jumping in, but people seem to be talking past one 
> another. I don't think you are talking about the same issue(s). Correct 
> me if I'm wrong.

I'm just arguing here - you are in better position to see what we are arguing 
about ;-)


> From Vadim and Eric: Many (most?) serializers are not reversible and 
> therefore there should be no prohibition on yet another seemingly useful 
> serializer based upon XSLT and its output element.


> From Joerg: An XSLSerializer (or TRAXSerializer) would require a src 
> attribute and so depend on something outside the sitemap for its 
> behavior. This is a question of side effects.

Not a criminal offence. Three easy steps:

   * Serializers are allowed to implement SitemapModelComponent
   * SitemapModelComponent has setup method
   * setup() method passes src parameter - src attribute from the sitemap.

Now, from Cocoon design perspective, this is all legal and supported. Question 
might be about best practices, but that's different discussion.


>> TraxSerializer does not break above design in any single place. It 
>> just gives you additional serialization option, which is, 
>> coincidentally, explores well documented and understood option of the 
>> XSLT specification, which is a plus in my book.
> That "well documented and understood option of the XSLT specification" 
> was categorically rejected when designing Cocoon 2.x.

Can you send a link to that?

> It was obviously 
> intended for standalone use just as processing instructions in XML to 
> determine the XSLT or CSS stylesheet. It is fundamentally at odds with 
> the Cocoon pipeline, as has been mentioned on the mailing list for years.

You can't use it in the transformer - true. It just does not make sense there.

>> TraxSerializer does not force you to put your final view xslt 
>> transform into the serializer. And I'd even discourage you to do it - 
>> as it, in some scenarios, reduces possibilities of reuse - but in some 
>> scenarios it'd be advantageous to add small xslt based serialization 
>> instead of writing yet another java serializer.
> Can you enumerate these scenarios?

IESerializer springs to mind ;-)

> What could you do for this that you 
> cannot do with a trax transformer followed by one of the existing 
> serializers? What advantage is there over, say, a virtual serializer 
> made up of an xslt transform and a serializer?

Thinking about it, ... I don't want my resuling (pre-serializer) XML to be 
polluted with implementation details/deficiencies of a particular browser 
(pda/phone/whatever). I want it to stay the same so I can re-use (via cocoon:) 

> Now, to add some more fodder to this discussion... Are there any other 
> serializers that rely on non-sitemap assets such as template files for 
> operation?

Two answers:
   * FOPSerializer takes xml config file.
   * What presense or absense of the example proves? (Hint: nothing).

> Wouldn't something like a TRAXSerializer 
> add side effects to the concept of sitemap serializers?

What would be the side effects? It's harder to implement side effects in XSLT 
than in custom Java serializer.

> Currently the 
> sitemap is as much a processing contract as it is a processor. By 
> looking at the sitemap pipeline, you can see what should be read, what 
> the schema/format is at each stage of the pipeline, and exactly what is 
> sent out.

As long as you know what components are you using do. As soon as you discover 
component not known to you, all bets are off.

> The svg2jpeg serializer is not 1:1 as Vadim and Eric have pointed out. 
> They are not equal. However, this does not invalidate Joerg's point. It 
> is a *completely different* point. A better, clearer statement is that 
> serializers are not 1:1 (to be clear, nothing in Cocoon 2 is) but rather 
> 1->1. There have been no end of emails equating reversibility (1:1) to a 
> processing anti-pattern. Currently, what you see in the sitemap 
> serializer declaration is what is output.

This is not correct, see below.

> Introducing a trax serializer 
> means that what you see in the sitemap serializer declaration is only 
> *part* of what is output. There is a huge difference between the two, 
> and I can see why Joerg was so upset.
> * The svg2jpeg serializer always requires SVG input and always provides 
> JPEG output -- including the mime type of image/jpeg.
> * The fo2pdf serizalizer always requires XSL:FO input and always 
> provides PDF output -- including the mime type of application/pdf.

FOPSerializer capable of producing PDF, PS, PCL, and (IIRC) more.

> * A hypothetical trax serializer would require a specific input 
> (elements that the stylesheet is expecting) but the output is...? HTML 
> sometimes, generic XML other times, etc.?
> It can't do it now, but what if someone writes an SVG-to-raster output 
> plugin to Xalan?

Why necessarily Xalan - it can be done in Java. Should we prohibit writing 
serializers in Java, then? Don't think so.

> Would it be acceptable or clear to have HTML sometimes, 
> generic XML other time, and a binary format still other times?

Yes. Quote:

      * Get the mime-type of the output of this <code>Component</code>.
     String getMimeType();

> Also, don't underestimate the value of having XSLT only in the middle of 
> a pipeline. Why? The sitemap maintainer can look at a pipeline 
> declaration and see that a stylesheet has specific input and specific 
> output. How so?
> <!-- My input source may be variable, but the output must match the next 
> link in the chain -->
> <map:generate src="myxml"/>
> <!-- The transformer must be written to the expected generator output. -->
> <map:transform src="schema1toSVG.xsl"/>
> <!-- The transformer must output the correct format, in this case SVG, 
> or the serializer breaks.
>     The serializer always expects SVG and always outputs JPEG. -->
> <map:serialize type="svg2jpeg"/>
> In that example, I can look at the sitemap and know exactly what's going 
> on.

That's good practice, which does not go away with adding new serializer.

> Compare this to a TRAXSerializer example:
> <map:generate src="myxml"/>
> <!-- The generator output must be exact or the XSLT won't match elements 
> correctly.
>     The serializer must be written to the expected generator output. -->
> <map:serialize type="trax">
>  <map:parameter name="xslt" value="stylesheet.xsl"/>
> </map:serialize>
> In the second example, I know what went in, but I have absolutely no 
> idea what happens to it unless I as the sitemap maintainer also know 
> XSLT as well. I am completely dependent upon the filename of the 
> stylesheet for a functionality hint.

Yes, you should here apply the same practice you used above:

  <map:serialize type="trax" src="schema1toxhtml.xsl"/>

But I'd not call it best practice - as I mentioned previously.

> It gets even more fun with stuff 
> like the following:
> <map:serialize type="trax">
>  <map:parameter name="xslt" value="cocoon:/stylesheet.xsl"/>
> </map:serialize>
> Let's take this to its logical conclusion. When would you ever want to 
> have the output type be dynamically assigned by the serializer 
> stylesheet?

When would you ever use something like this?


Having tools to do it does not mean you should do it. As they say, "Closed 
course, professional driver. Don't try it at home".

> After all, this is the *only* reason for TRAXSerializer 
> rather than an XMLSerializer with a specified doctype.

That usage scenario even never came into my mind. I wouldn't suggest it to 
anybody, and will talk you out of using it (at least - I'd attempt to :-)

> What is the use 
> case? If it's static and the stylesheet output type and mime/type never 
> changes, the only thing you've gained is a sitemap that isn't as clear 
> as to what was going on in the pipeline.
> Having the logic (XSLT stylesheet in this case) determine the processing 
> -- specifically the output portion of the sitemap process -- sends us 
> back to Cocoon 1.x, doesn't it? Is ProcessingInstructionTransformer far 
> behind where the processing instruction in the source XML stream 
> determines the stylesheet to use?

You missed it: it was proposed and discussed long time ago. Unfortunately ;-), 
nobody needed the beast strong enough to actually come around and implement it. 
The working name was "ReactorTransformer", or "C1Transformer".


> Don't kid yourself. That's what we're 
> talking about with a TRAXSerializer.
> I completely agree with Joerg.
> My $0.02,
> Miles Elam

View raw message