Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 24203 invoked from network); 21 Apr 2004 19:22:32 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 21 Apr 2004 19:22:32 -0000 Received: (qmail 91459 invoked by uid 500); 21 Apr 2004 19:22:18 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 91405 invoked by uid 500); 21 Apr 2004 19:22:17 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 91385 invoked from network); 21 Apr 2004 19:22:17 -0000 Received: from unknown (HELO mail.gmx.net) (213.165.64.20) by daedalus.apache.org with SMTP; 21 Apr 2004 19:22:17 -0000 Received: (qmail 11477 invoked by uid 65534); 21 Apr 2004 19:22:21 -0000 Received: from a183069.studnetz.uni-leipzig.de (EHLO gmx.de) (139.18.183.69) by mail.gmx.net (mp027) with SMTP; 21 Apr 2004 21:22:21 +0200 X-Authenticated: #3483660 Message-ID: <4086C9EB.3080006@gmx.de> Date: Wed, 21 Apr 2004 21:22:19 +0200 From: Joerg Heinicke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en-gb, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Serializers issues... References: <40857026.1080105@gmx.de> <9A1CAFDA-930A-11D8-B622-000393C27E0C@betaversion.org>

In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On 21.04.2004 20:44, Pier Fumagalli wrote: > We were looking at it monday morning with Jeremy, and we have ben unable > to get to the point where you were (took us roughly 2 hours round and > round the configs)... > > Took me 30 minutes to patch up the Garbage serializers, and another hour > to put it into a nice block, making sure it built and so on... > > The problem was that when we fixed something somewhere (on some browser) > it broke on another, and so on and so forth... With the Garbage > serializer that doesn't happen, and we can go on with the development. The pragmatic programmer :) What I have indeed *not* done was testing it in every browser. You seemed to focus on the validness, so I have looked only for this. >>> And it's scary that in our welcome XSLT we specify a META tag with a >>> charset and content type... Means that (probably) someone found that >>> bug beforehands and patched it with the XSLT... >> >> But isn't this only due to insufficient browser capabilities? IMO it's >> ok if an >> XHTML does not add the meta tag. Only those stupid browsers that >> ignore the xml >> declaration! > > ????????? I'm talking about this tag found in the XSLT for the home page > of our distro (welcome.xslt): > > Yes, I know. And I refered to the comment written above it. What I meant was if the encoding is given through the XML declaration there is no further need for the meta tag. But the spec states that both xml declaration and meta tag must be included while the xml declaration takes precedence (http://www.w3.org/TR/xhtml1/#C_9). > If I change the serializer configuration (for example, change encoding > to ISO-8859-1, I don't like UTF-8) that tag will be copied across to the > output, and the browser will panic. > > That tag MUST be written by the HTML serializer (or XHTML > serializer), and must NOT be encoded in an XSLT in a pipeline, as > pipelines use char(s) and not byte(s). Of course, the possible araised problems are obvious. >>> Why they're not fixed in there? Because I'm not smart enough to look >>> into XALAN itself, and (IMVHO) that thing of xsl:output was wrong in >>> the first place anyway (and that's what XALAN is relying on)... >> >> >> You mean the output options should not be under control of the >> stylesheet? > > > Absolutely not... Cocoon internally is 100% unaware of any whatsoever > encoding of characters... For instance it doesn't even know whether a > character such as (C) [the copyright character] can be encoded in the > output (imagine that I use an US-ASCII encoding). It _must_ not know it, > that's the realm of the serializer. Yes, also obvious. I only did not know if that was the point of your statement. Joerg