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