Simon Marlow wrote:
I guess that HaXml probably can't get into fptools because of license incompatibilities, but hxml and HXmlToolbox both have MIT licenses, and so could probably be put into fptools:
http://www.flightlab.com/~joe/hxml/ http://www.fh-wedel.de/~si/HXmlToolbox/
[...]
I'd like to see the community settle on a single XML API if possible, but I imagine that will probably happen over time in any case. Perhaps someone could offer to lead a group to work on standardising an API?
When I looked into XML libraries a while ago, I settled for HaXML because: (a) while hxml was clean and easy to use, it's functionality was very limited; e.g. no validation or entity handling, IIRC. (b) HXmlToolbox was the most functional of the packages in terms of XML support: mainly, being the only one with namespace support "out of the box". But I found the interface was too wedded to the IO monad for my purposes; I had cases when I wanted a pure function to process the XML "internal subset" from a string value, and return a result free of the IO monad. In the end, I added namespace support (and xml:lang, xml:base) to HaXml. I think that Malcolm has now incorporated much of that functionality into the mainstream version. From memory, the HaXML API seems very Haskelloid (?), so I'd suggest that as a starting point. I don't know about the licence issues, though. BTW, if we converge on an XML API, I'd be interested to see if that can be built upon to include RDF. Also, query APIs might be good to think about (e.g. for exploiting XQuery, SPARQL; Andy Seaborne at HP Labs has done some work on a SPARQL implementation in Java whose design allows queries to be composed and manipulated programmatically - that kind of thing would, I think, be bread-and-butter for Haskell). #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact