std.xml and Adam D Ruppe's dom module
Jonathan M Davis
jmdavisProg at gmx.com
Mon Feb 6 15:45:53 PST 2012
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:
> 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
More information about the Digitalmars-d