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=
