std.xml and Adam D Ruppe's dom module

[Jonathan M Davis]

On Tuesday, February 07, 2012 00:15:37 Alvaro wrote:
> The current std.xml needs a replacement (I think it has already been
> decided so), something with a familiar DOM API with facilities to
> manipulate XML documents.
> 
> I needed to do a quick XML file transform and std.xml was of little use.
> Then I found this Adam D. Ruppe's library:
> 
> https://github.com/adamdruppe/misc-stuff-including-D-programming-language-we
> b-stuff
> 
> Its "dom" module has that sort of Javascript-like DOM manipulation code.
> It has getElementsByTagName(), getElementById(), firstChild, nodeValue,
> innerText (read/write), toString, etc. Easy and performing. The XML
> processing I needed to make took minutes with that!
> 
> I thus suggest, if licensing allows (?) and no better exists, to base a
> newer std.xml module on that code as a starting point. Well, after
> cleaning up and fixing anything necessary. For instance, that module was
> designed for Web server programming and is targeted at HTML DOM mainly.
> It has stuff to deal with CSS styles, HTML specific elements and their
> special handling (table, a, form, audio, input, ...). A lot of that can
> be left out in XML.

Tomek Sowiński was working on a new std.xml which was intended to become the 
new std.xml, but he hasn't posted since June, so I have no idea where that 
stands. And I believe that xmlp is intended as a possible candidate as well.

The main issue is that we need someone to design it, implement it, and push it 
through the review process. Just suggesting it is not enough. Someone needs to 
champion the new module. And no one has gone all the way with that yet.

Also, two of the major requirements for an improved std.xml are that it needs 
to have a range-based API, and it needs to be fast. I don't know how Adam's 
stacks up against that. Tango's XML parser has pretty much set the bar on 
speed ( http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-
parsing-xml/ ), and while we may not reach that (especially with the initial 
implementation), we want a design which is going to be fast and have the 
potential of reaching Tango-like speeds (whether that's currently possible or 
not with a range-based interface is probably highly dependent on dmd's current 
optimizition capabalities - inlining in particular).

So, if Adam wants to work on getting his XML module into Phobos (which I 
question, since if he really wanted to, I would have expected him to do it 
already) or if someone else wants to work on it (and the license allows it), 
then it may be possible to get it into Phobos. But someone needs to put all of 
that time and effort in.

- Jonathan M Davis