dxml 0.1.0 released

[bauss]

On Friday, 9 February 2018 at 21:15:33 UTC, Jonathan M Davis 
wrote:
> I have multiple projects that need an XML parser, and 
> std_experimental_xml is clearly going nowhere, with the guy who 
> wrote it having disappeared into the ether, so I decided to 
> break down and write one. I've kind of wanted to for years, but 
> I didn't want to spend the time on it. However, sometime last 
> year I finally decided that I had to, and it's been what I've 
> been working on in my free time for a while now. And it's 
> finally reached the point when it makes sense to release it - 
> hence this post.
>
> Currently, dxml contains only a range-based StAX / pull parser 
> and related helper functions, but the plan is to add a DOM 
> parser as well as two writers - one which is the writer 
> equivalent of a StaX parser, and one which is DOM-based. 
> However, in theory, the StAX parser is complete and quite 
> useable as-is - though I expect that I'll be adding more helper 
> functions to make it easier to use, and if you find that you're 
> doing a particular operation with it frequently and that that 
> operation is overly verbose, please point it out so that maybe 
> a helper function can be added to improve that use case - e.g. 
> I'm thinking of adding a function similar to std.getopt.getopt 
> for handling attributes, because I personally find that dealing 
> with those is more verbose than I'd like. Obviously, some stuff 
> is just going to do better with a DOM parser, but thus far, 
> I've found that a StAX parser has suited my needs quite well. I 
> have no plans to add a SAX parser, since as far as I can tell, 
> SAX parsers are just plain worse than StAX parsers, and the 
> StAX approach is quite well-suited to ranges.
>
> Of note, dxml does not support the DTD section beyond what is 
> required to parse past it, since supporting it would make it 
> impossible for the parser to return slices of the original 
> input beyond the case where strings are used (and it would be 
> forced to allocate strings in some cases, whereas dxml does 
> _very_ minimal heap allocation right now), and parsing the DTD 
> section signicantly increases the complexity of the parser in 
> order to support something that I honestly don't think should 
> ever have been part of the XML standard and is unnecessary for 
> many, many XML documents. So, if you're dealing with XML 
> documents that contain entity references that are declared in 
> the DTD section and then used outside of the DTD section, then 
> dxml will not support them, but it will work just fine if a DTD 
> section is there so long as it doesn't declare any entity 
> references that are then referenced in the document proper.
>
> Hopefully, the documentation is clear enough, but obviously, 
> I'm not the best judge of that. So, have at it.
>
> Documentation: http://jmdavisprog.com/docs/dxml/0.1.0/
> Github: https://github.com/jmdavis/dxml
> Dub: http://code.dlang.org/packages/dxml
>
> - Jonathan M Davis

This is going to be really useful for people like me who works 
with webservices using soap.

Thanks for the great work.