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
