cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject Re: Fwd: patch for (fixing the encoding problem with XInclude)
Date Sat, 09 Sep 2000 14:32:27 GMT
I'm forwarding this to cocoon-dev where hopefully someone else will take 
care of it. Attachments to follow in next message.

"Tagunov Anthony" <> wrote:
>Hello, Robert!

(my name's not Robert, incidentally)

>As I'm in a confusion on where I should post my fixes

>and as you've been participating in the discussion on encoding problem 
> >with xinclude processor,

Well, I don't actually know anything about xinclude.

>I'm forwarding this to you to, it's an explanation of what was happening 
>Tagunov Anthony
>NNT Telecom, Russia
>==================BEGIN FORWARDED MESSAGE==================
> >From: "Tagunov Anthony" <>
> >To: "donald Ball" <>
> >Date: Fri, 08 Sep 2000 16:53:38 +0400
> >Reply-To: "Tagunov Anthony" <>
> >Priority: Normal
> >X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT 
> >MIME-Version: 1.0
> >Content-Type: multipart/mixed; 
> >Subject: patch for (fixing the encoding problem 
>with XInclude)
> >
>Hello, Donald!
>I really never expected I'll be sending new fixes to you soon, but still...
>1. The problem.
>Here are two files attached (sqlres.xml and sqlres-t.xml). sqlres-t 
>xincludes sqlres.xml. both files are in UTF-8.  In both files there's the 
>same block
>of three lines that are not ASCII (actually these are cyrillic letters, but 
>you should not bother you can't understand 'em. when I look at 'em in my 
>texteditor or
>print 'm to console I also see only mess).   The point is to put 'em on the 
>server, request sqlres-t.xml from it and look what you get. You'll see 
>block included
>via xinclude from sqlres.xml and block from sqlres-t.xml.  In ideal they 
>should be the same.  With my installation (Xerces 1.1.3, Tomcat 3.1, 
>Cocoon-1.7.4 + latest version
>of from CVS) I get'em different.
>2. Solution.
>To fix it on my system I went deep into the sources of Cocoon and Xerces 
>and found out that when we pass
>new InputSource(some-string)
>to parser.parse then we have systemid property in InputSource object set 
>(it would be the same to do  in=new InputSource(); 
>That's what ProducerFromFile does. Then in the depthes of Xerces
>             ...
>             URL url = new URL(systemId);
>             is = url.openStream();
>             ..
>                    XMLDeclRecognizer.recognize(...
>is called to read <?xml version=".." encoding=".."?> declaration and 
>interpret the encoding correctly.
>So my solution is sent in this patch...
>3. Other matters..
>     I have already asked some other people amoung the developers about 
>that, but didn't get a reply yet I've got a patch for xsp-java.xsl (part of 
>the XSP processor)
>that can partly fix a problem with lost namespaceURI's after XSP page 
>execution. BTW I hit this problem while testing XInclude processor and one 
>my own quite
>intresting processor which I derived from code 
>(Thanx for an Excellent example of how Processor should be written -- I 
>have never seen one
>before and yours helped my to build a fairly good processor of my own! 
>Thanx again!  :))... so I found that XSP processor misbehaves by stripping 
>namespaceURI's from the elements (not eleminating the prefixes, but not 
>substitutin URI's).. I've already sent a letter to Ricardo (20 hrs ago) --  
>no reply yet and
>to Robin Green (4 hrs ago, but there's night now in the US), now I'm 
>forwarding it to you too and my question is
>should I send such patches line XIncludeProcessor.diff and xsp-java.diff to 
>cocoon-dev or privatly to the authors?

Get Your Private, Free E-mail from MSN Hotmail at

Share information about yourself, create your own public profile at

View raw message