> From Vadim and Eric: Many (most?) serializers are not reversible and > therefore there should be no prohibition on yet another seemingly useful > serializer based upon XSLT and its output element. >
In fact, if i try to summarize this thread, we are just talking about implementation language. From now java was the only language for writing serializers. With a TraxSerializer (you're right vadim, this name would have certainly avoid all this XSL crispation :-) you can write them in XSL. A Trax Serializer, is much more isolated from object model than a java one, so don't tell me that they could encourage abuses. You play with the sax stream in a java serializer and trax one in the exactly same (it's just simpler, and the risk of stream corruption is lower with xsl). For some things you cannot just use existing serializer (characters-map). Serialization in xsl 2.0 is feature rich, and it would be a pain and a waste of time to reimplement them. And if you can stand the src attribute on the serializer, just define a virtual serializer in such a manner that <map:serialize type="xsl" src="serialize/xhtml.xsl"/> become <map:serialize type="clean-xhtml"/> in your pipelines. We use a traxserializer on our project since 2 months (as sylvain pointed out), i'm totally happy with it, and if enough people want it i can make a last effort to cleanup and format it accordingly to the cocoon project base rules. Regards.