BURGHARD Éric wrote:
1. I was talking about the concept, not implementation details. And from
that POV a stylesheet should not influence the pipeline. IMO It's plain
wrong to set the output format in the stylesheet.
2. But yes, I was missing the most important point in your approach
thinking that any stylesheet in the pipeline can have influence on it.
If you encapsulate the stylesheet in the serializer like it is done now
as you wrote there is no problem with it. But from what I understand you
want to provide "public access" to it, meaning that anybody can change
the stylesheet to adapt the output. Here the approach gets wrong again -
how will you prevent doing more stuff in the stylesheet than just
serialization with some cleaning up? It is made to easy ... The standard
tasks like "getting rid of alien namespaces" can be encapsulated. You
should not provide any access to the stylesheet. And then it should not
be called XSLSerializer, but something like
MoreSophisticatedXMLSerializer - however you will call it.
I certainly miss something, but i don't see the point. I don't see how this
could be used to break the actual pipeline design. With the XSLSerializer i
write
<match pattern="...">
<generate src="..."/>
<serialize type="xsl" src="serialize/xhtml.xsl"/>
</match>
I agree with Joerg here; by providing the author with the ability to use
any .xsl for serialization, you're allowing the serializer to control
not only how the model is serialized, but to modify the model itself
(which is the role of transformers). This essentially removes the
distinction between transformer and serializer, so if a serializer is
just another transformer why have it at all? That's how it breaks the
pipeline design.
It seems what you'd want instead is to enhance the XML/XHTML/whatever
serializer(s) to accept parameters to control all the XML serialization
options authors might want. For example:
<serialize type="xml">
<param name="cleanup-namespaces" value="true" />
<param name="replace-entities" value="true" />
<param name="indent" value="true" />
<!-- etc -->
</serialize>
Anything that modifies the actual model should go before the
serialization stage as a transformer.
Now, if it turned out that the best/most efficient way to implement the
above serializer was with an encapsulated XSLT file (not modifiable by
the author), then by all means do it that way, with the possibility of
changing the implementation later if something better came along.
I know this is a serialization, and i know that the serialization is
controlled by the xslt processor. As a pipeline architect i know that it
should serialize to xhtml, and as an xsl programmer i know where to look to
find the implementation details. I don't have to be a java programmer, and
absorb all that sax stuff and avalon life cycle to make my own serializer
which do some really complicated stuff efficiently like entities
replacement (with xslt2.0).
You shouldn't have to be an XSLT guru either. All you should have to
know is the sitemap configuration vocabulary.
You cannot prevent someone to do more complicated stuff (that just removing
ns) with this serializer, as you can cannot prevent someone to do bad and
complicated things with a pure java serializer, but with the former at
least i cannot produce a corrupted sax flow, which is better i think.
But providing an XSLSerializer greatly lowers the bar for doing those
more complicated things. Lowering the bar encourages abuse.
So as
an hardcore designer, i could even say that it's better to remove all the
java serializers and keep only the xsl one, but as an open source
enthousiast i will just say, please accept this poor litle xsl serializer
in the cocoon family :-).
Good luck re-implementing the svg2png or fop serializers in XSL. ;-)
As a beginner with cocoon, i was always disapointed when i put <xsl:output
indent='yes'/> in my stylesheet, and saw that the result was not indented
at all. Now that i know a little more on pipeline design, i really think
that the xslserializer could make all the experienced xslt programmers much
more comfortable with the serialization process in cocoon.
This much I agree with; if you come to Cocoon for the first time as an
experienced XSLT developer who is used to being able to use xsl:output
to control the output serialization format, it can be very confusing.
But as long as the same capability is offered by the serializer, and
it's well-documented, then it's not much of a problem.
