cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Suggestion for XHTMLSerializer
Date Sun, 07 Aug 2005 10:24:37 GMT
On 07.08.2005 10:53, BURGHARD √Čric wrote:

>>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.
> You see here that a serializer actually do a transformation. The only
> difference is that the resulting transformation always take the form of sax
> events in a transformer (eventually followed by some side affects: sql,
> xmldb, ...), and is a final transformation which could take many different
> forms with a serializer (binary, zip, text, jpeg, xml, ...).

Of course serializers do transformations, you already wrote it: from SAX 
to bytes. But there is one important difference: The behaviour of a 
serializer (and at the end the output) is absolutely predictable. If you 
feed the same SAX events into a specific serializer you will always get 
the same result.

If you need some modifications to the XML stream, just add another 
transformer. If you need to influence the serialization process, just 
configure your serializer component declaration. If the serializer's 
configuration does not offer all configuration options, fix the 
serializer implementation. But don't mix transformation and 
serialization. Or in other words: Until now the usage of the empty 
stylesheet in the serializer is a transparent implementation detail. 
Your approach will make it a mixture of transformation and serialization.

And to come back to Antonio's absolutely correct interjection about the 
virtual serializers: This is the point were you can put together again 
the above mentioned additional transformer steps and the standard 

>>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.)
> I'm not exposing the xslt implementation. There is other way of hiding
> implementation than compiling and encrypting a stylesheet in a java class.
> Users should not access the files of your webapp (this is webapp/container
> security), designers should not modify core stylesheets (this is repository
> security).

I don't see your point here.


View raw message