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?
Bye, Helma
