cocoon-dev mailing list archives

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).