DTDToHaskell was indeed a great idea. However, the
last time I tried to use HaXml for a real project, I was not able to
compile the resulting file because the DTD defined two namespaces. It would be great if someone could address that limitation.
As with many other topics, XML handling is an area where it's easy to make a novel library based on a new concept, but *very* hard to create a full, industry-ready implementation that handles non-trivial, real-world DTDs and XML.
Just in this thread, people have listed many libraries. Their features overlap in part but not perfectly. Their level of maintainership is unclear. Comparing all of this work to determine what a good choice would be is VERY hard* . To me, this highlights the fact that our community might do better if we focused on contributing to existing implementations, and resisted the urge to create new ones.
All the best,
Ivan
(*It's not always easy to measure any one dimension. The complexity of comparing implementations may quickly degenerate to something like m * (n ^ 2) where m is the number of dimensions compared and n is the number of solutions, but I think it can get even worse, but even then you may be left with the task of defining a good order relationship on an m-dimensional space. All of this to say that it's REALLY complex and adding a new implementation should rarely be seen as the solution.)