The main XML parser I use for my browser engines is XML Conduit, but some of my dependencies use other dependencies at compiletime if not runtime.
For the sake of implementing XPath queries in Amphiarao & compiling Khronos's XML files into OpenGL language bindings the heavier-weight Haskell XML Toolkit is used.
Looking just at it's core logic is a Parsec parser to a generic tree structure which in this case holding per-node strings, bytestrings, character references, entity references, ...
1/
... comment strings, CDATA strings, qualified-named processing-instructions with a secondary attribute subtree, qualified-named tags with a secondary attribute subtree, tagged DTD with associated array of attributes, qualified-named attributes (value in primary subtree), & errors with a code & message. Qualified names internally consist of local & namespace parts with a corresponding namespace URI, but those setters aren't directly in the public API.
2/3?
HXT also provides several typeclasses, operators, & utilities for easily traversing, validating, & transforming XML. With XSLT, XPath, etc implemented straightforwardly in seperate hackages, though the datamodel just described seems specifically designed for XPath judging by my attempts to implement XPath upon XML Conduit.
On the other end of the XML Light is a relatively-trivial self-contained (beyond importing better text encodings) XML parser which for me is used indirectly to parse SVG.
3/4
@worldsendless Personally I don't mind XML (though it does have some ugly APIs & usages, but it also has some great APIs like Light XML or Expat) & I don't see JSON as being anything better.
Then I again yes JavaScript's strongly-ingrained API is amongst the ugliest XML APIs having been designed in the midst of Java-style OO hype. That & SOAP is probably where most of the XML hate comes from.