std.experimental.xml available on DUB

Lodovico Giaretta via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Mon Aug 1 05:40:48 PDT 2016


On Monday, 1 August 2016 at 07:38:29 UTC, Guillaume Piolat wrote:
> On Sunday, 31 July 2016 at 18:56:33 UTC, Lodovico Giaretta 
> wrote:
>>
>> kxml is also way limited with respect to std.experimental.xml. 
>> It does not support many features, like custom allocators 
>> (because they don't exist in Java). It does not have to strive 
>> to be @nogc (because it does not exist in Java). It does not 
>> support high customization, with custom lexers, pluggable 
>> validations, full DOM Level 3 support, with the ability for 
>> the user to provide a custom DOM implementation and have the 
>> DOMBuilder use it instead of the default provided DOM 
>> implementation. It does not support SAX with DbI on the 
>> handler type. It does not support outputting XML using a 
>> custom formatter, again with DbI.
>
> Okay, just wanted to know what we are buying with (supposedly) 
> more code.
> For reference I was speaking of the D kxml package, which is a 
> DOM parser than can range-iterate on nodes using XPath.

Ouch. Looks like I misunderstood you then. I apologize.

I don't know anything about that D package, but I can safely 
assume that this library will provide more functionalities and 
(most of all) more customization points. It's designed as a 
collection of components, each of with can be customized or even 
substituted with a user defined one. This is what such a big 
quantity of code will buy.

There are various principles one can use when building a library. 
In this case I didn't choose minimality. I prefered extensibility 
and customizability.


More information about the Digitalmars-d-announce mailing list