cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arje Cahn" <A...@hippo.nl>
Subject RE: TidySerializer
Date Wed, 04 Jun 2003 10:33:51 GMT
> > 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
> bruno@outerthought.org                          bruno@apache.org
> 
> 

Mime
View raw message