XOM API for Processing XML with Java

[Christoph LANGE <ch.lange AT jacobs-university.de>]

Dear XOM developers, dear Saxon developers,

  sorry for crossposting, but this bug is actually related to both XOM and 
Saxon. As far as I can judge on that, Saxon generates DOM output that is not 
completely valid and makes XOM's DOMConverter crash.

In my project I'm calling, via an XPath extension function, a XOM-powered 
library (mmlkit, as mentioned 
previously on the XOM list; http://kwarc.info/projects/mmlkit/) from XSLT 
style sheets fed with DOM input. The 
DOM input is generated using the default XML parser of Java 5 (Xerces, 
AFAIK), and the XSLT is processed using Saxon. Whenever mmlkit obtains a DOM 
fragment, it uses DOMConverter to convert it to XOM. The XOM version is 
1.2b2, 
and the Saxon version is 9.0.0.2.

Now I have fragments like <elem xmlns="namespaceURL"/>. A full fragment that 
is passed from the XSLT to the XPath extension function would look like this:

<m:apply xmlns:m="http://www.w3.org/1998/Math/MathML"; 
xmlns:mcd="http://www.w3.org/ns/mathml-cd"; xmlns:wif="http://i
kewiki.srfg.at/syntax/1.0/core">
  <m:csymbol cd="arith1" mcd:cr="fun" name="plus"/>
  <om:OMSTR xmlns="http://www.w3.org/1999/xhtml"; 
xmlns:om="http://www.openmath.org/OpenMath";>arg1</om:OMSTR>
  <om:OMSTR xmlns="http://www.w3.org/1999/xhtml"; 
xmlns:om="http://www.openmath.org/OpenMath";>…</om:OMSTR>
  <om:OMSTR xmlns="http://www.w3.org/1999/xhtml"; 
xmlns:om="http://www.openmath.org/OpenMath";>argn</om:OMSTR>
</m:apply>

(Don't worry about these spurious wif and html namespace nodes; they 
originate 
from the surrounding context. In other cases, one of the really relevant 
namespaces is declared with the empty prefix.)

When this is converted from DOM to XOM, I encounter two bugs. First, some of 
the namespace nodes are wrongly represented as attributes named xmlns in the 
empty namespace, which I was able to handle by the following change to 
DOMConverter.makeElement(org.w3c.dom.Element, NodeFactory):

@@ -527,7 +527,11 @@
             String name = attribute.getName();
             String uri = attribute.getNamespaceURI();
             String value = attribute.getValue();
-            if (uri == null) uri = "";
+            if (uri == null) {
+               // from Saxon we sometimes get xmlns as 'attribute' without 
namespace
+                if (name.equals("xmlns")) continue;
+               uri = "";
+           }
             if (uri.equals(XMLNS_NAMESPACE)) {
                 if (name.equals("xmlns")) continue;
                 String prefix = name.substring(name.indexOf(':') + 1);

Note: I know that this misbehaviour is rather Saxon's fault but XOM's, but I 
needed to make it work in my application (the mathematical wiki SWiM; 
http://kwarc.info/projects/swim/), and I found the optimized data structures 
in net.sf.saxon.tinytree.* incredibly hard to debug.

The second bug occurs in DOMConverter.convert(org.w3c.dom.Element element, 
NodeFactory). It seems evident that the algorithm walks down and up the given 
tree and quits when it again arrives at the root node (i.e. element). In my 
application, this case never occurs; instead, the algorithm arrives at a 
point where the current node is null and runs into a NullPointerException. I 
made the following change to fix this:

@@ -465,11 +465,11 @@
         ParentNode parent = result;
         boolean backtracking = false;
         while (true) {
-            if (current.hasChildNodes() && !backtracking) {
+            if (current != null && current.hasChildNodes() && !backtracking) 
{
                 current = current.getFirstChild();
                 backtracking = false;
             }
-            else if (current == element) {
+            else if (current == null || current == element) {
                 break;
             }
             else if (current.getNextSibling() != null) {

Here, I am less sure whether it is the fault of Saxon or XOM.

Now I arrived at a solution that works for me but does not really solve the 
problem. Any helpful comments are appreciated, and I hope that my findings 
are also helpful for you.

Best,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701