JH In conclusion:
JH 1. We need a patch for the HTMLSerializer for the namespace issue.
JH 2. A validation transformer seems to be really welcome.
JH 3. For human readability we do not need really a new
JH serializer. What about the indent parameter on the serializer
JH (like indent in
Arje Cahn [EMAIL PROTECTED] wrote:
Another inventory.
1) script tags are messed up
2) style tags are messed up
3) textarea tags are messed up
I assume you mean the empty version of these tags? In that case don't
forget to add iframe tags are messed up...
1) script tags are messed up
2) style tags are messed up
3) textarea tags are messed up
4) iframe tags are messed up
I just checked and these are all fixed in Cocoon 2.1M3-dev.
Arje
On Tuesday 03 June 2003 23:46, Joerg Heinicke wrote:
JH For debug output I normalize-space every text node and simply indent
JH them by counting the ancestor nodes. This has no influence for HTML,
JH because HTML normalizes text nodes too (exception: pre/).
Right, would be enough for html. And
In conclusion:
1. We need a patch for the HTMLSerializer for the namespace issue.
2. A validation transformer seems to be really welcome.
3. For human readability we do not need really a new serializer. What
about the indent parameter on the serializer (like indent in
xsl:output/)? At the moment
On Wed, 2003-06-04 at 21:09, Joerg Heinicke wrote:
In conclusion:
1. We need a patch for the HTMLSerializer for the namespace issue.
2. A validation transformer seems to be really welcome.
3. For human readability we do not need really a new serializer. What
about the indent parameter on the
Bruno Dumon wrote:
On Wed, 2003-06-04 at 21:09, Joerg Heinicke wrote:
In conclusion:
1. We need a patch for the HTMLSerializer for the namespace issue.
2. A validation transformer seems to be really welcome.
3. For human readability we do not need really a new serializer. What
about the indent
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
Torsten Knodt wrote:
On Tuesday 03 June 2003 09:38, Bruno Dumon wrote:
TK We have a current problem, that cocoon is not useable in many
cases, TK 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
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
On Tuesday 03 June 2003 21:46, Bruno Dumon wrote:
BD yeah yeah, I agree with that, and for that purpose the tidyserializer is
BD very valuable. I was only wondering if there were any blocking bugs in
BD the normal htmlserializer that make it impossible to generate valid html
BD (next to the
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
On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote:
JH 1: A solution for the HTMLSerializer was discussed
JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer
JH provides a better solution, but I guess this can be adapted too.
A little more would be nercessary. You would have to
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
Torsten Knodt wrote:
On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote:
JH 1: A solution for the HTMLSerializer was discussed
JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer
JH provides a better solution, but I guess this can be adapted too.
A little more would be
On Tue, 2003-06-03 at 22:19, Torsten Knodt wrote:
On Tuesday 03 June 2003 21:46, Bruno Dumon wrote:
BD yeah yeah, I agree with that, and for that purpose the tidyserializer is
BD very valuable. I was only wondering if there were any blocking bugs in
BD the normal htmlserializer that make it
-Original Message-
From: Torsten Knodt [mailto:[EMAIL PROTECTED]
Subject: Re: TidySerializer
On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote:
JH 1: A solution for the HTMLSerializer was discussed
JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer
JH provides
Joerg Heinicke wrote:
Ok, reason accepted :) But what about an extra validating
transformer as
last pipeline step? Seems to make more sense IMO.
YES! This could be VERY useful: a transfomer that could validate the output
of some pipeline stage against a DTD or other schema could be a great
On Tuesday 03 June 2003 23:48, Bruno Dumon wrote:
BD TK BD If the job means that Xalan should validate the serialized xml
BD TK BD against the DTD it references, then I think it's a pretty save bet
BD TK BD to say that will never ever happen.
BD TK I hope it removes not allowed and not needed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 04 June 2003 00:09, Geoff Howard wrote:
GH TK JH 1: A solution for the HTMLSerializer was discussed
GH TK JH (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer
GH TK JH provides a better solution, but I guess this can be
On 4 Jun 2003 at 10:28, Conal Tuohy wrote:
Joerg Heinicke wrote:
Ok, reason accepted :) But what about an extra validating
transformer as
last pipeline step? Seems to make more sense IMO.
YES! This could be VERY useful: a transfomer that could validate the
output of some pipeline
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
map:transform type=dtd-validator
map:parameter name=dtd value=dtd/stage-1.dtd/
/map:transform
Or, perhaps
map:transform type=dtd-validator src=dtd/stage-1.dtd/
/Adrian
Any e-mail message from the European Central Bank (ECB) is sent in good faith but
shall neither be binding nor
On Monday 02 June 2003 12:57, Arjé Cahn wrote:
AC Torsten, am I missing something? Have I forgotton why we needed it? What
AC are your reasons to implement a TidySerializer?
AC I'm sure I had my reasons to need the TidySerializer; but I simply forgot
AC them.
My problem where unreadable XML/ HTML
to the left (aargh?!).
Bruno?
Regards,
Arje Cahn
-Original Message-
From: Torsten Knodt [mailto:[EMAIL PROTECTED]
Posted At: 02 June 2003 15:21
Posted To: Cocoon Dev List
Conversation: TidySerializer
Subject: Re: TidySerializer
On Monday 02 June 2003 12:57, Arjé Cahn wrote:
AC
On Mon, 2003-06-02 at 17:05, Arjé Cahn wrote:
I'm using the TidyUI standalone from the Tidy sourceforge community
(http://tidy.sourceforge.net/), which is very good, but the JTidy port has been
abandoned - how awfull!
But the namespace problem - that was one of my reasons, too.
When
On Monday 02 June 2003 17:05, Arjé Cahn wrote:
AC When should one use the TidySerializer?
AC ---
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
It doesn't really validate
On Monday 02 June 2003 17:38, Bruno Dumon wrote:
BD What I wanted to avoid though is that problems with the normal HTML
BD serializer (like the namespace or textarea problem) would be hidden by
BD jtidy, and that users would be pointed to the tidyserializer as the
BD solution for these problems.
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
AC Bruno?
BD You expect me to give my blessing or so? I don't really care that much
BD about it all. Arguments 2 and 3 are reasonable, and certainly
BD have their uses.
You dropped the question (and I had my doubts too), so I tried to sum up the pro's and
asked for your opinion. Blessing
Bruno says:
What exactly is the purpose of a tidy serializer again?
I was fiddling around with Tidy and noticed that I couldn't get the textarea/
problem solved with it.
[The textarea/ problem: an empty textarea (formtextarea//div) is serialized to
formtextarea/form which results in a loss of
On Mon, 2003-06-02 at 12:57, Arjé Cahn wrote:
Bruno says:
What exactly is the purpose of a tidy serializer again?
I was fiddling around with Tidy and noticed that I couldn't get the
textarea/ problem solved with it.
[The textarea/ problem: an empty textarea (formtextarea//div)
is
Bruno,
There was a (Xalan) bug for this:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15715
Ah! I'll re-check it - according to Torsten (Curdt) it should be fixed. We're running
M1; I need some time to check M2.
Arje
33 matches
Mail list logo
