On Tue, 2003-06-03 at 15:28, Torsten Knodt wrote: > On Tuesday 03 June 2003 09:38, Bruno Dumon wrote: > > BD> TK> We have a current problem, that cocoon is not useable in many cases, > BD> TK> because it's nearly impossible to create valid (x)html. > BD> And again I'm wondering why? Of the tree reasons given earlier: > BD> AC> 1) As a fix for the "the namespace problem" > BD> AC> 2) When human-readable HTML output is needed > BD> AC> 3) To validate the output to a dtd > BD> only number 1 really causes problems, the others are merely > BD> conveniences. Those are important too, but don't make it "impossible to > BD> create valid (x)html". > The second is helpful to debug your output and the last is helpful to ensure > you output valid code.
yeah yeah, I agree with that, and for that purpose the tidyserializer is very valuable. I was only wondering if there were any blocking bugs in the normal htmlserializer that make it impossible to generate valid html (next to the namespace problem). (I'll look into applying the tidyserializer.) > BD> I'm not opposed to a tidyserializer. I'm just figuring out why I would > BD> use it. > To make it affordable to have valid html output. Problem is, you can do it > actually, but it's to much work. You have to use a xml formatter, to read the > output and see whats wrong. You have to validate the output to see if it's > valid. Is there any other way to validate the output then by validating it? > You have to do xalan "tricks" to remove unneeded namespaces. ... > Tidy is a temporary (I hope that xalan does the job some time, because I'd > like to have it for wml and others too) If "the job" means that Xalan should validate the serialized xml against the DTD it references, then I think it's a pretty save bet to say that will never ever happen. > "solution" for these problems. > For me it works much better than the existing HTMLSerializer, that's why I > sent it to the BTS. When you don't have these problems so far, or have > another way or a better way to solve them, you don't need it. Indeed it's > better not to use it, as it eats performance. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
