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: <200306021757.53626.torstenknodt@datas-world.de>
References: <84F0A43A4248CE45B5C0E20F4C40779C34C3E1@naomi.webworks.nl>
	 <1054568300.21067.1368.camel@yum.ot>
	 <200306021757.53626.torstenknodt@datas-world.de>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1054625891.32336.1441.camel@yum.ot>
Mime-Version: 1.0
Date: 03 Jun 2003 09:38:12 +0200
Content-Transfer-Encoding: 7bit

On Mon, 2003-06-02 at 17:57, Torsten Knodt wrote:
> 
> When TidySerializer would be in cocoon, more people would try it. And perhaps 
> there will be someone who cleans it up and adds SAX and DOM support.

That's right.

>  Also 
> perhaps someone integrates it into xalan.
> And for the namespace problem. Tidy hides it only for (X)HTML. It doesn't hide 
> it for WML, where you have the same. Everywhere where you have a DTD for the 
> output and using different namespaces during creation, you can have the 
> problem.
> We have a current problem, that cocoon is not useable in many cases, because 
> it's nearly impossible to create valid (x)html.

And again I'm wondering why? Of the tree reasons given earlier: 

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

only number 1 really causes problems, the others are merely
conveniences. Those are important too, but don't make it "impossible to
create valid (x)html".

>  With TidySerializer we would 
> have a temporary inofficial solution. There is also HTMLGenerator using jtidy 
> and noone says, we wait for the web pages to have valid (X)HTML.

While I do find this a false comparison (we don't control webpages, but
we do control what we generate in our pipelines), please understand that
I'm not opposed to a tidyserializer. I'm just figuring out why I would
use it.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org