On Tue, 2003-06-03 at 22:29, Joerg Heinicke wrote: > 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.
I agree that this should be fixed in the htmlserializer. Dropping startPrefixMapping and endPrefixMapping is a rather dirty solution though. > 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. > The above two reasons still make it valuable, even if only for debugging purposes? I think that if we make this purpose clear in the documentation, then there's no problem. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
