I haven't analyzed this completely, but both problems go away if you
change TreeWriter.startDocument: after
receiver = new NamespaceReducer(receiver);
What's happening here is that the Receiver obtained from the
XdmDestination (which is pretty close to the actual TinyTree builder)
is assuming it will receive a namespace-complete and -well-formed
sequence of events: that is, the namespace() calls will represent
exactly the namespace declarations that are needed, no more and no
less. This can be achieved by filtering a less-well-formed sequence of
events through a NamespaceReducer (so misnamed because its original
function was merely to remove duplicate namespace declarations.)
I'm not entirely sure what to do to stop people falling into this trap.
Inserting a NamespaceReducer unconditionally would be rather
heavy-handed for those applications that don't need it. I do already
insert a TreeProtecter into the pipeline (probably as a result of
previous Calabash issues??) which checks for some consistency errors,
but doesn't do the whole work on namespaces. In 9.3 I'm introducing the
ability to write programmatically to a Destination using the
XmlStreamWriter interface (which I find to be a very nice interface for
the job), and perhaps this could insert the NamespaceReducer
On 18/07/2010 21:01, Norman Walsh wrote:
Norman Walsh <email@example.com> writes:
I'm working on building a test case now which I hope will illuminate
Not one error, it turns out, but two. :-(
There are two "main" routines in the attached test, run1() and run2().
If you try run1, you'll see that the output is
which is wrong. It should be
<doc xmlns...><parent><child xmlns=""/></parent></doc>
If you try run2, you'll see the "Cannot output a namespace node for
the default namespace when the element is in no namespace" error.
The difference between the two cases is that in run2, I walk over the
input document attempting to reconstruct it without the "xmlns:p"
This is probably user error on my part, but any insight you could
provide as to the location of those errors would be most appreciated.
Be seeing you,
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
saxon-help mailing list archived at http://saxon.markmail.org/