Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of marc.portier@gmail.com
 designates 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=a13IugjsmX0DmYBDOHwcmSnBLm3jVjnLHCb+NO9EROYMNTNKqT70OOepYoNbb/2JHEQ8HNZCLzG21/Rzys4PDlY9R6dbQW+hcTJs+4JJq/OcAqQUxeZ0nVbrfwYExpyB0XZ+FszSYcs0vU6Cjxe6/QJBewl6U27WidjhcHzrmts=
Message-ID: <4655B381.2030807@outerthought.org>
Date: Thu, 24 May 2007 17:47:13 +0200
From: Marc Portier <mpo@outerthought.org>
Organization: Outerthought
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CForms binding with namespaces error - advice wanted
References: <4653073A.1020300@mi.unimaas.nl> <46535023.1050507@gmx.de>
 <46540208.1030209@gmail.com> <465410CC.6020605@apache.org>
 <465416ED.3040904@outerthought.org> <4654208B.3060403@gmail.com>
 <465481F2.7070508@gmx.de> <465495D5.10706@gmail.com>
 <4654997A.4090002@apache.org> <46553ECD.3010203@outerthought.org>
 <46555613.6090503@apache.org> <465584C8.7020307@outerthought.org>
 <465592ED.1070209@gmail.com> <465599CE.4060804@apache.org>
 <46559B9E.5000209@gmail.com> <46559DC3.5060403@apache.org>
 <4655AA1F.1010108@gmail.com> <4655AFF8.3090407@apache.org>
In-Reply-To: <4655AFF8.3090407@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Marc Portier <marc.portier@gmail.com>


Carsten Ziegeler wrote:
> Helma wrote:
>>
>> That's what I'm slowly starting to realise. For proper XML validation 
>> I do need it so I assumed the parser requires this too.
>>
>> That would partially explain why the binding file (without a 
>> namespaceURI for 'oe') still maps to the source (in the source=file 
>> situation). It would also explain the observations in
>>
>> https://issues.apache.org/jira/browse/COCOON-1671
>>
>> i.e. if the prefix is the same with a matching or a different 
>> namespaceURI it binds, but if the prefix is different but the 
>> namespaceURI is identical it fails.
>>
>> So how should this be solved then?
>>
> I think there are two areas:
> 
> The first one is the parsing of the binding. We have to ensure that the 
> namespace prefixes are correctly send to the cforms component parsing 
> the binding. So we should see that there is no namespace prefix 
> inbetween. Actually, I fear, we can't ensure this in general. So perhaps 
> in these cases a workaround is required and you have to add a dummy 
> attribute somewhere in the binding, like <fb:... oe:something="dummy">.
> This is not great, but hopefully solves this problem.
> 

good idea,

on the other hand we are looking here at xml representations on file, right?

so while this approach would force some xml-serializer to include the 
xmlns declaration it doesn't really guarantee that the SAX-stream will 
suddenly add a xmlns:oe="..."  as _attribute_ to the sax startElement 
method, does it?
(which is what we forced on the sax parser by adding the 'dangerous' 
parameter)


personally I think the safer bet is to change the harvesting logic of 
the xmlns declarations from the DOM tree
(although it is more work)


> Now, the second area is more complicated. When cforms parses a binding 
> it should parse the paths and test them for namespaces and if these 
> namespaces are properly defined - if not, throw exception.
> When the binding is applied, the namespaces have to be checked, if the 
> uri's are the same. This should then work even if different prefixes are 
> used. I looked into namespaces and jxpath a long time ago and I think to 
> remember that there were problems; so this could get ugly :(
> 

there were, but as mentioned in the bug (see my previous post), they 
should be solved in jxpath 1.2

> I think this is something for our cforms and jxpath experts!
> 
> Carsten
> 


regards,
-marc=