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 64.233.184.231 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=GOULy+H80WQaYSFq6FgCNEyYo6RUZlMwheF/b7mSHi1kaFm0fS0XuZhB5S1njb9G9voRVajkJ2ViBEnMJQs1bLUiXZdIn3ztEfQSkZd3owEUQWs5BEcYqbzF+bWBdxx1b+zBF/Oe+HB0H3o0tOhRLIMETZVa/22jw2l/4saOitQ=
Message-ID: <4655B0DC.2060206@outerthought.org>
Date: Thu, 24 May 2007 17:35:56 +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>
In-Reply-To: <4655AA1F.1010108@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Marc Portier <marc.portier@gmail.com>


hepabolu wrote:
> Carsten Ziegeler said the following on 24/5/07 16:14:
>> Helma wrote
>>>
>>> Yes. Source is:
>>>
>>> <oe:version xmlns:oe="openEHR/v1/Version" 
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>>> xsi:type="ORIGINAL_VERSION">
>>>
>>> So in fact I want the first line of the binding file to bind to 
>>> /oe:version
>>>
>>> I don't think there are unused prefixes in both binding and source.
>>>
>> Ah, sorry, I meant are you really using the prefix in the binding file?
>> Using the prefix inside of an attribute (like the path attribute) does
>> actually not use the prefix. This is just arbitrary text for the parser.
> 
> 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.
> 

I'm not sure, but to my knowledge this effect is because jxpath falls 
back to qname binding when it doesn't have the correct ns bindings on 
the context


here is what I think is happening:

IF jxpath gets
- on a context with some ns declared: [x=uri1, y=uri2]
- a call to resolve an xpath: /z:whatever

then it first tries to find a ns binding for the 'z' prefix, and since 
that one isn't there, then just assumes 'z:name' to be matched as a qname

so it will find such z:name regardless of whatever ns declaration there 
would be in the xml-document it is querying for z

(we could argue if this is a bug, but I think this fallback makes 
perfect sense for jxpath in order to support lookups that are not ns-aware)


however IF all namespaces are declared I would assume jxpath to be 
working fully ns-aware, ie

IF jxpath gets
- on a context with some ns declared: [x=uri1, y=uri2]
- a call to resolve an xpath: /x:whatever

then it will find the node 'whatever' even if it is present in the xml 
with prefix 'other' as long as xmlns:other'"uri1" is declared in the 
target xml being searched


now for all this to work inside the binding-setup it needs to keep track 
of all the namespace-declarations in the binding file in order to pass 
them down to the jxpath context before asking it to resolve the @path of 
the binding at hand


my guess is that since we don't seem to control the namespace-prefix 
usage on the various parsers into play we sometimes get empty 
ns-declaration sets, thus no ns info on the jxpath context, thus binding 
failures, or rather lucky shot successes if the ns prefixes happen to match


> So how should this be solved then?
> 

we could start off by checking some more

1/ can jxpath in fact handle namespaces correctly as described above
( in https://issues.apache.org/jira/browse/COCOON-1671#action_12356396 
the orginal reporter of the issue states that this is the case, so we 
can take it from there of course)


2/ are indeed the ns-maps inside the CommonAttributes objects on each 
JXPathBinding base correctly filled in (I suggest dumping those in 
log-debug statements during binding to verify in the various cases)


if those ns-declaration-maps are empty when they should not, then we 
should fix the binding first to populate them correctly:


- probably follow the path of fixing DomHelper to use the 
lookupNamespaceURI() method in combo with some xpath parsing as I 
suggested earlier)
- or stop joking about it and do the sax rewrite :-)


regards,
-marc=