> > BD> TK> We have a current problem, that cocoon is not > useable in many cases,
I think I just changed my opinion. I don't need a TidySerializer as desperately as I thought I did. What I need is HTML-valid (whatever that may be) output from Cocoon. I saw Jeorg rescue someone on the users list who's <script> tag got messed up. This issue has been going on for a long long time.. And I have the feeling a lot of users really don't understand this behauviour. I know it is fixed now - but it's not clear enough for users. It's probably a matter of time, but some Wikifying could speed the process [note to myself]. So that's done. Another inventory. 1) <script> tags are messed up 2) <style> tags are messed up 3) <textarea> tags are messed up 4) namespaces stick in the final HTML 5) dtd validity (for debugging purposes?) 6) human readibility These could all by done by Tidy; but with the extra overhead, and we shouldn't encourage this. ad. 1, 2, 3: [Joerg Heinicke] 2.0.5-dev and 2.1M3-dev: With both versions <script/> and <style/> are serialized to <script></script> and <style></style>. (same goes for textarea, right?). [NTM: Wikify] ad. 4: fix in the HTMLSerializer: TK> A little more would be necessary. You would have to map TK> all xhtml namespace to default prefix and remove the declaration. TK> All other namespaces would have to generate an error. I agree with this completely. But is this the same thing that you discussed with Vadim in august last year? (http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102865880018966&w=2). What was the final outcome back then? ad. 5: ....... [Conal Tuohy] ValidatingTransformer? ad. 6: ....... HumanReadableSerializer? - oops sorry; I meant TidySerializer :) So only the last point could be used as an argument for the TidySerializer? Sorry for this long post... But I need some clarity.. Arje > > 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] > >
