hepabolu wrote:
Marc Portier said the following on 24/5/07 17:35:
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)
right.
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)
No. I've done step-by-step debugging on this and the CommonAttributes
are empty or null (can't remember exactly). In any case, no namespaces
are available. In fact CommonAttributes calls addLocalNSAttributes (or
something similar) which in turn calls Element.getAttributes() which
doesn't return any namespaces.
yes, the namespace-prefix param on the parser does not guarantee that in
all cases pipelines will keep producing xmlns declarations as attributes
(only directly atop the parser we have that guarantee)
I can't say whether that's due to a flaw in addLocalNSAttributes or
because I was processing the binding generated through pipelineUtil.toDOM.
I suspect the latter
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)
ok, well it is probably rather 'bypass' the domhelper then fix
what we do now is ask (via the domhelper) to list ALL namespaces it can
find on an element (locally or inheritted) and then remember those in
the common-attributes
we do this based on the assumption that the xmlns-declarations are
available in the DOM as attributes, an assumption that you proved not
always to be true
to my knowledge there is no method in the DOM that will return you the
same information (list of all known ns-declarations)
There is however (already mentioned) node.lookupNamespaceURI(prefix)
which (according to javadoc) will resolve a given prefix to the bound
ns-uri in the context of any given node
So rather then list all the namespaces on the xml-element we could use
this to remember only the namespaces we need inside the bindings @path
statement. For that however we need to know which prefixes are used
inside the @path statement (hence my previous remark on a need to parse
those)
again there are assumptions in this approach
- sax-pipelines should not be hiding namespace-prefix-binding events
- the dom-trees (built from sax events) should be tested to be
correctly resolving the inheritence/overwrite of namespaces in the
result of the node.lookupNamespaceURI()
and more fundamentally:
code-wise these xml manipulations have been applicable for all bindings
(hence the name -common- attributes) in this case however there might be
(not sure) binding-specific structures that are declaring @path-like
attributes which should be parsed for more prefixes to list....
HTH,
-marc=
If you could be more specific in how I should go about doing this, I'd
have another look tomorrow...eh, later today. ;-)
- or stop joking about it and do the sax rewrite :-)
Just wondering: is this 2.1.X only or does it affect 2.2 as well?
Bye, Helma
