[Classpathx-xml] BUG: DOM handling of DTD decls?

[nferrier]

I have a document which starts like this:

  <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
  <?xml-stylesheet type="text/xsl" href="sdocbook.xsl"?>
  <!-- generated by Majix from C:\tmp\example.rtf on Mon May 13 20:39:10 BST 
2002 using template SDocBook -->
  <!DOCTYPE article SYSTEM 
"http://www.oasis-open.org/docbook/xml/simple/1.0b2/sdocbook.dtd"; [
  <!NOTATION wmf SYSTEM "wmf" >
  <!ENTITY g001 SYSTEM "images/example_001.wmf" NDATA wmf>
  ]>
  <article>
  .
  .
  .

Then I am using this piece of code to try and extract values from it:


            Document d = domManager.parse(x);
            Element root = d.getDocumentElement();
            try
              {
                NodeList children = root.getElementsByTagName("para");
                Element header = (Element) children.item(0);
                longTitle = header.getFirstChild().getNodeValue();
                children = root.getElementsByTagName("author");
                Element authorTag = (Element) children.item(0);
                if (authorTag != null)
                  author = authorTag.getFirstChild().getNodeValue();
              }
            catch (Exception e1)
              {
              }

I put some debug into DomNode.checkMisc to output the type and child
type and also the node value (if the node was a text node).

I get the following error:


DOMNode node type = 9 new type: 7
DOMNode node type = 9 new type: 8
DOMNode node type = 9 new type: 10
DOMNode node type = 9 new type: 3
child content = ß
gnu.xml.dom.DomEx: The node doesn't belong here.
More Information: this node can't have that type of child
Node Name: #document
        at gnu.xml.dom.DomNode.checkMisc(DomNode.java:374)
        at gnu.xml.dom.DomNode.appendChild(DomNode.java:533)
        at gnu.xml.dom.DomDocument.appendChild(DomDocument.java:237)
        at gnu.xml.pipeline.DomConsumer$Handler.characters(DomConsumer.java:508)
        at gnu.xml.aelfred2.SAXDriver.charData(SAXDriver.java:880)
        at gnu.xml.aelfred2.XmlParser.dataBufferFlush(XmlParser.java:2641)
        at gnu.xml.aelfred2.XmlParser.parseCharRef(XmlParser.java:1806)
        at gnu.xml.aelfred2.XmlParser.readLiteral(XmlParser.java:2383)
        at gnu.xml.aelfred2.XmlParser.parseEntityDecl(XmlParser.java:1948)
        at gnu.xml.aelfred2.XmlParser.parseMarkupdecl(XmlParser.java:919)
        at gnu.xml.aelfred2.XmlParser.parseDoctypedecl(XmlParser.java:869)
        at gnu.xml.aelfred2.XmlParser.parseProlog(XmlParser.java:525)
        at gnu.xml.aelfred2.XmlParser.parseDocument(XmlParser.java:417)
        at gnu.xml.aelfred2.XmlParser.doParse(XmlParser.java:170)
        at gnu.xml.aelfred2.SAXDriver.parse(SAXDriver.java:324)
        at gnu.xml.aelfred2.XmlReader.parse(XmlReader.java:295)
        at gnu.xml.dom.JAXPFactory$JAXPBuilder.parse(JAXPFactory.java:186)
        at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:161)

Note:
This is a bug report for me, I'm happy to fix this. I know David is
busy.

It's definitely a bug I think, xerces parses the document quite
happily.

Maybe if someone spots something really dumb they'll tell me  /8->




Nic