cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: CForms binding with namespaces error - advice wanted
Date Thu, 24 May 2007 15:35:56 GMT


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=

Mime
View raw message