Hi Frank,
I’ve been doing some work on a new CSL processor (citeproc-js), and
have made some progress. The next academic term is approaching,
though, and I’ll be battening down the work on citeproc-js over the
next few days. I’ll be pretty much leaving the code alone until
sometime during the summer,
Whose “summer”; the one down south, or up north? So June, or December?
Why, my summer, of course! Things will quieten down here again in July/August.
Also, just a couple of more questions …
but I don’t claim ownership of it, and any
work by others on the project will be very welcome as far as I’m
concerned. (In fact, it’s probably better for the long term if I’m
not the primary maintainer. I’m a hobbyist, my skill level is not
that high, and my ability to focus on programming issues varies with
the season.) Before downing tools, I’ll go through the code to update
the comments and bring them into line with the state of the code. The
test suites don’t show much organization, but I’ll probably leave
those alone for the present.
It’s been an exciting ride over the past month. There’s a lot still
to do, but most of the seriously worrisome issues have been cleared.
Can you estimate what percentage is complete?
I tend to be over-optimistic. But in terms of time, I’d say it’s
maybe 40% done in the coding. It’s about 1600 lines at the moment,
half the size of the csl.js in Zotero. I’d expect it to swell
significantly over the current implementation in total size, because
the definitions of individual attributes in citeproc-js are more
verbose at the compiler level (although the runtime it will generate
will be much more spartan).
Here are some of the highlights:
With test-driven development, you write the tests first, then write
the code until they pass.
But given that all test pass but you’ve said there’s still “a lot to
do” I take it that’s not exactly the approach you’ve taken.
Oh, darn, I messed up again! Sorry about that, I’ll try to do
better in the future. 
But seriously, I felt my way in a spiral, with bits of code, then
tests, then rewriting of the code to make it more readable. Some
parts of the code have been rewritten three or four times as new
issues came up. I’ve watched XP teams work, it’s been a similar
process, except that I didn’t have a programming partner and II was a
neophyte in the language when I started writing – and I wrote a lot
more verbal commentary as I went along because I’m chatty by nature.
You gets what you pays for.
So would it be fair to say that the next step really ought to be to
sort out the remaining tests?
If yes, do you have some input on what they should be?
Yep, absolutely. The only big piece of infrastructure still to be
built is the disambiguation/sorting registry. I can certainly provide
internal unit tests for that, if there’s need.
For the CSL language, anyone building an engine would want to have at
least one test for each element, attribute and option, and test suites
for known hard cases (like et al., disambiguation, and sorting). It
would be great if you as the language designer could provide the
hard-case items, to be sure behaviour is defined as you intend.
Or, if you can find some remaining time, can you imagine starting to
put those in place so that others can enter and figure out how to make
them pass?
Sure thing. Dividing the work between test-writing and coding is
ideal. There is a proposed generic test layout from Simon (with a
couple of tiny changes by me) at data/README-3.txt in the archive. If
the layout can be agreed and a file hierarchy set up somewhere, I’ll
be happy to chip in.
BTW, I converted you TODO.pdf to a text file in the repo for editing purposes.
Thanks, that was a hasty addition, to be sure I didn’t lose the message.
