On Wed, 2013-05-15 at 12:27 +0100, Alix Pexton wrote:
[…]
> libxml2 and its kin should definitely get the deimos treatment!

Indeed. Sadly, I doubt I will have time to even look at it for at least a couple of months.

> I don't know how hard it might be to create a wrapper with an idiomatically D-ish interface though.

I guess the trick will be to look at how lxml provides the ElementTree API (very Pythonic) over libxml2 and take a leaf from that book.

I am assuming SWIG would not be a good idea here.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, May 15, 2013 09:52:09 Alix Pexton wrote:
> I've also not really thought that much about the API yet, I have a plan for the features that I want, but recall from previous discussions that SAX-like callbacks were desired by some, and full DOM-like interfaces by others.

Ideally, I would expect multiple levels to it. The lowest one probably wouldn't even be a SAX parser (something closer to StAX probably), and then SAX and DOM parsers could be built on top of that. Then you can get the absolute best speed possible out of it depending on what your requirements are, and we give people the choice between SAX and DOM (as well as the lower- level API if they really want raw speed and don't need the higher level features of either SAX or DOM).

- Jonathan M Davis

On Wednesday, 15 May 2013 at 10:39:41 UTC, Russel Winder wrote:
> It might be worth noting here that SAX and DOM have not been
> distinguished so far in the thread.  I would have thought SAX would be really easy in D.
Indeed. My original question is specfic to XML document generation in D code, not necessarily reading (although any half-decent DOM library needs to be able to read files as well as write them). I'm not very familiar with SAX, but Wikipedia says that it's not standardised and so, if I understand correctly, there would be varying implementations of it.

> Although it might be nice to have D implementations, perhaps D might
> follow Python and wrap a rather good system so as to get something with
> full validation and XPath sooner rather than later?

I think that this is a better approach to take. Surely Windows has an XML library and that would have to be done is write a single header file that would link to the XML library on the operating system? I know, probably far more difficult to implement than it sounds...

On 15/05/2013 12:45, Russel Winder wrote:
> On Wed, 2013-05-15 at 12:27 +0100, Alix Pexton wrote:
> […]
>> libxml2 and its kin should definitely get the deimos treatment!
>
> Indeed. Sadly, I doubt I will have time to even look at it for at least
> a couple of months.

I took a look... Why is it that I find the prospect of moulding a wrapper around a c-lib more daunting than writing my own d-lib from scratch?

Mike Parker's GameDev.net has made a timely arrival, but although reading it makes me feel more knowledgeable about the process, I feel no more confident ><

>> I don't know how hard it might be to create a wrapper with an
>> idiomatically D-ish interface though.
>
> I guess the trick will be to look at how lxml provides the ElementTree
> API (very Pythonic) over libxml2 and take a leaf from that book.

There is a section on the lxml website that goes into very brief detail about how the binding works, it uses cython to wrap the c structs into proxy objects. I should probably say that while I have written code in python, I have never written any pythonic code, I'm not sure what it should look like, so I don't think looking at lxml would give me any insight into how to wrap libxml2. After all, getting away from python is my motivation for putting better XML support into D.

> I am assuming SWIG would not be a good idea here.

That would be a question to ask a SWIG guru (or even a htod guru).

A...

On Wednesday, May 15, 2013 20:08:13 Borden wrote:
> I think that this is a better approach to take. Surely Windows has an XML library and that would have to be done is write a single header file that would link to the XML library on the operating system? I know, probably far more difficult to implement than it sounds...

Long term, that is very much the wrong way to go. Thanks primarily to slicing, parsing is one area where D really shines and is likely to outstrip the competition of the code is well-written. And it does even better of any aspects of it can be generated at compile time (as happens with std.regex - the compile time stuff that it has is the faster regex library on the planet). Also, as far as the standard library goes, we want a range-based XML solution, which is likely to be much harder if you're trying to wrap a C API. So, in this particular case, wrapping a C library would be a stop-gap solution at best. In other cases, it may be the best way to go, but parsing is one area where D stands out. Tango's XML parser is lightning fast and was a great highlight for D1 (and it should be useable in D2 now that Tango has been ported to D2, though given the difference in license, it could never be put into Phobos). It's just that std.xml is a particularly poor implementation. We can do far, far better.

- Jonathan M Davis

On Thursday, 16 May 2013 at 19:23:37 UTC, Jonathan M Davis wrote:
> So, in this particular case, wrapping a C library would be a stop-gap solution at best. In other cases, it may be the best way to go, but parsing is one area where D stands out.

Thank you for the insight, Jonathan,

You have the advantage on me as you know far more about this and I know next to nothing. It's amusing, as a general observation, how object-oriented programming was supposed to make code reusable and yet it seems that these essential libraries constantly need rewriting in new languages because they're 'programmed wrong.'

As I've mentioned in this thread http://forum.dlang.org/thread/bsbdpjyjubfxvmecwhjl@forum.dlang.org my EPUB conversion has hit something of a brick wall as I'm finding DDoc's macros to be very awkward to use and, in order to do what I need them to do, I'd have to rewrite much of the documentation! I'd be interested in feedback on that thread...