In honor of SysAdminDay, I’d like to give a shout-out to library sysadmins everywhere. Not only do they keep the networks running, the PCs together, the OPAC up and running during a Slashdotting (hey, you never know, it just might happen), the obscure 20-year-old CD-ROM databases alive, and the various dis-integrated library applications tied together, they give the catalogers sharing the basement offices somebody to talk to!

About a week ago, I set up an IRC bot in #kohanews on freenode to monitor the goings on around Koha and report them. It announces when new patches have been added to the git repository, when there as activity in bugzilla or the wiki, and some other useful events. I mentioned it to a few people and encouraged them to idle there if they’re interested.

In the past week or so, I have learned a few things:

1. There is a lot more happening on the wiki than I knew. The english part of the wiki is just the tip of the iceberg, I guess. There are articles there in languages I can’t even make out. I’m excited to see the large and growing amount of documentation we have
2. People report a lot of bugs. I only see a small fraction of the bugs reported, probably because I’m not set as the owner for any parts of the application, and I have only worked on a few small parts of the application so far. But, there are a ton of bugs being reported, and a ton of information about existing bugs is being added. I think that’s a great thing. I don’t actually use the application for real work, so I may never notice the problems that the users do. We developers depend heavily on input from our users to point out areas for possible improvement. Now, of course I wish that there weren’t as many bugs in the application, but we can’t fix them if they’re not reported. I’d rather have the same bug reported 10 times than not at all.
3. There are lot more people actively contributing to Koha than I knew about. Not all contributions are patches. There are a bunch of people editing the wiki, reporting bugs, testing new features, and helping in ways other than submitting patches. Thanks. You’re really helping out. Please keep it up.

So, if you’re interested in keeping tabs on the newest activity, and you’re comfortable with IRC, feel free to drop by #kohanews on freenode and idle. You can even speak up occasionally if you want!

Lately I’ve been thinking about how to represent information about XML paths and data as a string.

For example, I’d like to be able to record the origin of this data:

<titleInfo type="alternative">
<title>Special edition using XSLT</title>
</titleInfo>

as something like this (with id and data as properties in a JSON object):

{"id":"titleInfo-2@type=alternative\title-1","data":"Special+edition+using+XSLT"}

I could then take the preceding id string, extract the provenance of the data, and recreate the original XML document.

Here’s how I’ve tried encoding the XML path and data using an XSLT stylesheet:

For each text element, create an id consisting of:

1. Each ancestor (except the root)
2. A dash to delimit the ancestor element’s name from its position
3. The integer position of that node in the XML file (using )
4. Each of the ancestor’s attributes, in the form @attrname=attrvalue
5. A backslash to be used a path delimiter
6. The text element’s name

With this id, I believe I now have everything I need to reconstruct the node that the data referenced by that id came from.

After playing around with this a bit, I realized that what I’d done was basically reinvent XPath! In XPath, the preceding path in the id string would be represented as:

/titleInfo[1]@type=alternative/title[0]

OK…so next idea is to see if there are libraries out in the wild wild web for creating XML documents from XPath expressions (and not just querying XML documents). I see that the Perl module XML::XPath may offer a solution.

I also wonder if this is how XForms libraries keep track of what parts of an XML document have been edited….