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.
