hepabolu schrieb:
So you can't rely that you get the namespace attributes in the dom
builder.
I think this is where things go wrong.
Note that both binding file and source are generated with a pipeline and
pipelineUtil.toDOM.
I've done some debugging into pipelineUtil.toDOM and this is what I found:
- binding file has all the namespaces in pipeline. This is confirmed
because I can save the output of the pipeline and see the namespaces in
the root element:
<fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:fd="http://apache.org/cocoon/forms/1.0#definition";
xmlns:oe="openEHR/v1/Version" path="/oe:version">
- After returning from SourceUtil.toDOM (which uses the default
DOMBuilder()), the only namespace left is
fb="http://apache.org/cocoon/forms/1.0#binding";.
Attributes of this node only holds 'path=/oe:version'.
- This is true for the source=pipeline situation as well: only the
oe="openEHR/v1/Version" is left.
- The source=file situation has all namespaces in the attributes.
I can understand that in the situation of source=pipeline there cannot
be any matching because the oe namespace is not known in the binding
file. However, this is also true for the situation of source=file and
there matching happens on various fb:context until it fails on a
difference in datatype.
What I also don't understand is the fact that putting the
source=pipeline through the savedocument function as I did this morning,
gives me all the namespaces back.
I'm not sure if this helps in the discussion and I have no clue on how
to solve this.
Anyone?
I must say that this is all a little bit strange to me as well. Now, are
you using the prefix oe somewhere in the xml? The prefix fb is definitly
used, so it might be that there is some optimization filtering unused
prefixes? Just a wild guess.
Carsten
