Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: Re: TidySerializer
From: Bruno Dumon <bruno@outerthought.org>
To: cocoon-dev@xml.apache.org
In-Reply-To: <3EDD051A.8030504@gmx.de>
References: <84F0A43A4248CE45B5C0E20F4C40779C34C3E1@naomi.webworks.nl>
	 <200306021757.53626.torstenknodt@datas-world.de>
	 <1054625891.32336.1441.camel@yum.ot>
	 <200306031528.49333.torstenknodt@datas-world.de>
	 <1054669561.8641.60.camel@yum.ot>  <3EDD051A.8030504@gmx.de>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1054676539.8642.85.camel@yum.ot>
Mime-Version: 1.0
Date: 03 Jun 2003 23:42:19 +0200
Content-Transfer-Encoding: 7bit

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
bruno@outerthought.org                          bruno@apache.org