cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Suggestion for XHTMLSerializer
Date Mon, 08 Aug 2005 21:10:52 GMT
Joerg Heinicke wrote:
> On 08.08.2005 21:30, Vadim Gritsenko wrote:
> 
>>>> Completely wrong. If you find a 1:1 relation between a svg and a 
>>>> bitmap, go
>>>> ahead man, you're rich. For me a svg serialization is not 
>>>> reversible, you
>>>> loose layers, labels, structure and of course scalability.
>>>
>>> Man, 1:1 does not mean that you can go in both directions!
>>
>> You just proved Eric's point.
> 
> In which way?

XSLT serialization (as per spec Eric quoted) provides a way for "one way 1:1 
transformation" of xml into the desired view format exactly in the same way as 
batik transforms svg into png. XSLT has more capabilities, one even might say 
that it allows for arbitrary xml transformations - but another will say that's 
exactly the transformation he needs for his view.


> Furthermore there were reasons for not using xsl:output information, but 
> putting it into serializer component declaration. Shall they no longer 
> be valid?

Design of the Cocoon components does not force you into using xsl:output 
instruction. Moreover, you are encouraged to split up your transformations into 
multiple logically separated stages, some of them transforming xml data and some 
of them applying view, layout, etc details, (and some of them even doing LDAP or 
SQL DB lookups) and finally, you have an option to serialize this xml into the 
output format of your choosing.

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.

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.

Vadim

Mime
View raw message