dxml 0.2.0 released

[rikki cattermole]

On 12/02/2018 2:45 PM, Chris wrote:
> On Monday, 12 February 2018 at 14:04:38 UTC, Jonathan M Davis wrote:
>> On Monday, February 12, 2018 12:38:51 Chris via Digitalmars-d-announce 
>> wrote:
>>> On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
> 
>>
>> However, std.xml does not support the DTD section, and glancing over 
>> it, it doesn't look like it even handles skipping the DTD section 
>> properly (it doesn't handle the fact that '>' can appear within quoted 
>> sections within the DTD). So, dxml is not worse than std.xml in that 
>> regard, and we wouldn't lose any functionality by having dxml replace 
>> std.xml. It just wouldn't necessarily do as much as some folks might 
>> like.
> 
> I thought the same when I glanced over std.xml. There's no DTD support 
> there either and I don't think it would be a deal breaker for most users.
> 
>> My guess is that DTD support won't be a deal breaker given that 
>> std.xml doesn't support it, that std.xml has needed to be replaced for 
>> years now, and that no one else is working on replacing it, but I 
>> don't know. Disagreements over what should be done with std.json's 
>> replacement has meant that it has never been replaced even though 
>> significant work was done towards replacing it, so unfortunately, 
>> there's already precedence for a module not being replaced with 
>> something better due to disagreements over what the replacement would 
>> ideally be. So, I don't know.
>>
>> - Jonathan M Davis
> 
> Wasn't there a replacement module that never got past the initial review 
> steps? Some GSoC thing or so. But I wonder if that module would be up to 
> the latest D standards.

https://github.com/dlang-community/experimental.xml

Code isn't great, and not complete yet.
Author has just disappeared sadly.

> While one may argue that DTD support is important, I would rather have 
> something fast and simple like dxml that covers, say, 90% of the cases 
> than nothing. It doesn't make sense to me that we should accept the 
> current situation, only because of some bikeshedding that concerns 10% 
> of the use cases. After all, it's only a module not a fundamental 
> decision that concerns the direction D will take in the future. I think 
> stuff like that can seriously turn off potential users. A lot of useful 
> things begin with one person deciding to give it a go. vibe.d, dub, 
> DScanner and DlangUI, for example. If the creators had started 
> bikeshedding before writing the first line of code, there would still be 
> a flamewar about the best way to go about it - and nothing would have 
> happened.

Everything you have mentioned is not in Phobos. Just because something 
is 'good enough' does not make it 'good enough' for Phobos. In the words 
of Andrei "Good enough is not good enough", we need to aim higher to 
show what we actually can do.

Personally I find J.M.D. arguments quite reasonable for a third-party 
library, since yes it does cover 90% of the use cases.