cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
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="" 
>>> 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
> 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 
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 :-)


View raw message