dxml 0.1.0 released
bauss
jj_1337 at live.dk
Sat Feb 10 19:24:48 UTC 2018
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.
More information about the Digitalmars-d-announce
mailing list