Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 27149 invoked by uid 500); 10 Dec 2001 12:16:50 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 27123 invoked from network); 10 Dec 2001 12:16:41 -0000 Message-ID: <3C14A78B.DFD961E8@anyware-tech.com> Date: Mon, 10 Dec 2001 13:16:11 +0100 From: Sylvain Wallez Organization: Anyware Technologies X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org CC: cocoon-users@xml.apache.org Subject: Re: Multiple Namespace Decls. References: <9FDE13142FC0D3118B5100508BE7C43929EE62@certechexc3.cerillion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Luke Studley wrote : > Hi > > Wonder if anyone else has seen this > > I'm trying to use cinclude, but the same seems to happen for all ns > declarations - whether from xsp or read from xml - in the down > pipeline processing there are multiple (dual) declarations of each > namespace - my editor complains about this and my styleshets screw > up. > > Sticking in a log statement I see the following - which seems to > correctly fire a startPrefixMapping event - but also an attribute > event for the xmlns:ci attribute as well - is this correct? If it > is then something downstream is responding to both events and thus > duplicating xmlns dec.s First of all, would you mind avoiding HTML mail on the list ? Thanks. I guess you're using Saxon. This is because cocoon was mainly tested with Xalan whose serializer has a bug associated with namespace declaration (startPrefixMapping isn't enough, Xalan also wants xmlns: attributes). To circumvent this problem, the XML parser in Cocoon always had the "namespace-prefixes" property set (see org.xml.sax.ContentHandler.startElement() javadoc to see what this means) but this isn't in fact the real good solution and hurts Saxon. As I also faced this problem recently and I'm currently working on a more robust solution, that handles transparently both Saxon and Xalan, which I will commit in the CVS I hope this week. I'll notify you when the commit is done, and it will of course be included in the next Cocoon minor release. In the meanwhile, I suggest you temporarily switch to Xalan. Sylvain. -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org