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
