How work cascades

Created: 2013/06/23 10:08:32+0000

It started when I noticed that the detached signatures of the RDF documents were not correctly linked. There was an extra '/' at the start of the path. I recognized this problem immediately as a mistake in the XML file. The host is described in the XML file as an entity ending with a '/'. The path following on from this also included a '/' so I thought I would taken 10 minutes to fix and release it. Easy, releasing it would be the hardest part.

I then noticed that there was duplicated triples in the different XML files. I was referring to the same PGP public key in each file using a node ID, which duplicated 5 or so lines in each file. Not technically wrong but not desirable. So I again thought I would take a few more minutes to fix this. I was still editing the same XML files.

I then realized that as I had changed from using an RDF nodeID to a resource to identify the key I should perform content negotiation when requesting the new resource. This would mean editing another XML file and making sure that the content negotiation would resolve correctly. It still looked like a quick job. Testing it was going to be the difficult part but I didn't anticipate any problems.

Naturally I found a bug in the code I used to perform content negotiation. When redirecting to content other then RDF I was sending the browser off the the MIT hosting page for PGP keys. To link directly to my key I used two URL parameters separated by '&' encoded as the entity & in the XML file. The SAX parser I was using was failing to handle the entities correctly. This was a simple but that it did not take me long to identify. The character method of the SAX handler was not taking into account that it might be called more then once for the same element. This was again easy to fix. I quickly changed it to use a stack it would push a StringBuilder on for each element and append text to the top every time characters was called. I wrote a test case for it to prevent regression. I could have stopped here.

I noticed some test cases that were in my deprecated DOM parser but not my new SAX parser. It seemed simple enough to copy them across. The SAX parser failed these tests. Having found failing test cases I set about trying to fix them. I worked out this was caused by a failure to verify the XML file. Naturally because I was using SAX instead of DOM. I did a Quick Fix. I made some changes and was able with a little work to get the tests passing. I released to Maven and thought everything was fine.

Until I tried to use the code I had written and found that it threw exceptions at me. I found that I was not loading the schema file in a way friendly to JARs. At this point I gave up on a Quick Fix and decided to do a Proper Fix. I changed the way I was validating the file from setting the parser to validating to setting the parser factory to use a Schema object. I ensured that the Schema object could be created correctly from a file in a JAR. I changed the interface VariantSAXHandler to return the schema. Allowing people to write custom handlers to parse and verify custom schemas and still be used by my BaseVariantXMLSource class. I changed the XML to require a namespace and published the schema XSD document as part of the Maven generated site.

I released to Maven again, made a couple of minor changes to my website and I was done.

This is how programming work cascades into bigger and bigger problems. This is why things take longer then you expect. There were places I could have stopped but not if I wanted to Do Things Right.