cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy G. Biv" <>
Subject Re: Suggestion for XHTMLSerializer
Date Mon, 08 Aug 2005 22:40:54 GMT
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.

Vadim Gritsenko wrote:

> Joerg Heinicke wrote:
>> On 08.08.2005 21:30, Vadim Gritsenko wrote:
>>>>> Completely wrong. If you find a 1:1 relation between a svg and a 
>>>>> bitmap, go
>>>>> ahead man, you're rich. For me a svg serialization is not 
>>>>> reversible, you
>>>>> loose layers, labels, structure and of course scalability.
>>>> Man, 1:1 does not mean that you can go in both directions!
>>> You just proved Eric's point.
>> In which way?
> XSLT serialization (as per spec Eric quoted) provides a way for "one 
> way 1:1 transformation" of xml into the desired view format exactly in 
> the same way as batik transforms svg into png. XSLT has more 
> capabilities, one even might say that it allows for arbitrary xml 
> transformations - but another will say that's exactly the 
> transformation he needs for his view.

 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.

These are two separate and distinct design/implementation issues.

>> Furthermore there were reasons for not using xsl:output information, 
>> but putting it into serializer component declaration. Shall they no 
>> longer be valid?
> Design of the Cocoon components does not force you into using 
> xsl:output instruction. Moreover, you are encouraged to split up your 
> transformations into multiple logically separated stages, some of them 
> transforming xml data and some of them applying view, layout, etc 
> details, (and some of them even doing LDAP or SQL DB lookups) and 
> finally, you have an option to serialize this xml into the output 
> format of your choosing.
> 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. 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.

> 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? 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? What is the specific use 

Use cases that currently cannot be handled easily = excellent reason.
But "some scenarios" sounds like (dare I say it?) Flexibility Syndrome.

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? Batik uses AWT behind the scenes and the system fonts for 
example, but does this count? Wouldn't something like a TRAXSerializer 
add side effects to the concept of sitemap serializers? 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.

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. 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.
* 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? Would it be acceptable or clear to have HTML sometimes, 
generic XML other time, and a binary format still other times?

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. Compare this to a TRAXSerializer example:

<map:generate src="myxml"/>
<!-- The generator output must be exact or the XSLT won't match elements 
     The serializer must be written to the expected generator output. -->
<map:serialize type="trax">
  <map:parameter name="xslt" value="stylesheet.xsl"/>

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. It gets even more fun with stuff 
like the following:

<map:serialize type="trax">
  <map:parameter name="xslt" value="cocoon:/stylesheet.xsl"/>

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? After all, this is the *only* reason for TRAXSerializer 
rather than an XMLSerializer with a specified doctype. 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? 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