On 15/05/2013 06:22, Borden wrote:
Thank you for the feedback, all.
The XML parsing bit is a little important for me because, to generate
the required boilerplate for an EPUB, one necessarily needs to
manipulate XML. The approach I'm thinking for the EPUB is to write a
'generate EPUB from an OPF' program in D and shove it into the tools
directory (hence my earlier question about what 'belongs' in there).
Of course, I'd be happy to set straight to work in writing such a
program (I have some XML experience using PHP and D could not possibly
be any more awkward to use) but I don't want to be calling in libraries
that are likely to be superceded before my patches get reviewed.
As a hobbiest trained in accounting, I'm the last person anyone would
want to work on a programming language. I suppose, though, that I'm
pretty good with standards...
fwiw...
I recently started implementing my own XML lib for D out of frustration
(I want to write addons for inkscape in something that isn't Python).
I had originally planned to "port" my own old Ada XML lib, but upon
reacquainting myself with the official spec I realised that it would
just not cut (no unicode support etc...)
I'm pretty sure anyone with any real experience of writing
lexers/parsers would look at the spec and think it pretty simple, but I
keep finding corner cases and subtleties that I hadn't allowed for in my
adaptation of the grammar.
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.
Anyone who wants a great XML lib in double-quick time should probably
ignore this though, I'm a very slow and rusty coder ><
A...
