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.


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.

Reply via email to