cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
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 ;-)


<snip/>

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

True.


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

<snip/>

>> 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:) 
elsewhere.


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

   http://localhost:8888/samples/sources/xsp/all-dynamic

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

Vadim


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

Mime
View raw message