Re: XML strictness
Robert Schuster wrote: When run as 'echo a/ | jamvm -cp . xmlfilter.XMLFilter' you get the following exception: gnu.xml.dom.DomDOMException: The node doesn't belong here. More Information: document element already present: gnu.xml.dom.DomElement[a] Node Name: new at gnu.xml.dom.DomDocument.checkNewChild (DomDocument.java:294) at gnu.xml.dom.DomDocument.appendChild (DomDocument.java:317) at xmlfilter.XMLFilter.main (XMLFilter.java:42) You get the same message with all proprietary JDKs prior to 1.5 . The latest incarnation however accepts creating the new node and generates the following XML upon calling 'echo a/ | /opt/sun-jdk-1.5.0/bin/java xmlfilter.XMLFilter': ?xml version=1.0 encoding=iso-8859-1? a/ new/ AFAIK there should/must be only one top-level node which is named xml. I am confused ... Is Sun breaking the rules here? According to http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#appendChild(org.w3c.dom.Node) HIERARCHY_REQUEST_ERR: Raised ... if this node is of type Document and the DOM application attempts to append a second DocumentType or Element node. If you want to add arbitrary node types, use a DocumentFragment. -- Chris Burdess ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
XML strictness
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
I got a bug report about our DOM parser which I thought to be valid but
then found something that irritates me.
The following program (probably) demonstrates a problem with Classpath'
DOM parser.
package xmlfilter;
!various imports ommitted!
public class XMLFilter {
public XMLFilter() {
super();
}
public static void main(String[] args) throws Exception {
/*
* parses stdin
*/
Document doc =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(System.in);
Element newElement = doc.createElement(new);
// The next line makes it unhappy ...
doc.appendChild(newElement);
/*
* serializes xml file to System.out
*/
TransformerFactory tfactory = TransformerFactory.newInstance();
Transformer serializer = tfactory.newTransformer();
doc.normalize();
serializer.setOutputProperty(OutputKeys.INDENT, yes);
serializer.setOutputProperty(OutputKeys.ENCODING, iso-8859-1);
serializer.transform(new DOMSource(doc),
new StreamResult(System.out));
}
}
When run as 'echo a/ | jamvm -cp . xmlfilter.XMLFilter' you get the
following exception:
gnu.xml.dom.DomDOMException: The node doesn't belong here.
More Information: document element already present:
gnu.xml.dom.DomElement[a]
Node Name: new
at gnu.xml.dom.DomDocument.checkNewChild (DomDocument.java:294)
at gnu.xml.dom.DomDocument.appendChild (DomDocument.java:317)
at xmlfilter.XMLFilter.main (XMLFilter.java:42)
You get the same message with all proprietary JDKs prior to 1.5 . The
latest incarnation however accepts creating the new node and generates
the following XML upon calling 'echo a/ |
/opt/sun-jdk-1.5.0/bin/java xmlfilter.XMLFilter':
?xml version=1.0 encoding=iso-8859-1?
a/
new/
AFAIK there should/must be only one top-level node which is named xml.
I am confused ...
Is Sun breaking the rules here?
cu
Robert
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCm8i0G9cfwmwwEtoRAsUyAJ9nU4WtvKJE94oh22WcwWACnjVdqQCcDkNg
SQ3+IUlJgX3N8FLpDSkBeLU=
=XfBm
-END PGP SIGNATURE-
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: XML strictness
Robert Schuster wrote: You get the same message with all proprietary JDKs prior to 1.5 . The latest incarnation however accepts creating the new node and generates the following XML upon calling 'echo a/ | /opt/sun-jdk-1.5.0/bin/java xmlfilter.XMLFilter': ?xml version=1.0 encoding=iso-8859-1? a/ new/ AFAIK there should/must be only one top-level node which is named xml. I am confused ... Is Sun breaking the rules here? Depends on which set of rules. The XQuery 1.0 and XPath 2.0 Data Model is a bit more general: See http://www.w3.org/TR/xpath-datamodel/#DocumentNode Of course an *XML document* is somewhat more restricted, but if you want to use DOM to support XQuery/XPath/XSLT objects it makes sense to allow more generality. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
