AC> 1) As a fix for the "the namespace problem" AC> 2) When human-readable HTML output is needed AC> 3) To validate the output to a dtd
Hmm, all 3 reasons are not strong enough for adding a further serializer with almost the same functionality IMHO.
1: A solution for the HTMLSerializer was discussed (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer provides a better solution, but I guess this can be adapted too.
2: Human readability is as you say for debugging reasons. This needs not to be done on live systems. We use IMO a better way: on the last transformer step we add a label="format". We access a page in debugging mode via test.html?cocoon-view=format. The view "format" is simply a further transformer step using format.xsl and the XMLSerializer. The different between live and debugging mode is the URL, not the sitemap. And there is no need for second component.
3: Also only for debugging, isn't it? Validating every request on live systems is too much resource consuming. And what do you want to do on live systems when a validation error occurs? A message "We can't deliver the page, because it's not valid HTML"? But you have other possibilities, e.g. using http://validator.w3.org/ or a mix of Jakarta commons httpclient with Tidy as we did. If you integrate this in a test system you can validate your pages automatically.
Joerg
