This is using Ryan Senior's new 0.0.3-SNAPSHOT.

While trying to parse a huge XML file (7.5 GB compressed, a dump of Wikipedia), got a stack overflow error. Some digging turned up this bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6440214

Modifying clojure.data.xml/source-seq to disable the IS_COALESCING property got rid of the error.

The old lazy-xml contrib code worked (although used up tons more memory).

Attached is a patch that adds keyword options to source-seq, parse, and parse-str, allowing the consumer to disable coalescing and sidestep the upstream bug.

Emitting large XML documents, fed from lazy-seqs in data.xml does not work. Currently, the lazy-seq is held in a defrecord, which holds onto the head of the lazy-seq and will force it to all be in memory (eventually consuming all available memory). Example code to reproduce the issue below:

(with-open [fw (java.io.FileWriter. "/tmp/lots-of-foo.xml")]
    (xml/emit
       (Element. :some-tags
           {}
           (map #(Element. :foo {} [(str "foo" %)])
                (range 0 10000000)))
       fw))

See https://groups.google.com/d/topic/clojure-dev/Z-wrRTcUs6U/discussion

See the test matrix here: http://build.clojure.org/job/data.xml-test-matrix/. Looks like the mixed-quotes test is to blame, just a reordering of attributes when they are emitted to a string.

C:\Users\ralphm\workspace\dbxml-env>lein version
Leiningen 1.6.2 on Java 1.7.0_02 Java HotSpot(TM) Client VM
C:\Users\ralphm\workspace\dbxml-env>lein deps
Downloading: org/clojure/data.xml/0.0.2-SNAPSHOT/data.xml-0.0.2-SNAPSHOT.pom from repository clojars at http://clojars.org/repo/
Unable to locate resource in repository
[INFO] Unable to find resource 'org.clojure:data.xml:pom:0.0.2-SNAPSHOT' in repository clojars (http://clojars.org/repo/)
Downloading: org/clojure/data.xml/0.0.2-SNAPSHOT/data.xml-0.0.2-SNAPSHOT.jar from repository clojars at http://clojars.org/repo/
Unable to locate resource in repository
[INFO] Unable to find resource 'org.clojure:data.xml:jar:0.0.2-SNAPSHOT' in repository clojars (http://clojars.org/repo/)
An error has occurred while processing the Maven artifact tasks.
Diagnosis:

Unable to resolve artifact: Missing:
----------
1) org.clojure:data.xml:jar:0.0.2-SNAPSHOT

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.clojure -DartifactId=data.xml -Dversion=0.0.2-SNAPSHOT
-Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.clojure -DartifactId=data.xml -Dversion=0.0.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

Path to dependency:
1) org.apache.maven:super-pom:pom:2.0
2) org.clojure:data.xml:jar:0.0.2-SNAPSHOT

----------
1 required artifact is missing.

for artifact:
org.apache.maven:super-pom:pom:2.0

from the specified remote repositories:
central (http://repo1.maven.org/maven2),
clojars (http://clojars.org/repo/)

This error does not present till you attempt to emit xml that has a string where the element function is expecting a keyword. This is double hard to figure out at first because the error message is vague. I am requesting that the element function is allowed to use strings instead of keywords or the error message is cleaned up so that the "user" error is clear.

prxml allowed something like this:

(prxml [:foo [:cdata! "all my cdata"]])

It doesn't look like that is currently allowed in data.xml. It looked like maybe I could extend the AsElements protocol to get this behavior, but I couldn't quite figure it out, seems like I'd have to have access to the XmlStreamWriter to get the string representation of the cdata.

(xml/emit-str (xml/cdata "fooo]]>bar"))

"<?xml version=\"1.0\" encoding=\"UTF-8\"?><![CDATA[fooo]]>bar]]>"

This is invalid xml. The contract for cdata states that it cannot contain the end tag "]]>", so if the cdata function gets passed content that contains it, it should do the right thing, which is probably this:

http://stackoverflow.com/questions/223652/is-there-a-way-to-escape-a-cdata-end-token-in-xml

(split the content so it is emitted as multiple cdata blocks, none of which contain the entire end-tag "]]>").

This is not a purely academic bug report - I actually hit this problem in prxml and fixed it on my fork.

When using the Indent function, and trying to change the encoding, an exception is thrown.

java.lang.IllegalArgumentException: No value supplied for key: [:encoding "UTF-8"]

This seems to be that the options are not being passed from indent to emit correctly.

There are a couple of occurrences of reflection in the data.xml library