XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

> 
> There is a difference about which I'm not sure what causes 
> it, namely that in my test program the DOM elements turn out 
> to be of type 
> com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl, 
> whereas I remembered them being of some type 
> net.sf.saxon.TinySomething when that but occurred that I 
> reported initially.

If you call an extension function supplying a node that was present in your
input DOM tree, then the original Xerces element node will be passed to the
extension function.

If your Saxon stylesheet constructs a node and then passes that node to an
extension function that expects a DOM node, Saxon will construct the node
typically as a net.sf.saxon.tinytree.TinyNodeImpl, and will then wrap this
in a NodeOverNodeInfo object to provide the DOM interface; your extension
function will see the NodeOverNodeInfo object. The two cases are very
different in terms of internal code paths and things that can go wrong,
though they might appear very similar to a simple application.

However the stack trace below suggests you are doing neither of these
things: this time you don't seem to be calling an extension function, you
seem to be writing a new DOM as the final output of a transformation. Is
that right? 
> 
> Now in my real application the patched Saxon fails with some 
> completely strange error, namely:

That looks very similar to this bug in Saxon 8.8:
http://sourceforge.net/tracker/index.php?func=detail&aid=1558133&group_id=29
872&atid=397617

In fact I think it is that bug. The line numbers in your stack trace match
the Saxon 8.8 source code; I suspect you are picking up the wrong version.
> 
> Could it be related to the fact that I used an outdated 
> build.xml? After all, I've never built Saxon myself (just 
> downloaded the jar files), and now I checked out the sources 
> from SourceForge, applied your patch in the trunk (or should 
> I have used latest9.0?), 

Yes, the branch you should use is latest9.0. I do recognize that it's not
easy to build Saxon. For most people the best way is to ignore (delete) the
packages you don't need, such as the dotnet package; running the full build
involves you in a lot of dependencies, and I have never really productized
it.
> >
> > Without more information as to how the tree appears to be 
> corrupt it's 
> > difficult to help.
> 
> Any ideas how to get at this information? Is there anything I 
> could dump?
> 
What I need is a repro: a package of code that I can run to reproduce the
problem in my own diagnostic environment. It's quite tough, as I'm not well
equipped to run XOM through a debugger (I had quite some trouble compiling
it - you're not the only one with such problems!), but if I can reproduce
the problem then I can solve it, and if I can't then I probably can't.

Michael Kay
http://www.saxonica.com/