On Monday 02 June 2003 13:24, Alexander Schatten wrote:
AS Is this the solution, posted on the Wiki? If not, please could you
AS provide the solution, though, as mentioned already several times, this
AS is only a workaround, no solution in my opinion.
First, it's in the Wiki since some seconds as
Alexander Schatten wrote:
Again: if there is no one having time or capabilities to fix it, it is
clear to accept this in an open source environment, but legacy format
is *definitly* no argument.
Ok, perhaps you are right on my characterization of HTML. But my
emphasis was not on legacy format
On Mon, 2003-06-02 at 14:33, Alexander Schatten wrote:
Bruno Dumon wrote:
Nice, but an overkill for Alexander who simply wants all namespaces to
be removed, which could be done streaming. And preferably immediately in
the serializer, instead of another transformation step. The Xalan people
At 08:57 AM 6/2/2003, you wrote:
Seem not convinced? HTMLserializer that generates wrong output does not
convince the programmer? I mean, I can understand, if there is nobody
who has time or the capabilities to solve this bug, but not beeing
convinced sounds a little strange to me.
Don't
Why not just add a parameter which removes them or not, big deal. No reason
for Yet Another Class.
-Andy
On 6/2/03 9:34 AM, Geoff Howard [EMAIL PROTECTED] wrote:
At 08:57 AM 6/2/2003, you wrote:
Seem not convinced? HTMLserializer that generates wrong output does not
convince the
On Mon, 2003-06-02 at 15:34, Geoff Howard wrote:
quote-from-wiki
So... what I ended up doing was extending the HTMLSerializer (or whatever
serializer you're using for your pipelines), and overriding the
startPrefixMapping and endPrefixMapping methods to do nothing, effectively
removing all
Ah, excellent point. Actually, this is what I was thinking - honest!
At 10:01 AM 6/2/2003, you wrote:
Why not just add a parameter which removes them or not, big deal. No reason
for Yet Another Class.
-Andy
On 6/2/03 9:34 AM, Geoff Howard [EMAIL PROTECTED] wrote:
quote-from-wiki
So... what
Geoff Howard wrote:
I have done exactly this before -- does this still work from a purely
technical perspective? If so, why wouldn't we just define an
NoNsHTMLSerializer which extends HTMLSerializer and overrides
just those two methods? Then, it's a user decision whether these
namespaces
Andrew C. Oliver wrote:
Why not just add a parameter which removes them or not, big
deal. No reason
for Yet Another Class.
Why provide an _option_ for people to output invalid HTML?
Seriously, isn't it _always_ a bug to output namespaces in the HTML? What
are the use cases for HTML +
Conal Tuohy wrote:
Andrew C. Oliver wrote:
Why not just add a parameter which removes them or not, big
deal. No reason
for Yet Another Class.
Why provide an _option_ for people to output invalid HTML?
Seriously, isn't it _always_ a bug to output namespaces in the HTML? What
are the use
At 08:02 AM 6/3/2003, you wrote:
Conal Tuohy wrote:
Why not just add a parameter which removes them or not, big
deal. No reason
for Yet Another Class.
Why provide an _option_ for people to output invalid HTML?
Seriously, isn't it _always_ a bug to output namespaces in the HTML? What
are the use
Bla bla bla bla submit a patch bla bla bla bla
-andy
On 6/3/03 8:02 AM, Alexander Schatten [EMAIL PROTECTED] wrote:
Conal Tuohy wrote:
Andrew C. Oliver wrote:
Why not just add a parameter which removes them or not, big
deal. No reason
for Yet Another Class.
Why provide
I would agree with you Alexander - it's a bug for the HTML Serializer to
output other namespaces ... IMHO the HTML Serializer should log an error if
you give it any namespace except the XHTML namespace and the null namespace.
Post it in bugzilla and someone will fix it (maybe you? :-)
Con
On Monday 02 June 2003 09:49, Alexander Schatten wrote:
AS However, revisiting the problem (also watching websites others create
AS with Cocoon), I have to realize, that leftover namespaces are very
AS usual; e.g. the following: SQL, i18n, XHTML also others, that have
AS nothing to do with HTML
Torsten Knodt wrote:
On Monday 02 June 2003 09:49, Alexander Schatten wrote:
AS However, revisiting the problem (also watching websites others create
AS with Cocoon), I have to realize, that leftover namespaces are very
AS usual; e.g. the following: SQL, i18n, XHTML also others, that have
AS
On Mon, 2003-06-02 at 13:14, Torsten Knodt wrote:
On Monday 02 June 2003 09:49, Alexander Schatten wrote:
AS However, revisiting the problem (also watching websites others create
AS with Cocoon), I have to realize, that leftover namespaces are very
AS usual; e.g. the following: SQL, i18n,
Bruno Dumon wrote:
Nice, but an overkill for Alexander who simply wants all namespaces to
be removed, which could be done streaming. And preferably immediately in
the serializer, instead of another transformation step. The Xalan people
seem not yet convinced though.
Seem not convinced?
Hi Alex,
Alexander Schatten wrote:
Bruno Dumon wrote:
Nice, but an overkill for Alexander who simply wants all namespaces to
be removed, which could be done streaming. And preferably immediately in
the serializer, instead of another transformation step. The Xalan people
seem not yet convinced
At 08:48 AM 6/2/2003, you wrote:
Hi Alex,
Alexander Schatten wrote:
Bruno Dumon wrote:
Nice, but an overkill for Alexander who simply wants all namespaces to
be removed, which could be done streaming. And preferably immediately in
the serializer, instead of another transformation step. The
Emmanuil Batsis (Manos) wrote:
I'm not convinced either. HTML is a legacy format. Most of us only use
it instead of XHTML when we need to brake it anyway (via custom
elements etc).
(1) HTML is definitly no legacy format in my opinion
(2) even IF HTML would be a legacy format, the serializer
Geoff Howard wrote:
XHTML is the domain of the xml serializer, not the html serializer
which exists for people
who need to output that legacy format. Why is this tied to Xalan?
precisely.
Alex
-
To unsubscribe, e-mail:
Geoff Howard wrote:
At 08:48 AM 6/2/2003, you wrote:
I'm not convinced either. HTML is a legacy format. Most of us only use
it instead of XHTML when we need to brake it anyway (via custom
elements etc).
XHTML is the domain of the xml serializer, not the html serializer which
exists for
22 matches
Mail list logo
