Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] Bug (?) in Saxon/DOM/XOM interaction: Attributes instead of namespaces; strange element tree structure

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Christoph LANGE <ch.lange AT jacobs-university.de>
  • To: XOM <xom-interest AT lists.ibiblio.org>, Saxon <saxon-help AT lists.sourceforge.net>
  • Subject: [XOM-interest] Bug (?) in Saxon/DOM/XOM interaction: Attributes instead of namespaces; strange element tree structure
  • Date: Thu, 21 Feb 2008 22:37:41 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page