BURGHARD Éric wrote:
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.
You seems to forgot the main distinction between a serializer and a
transformer. A transformer process sax events and generate sax events,
whereas a serializer ends a sax flow, and that's what the xsl serializer is
doing. I don't see where it breaks the pipeline design.
If you look at existent transformers, quite a few of them could potentially
modify the model (sql, xmldb, writeDOMSession, ...). IMHO this is not the
right angle to compare serializers and transformers roles.
I also happen to dislike that pattern, but it's unrelated to the current
discussion.
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.
I don't understand here. How could i modify a model with an xsl
transformation (and by extension an xsl serialization) ? XSL is for
generating views from a sax representation of a model (not to be confused
with the model itself. It's generated at the beginning of the pipeline by
the generator). As far as you don't write nasty java extension to your
processor (do you really need xsl for nasty java ?), i don't see how you
can achieve such side effects with xsl (ie writing to your DB which IS the
model).
Perhaps I overused the term "model". I was referring more to the
_Document_Object_ Model (DOM) represented by the various stages of the
SAX stream. A generator creates one DOM, a transformer converts that
DOM into another, and a serializer takes the DOM resulting from the
final transformer and creates a representation of it. It does not
modify that DOM.
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.
sorry, "not modifiable but with the possibility of changing later" seems
confusing for me.
By this I simply mean that there are many ways you could implement the
behavior we're talking about (control over the serialization details
like indentation, collapsing certain elements, etc.) One possible way,
which IIUC the current XMLSerializer uses, is to use an internal XSLT
stylesheet. But certainly there are other ways, and it may turn out
that using XSLT is not the most efficient, so you could conceivably
change the implementation to achieve the same behavior.
But the important thing is that using an XSLT internally is merely an
implementation detail. Exposing the XSLT implementation to users is
what Joerg and I take issue with. (Don't mean to speak for you here,
Joerg, correct me if I'm misquoting you.)
But providing an XSLSerializer greatly lowers the bar for doing those
more complicated things. Lowering the bar encourages abuse.
Here i understand that things must stay complicated just to frighten new
users ;-). I just need some sleep.
Now now, don't twist my words.
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.
I was not experienced before cocoon, but XSL is far more documented than any
of a single cocoon component so guess where is my best skill today. All
variant of XHTML Serializer failed to handle correctly some empty tags like
<inputarea/>, <div/>, or <script/>. This is much of a problem that
motivated this thread.
Those are absolutely bugs that should be fixed in the current serializer(s).
