Amazon has done it again. Thanks to all the pre-orders from Cafe con Leche readers, the third edition of XML in a Nutshell has gone straight from "Not Yet Released" status to sold out and "Usually ships within 3 to 5 weeks" without stopping at "Ships within 24 hours" first. Thanks for all the orders! Based on past experience, Amazon should have more copies in stock a lot sooner than 3 to 5 weeks. If you order it today, you'll probably get it some time next week.
In my continuing efforts to make XML a lot less irritating for in-memory manipulation, I've posted beta 6 of XOM, my dual streaming/tree API for processing XML with Java. This beta is primarily a bug fix release. It also polishes off some rough edges in various corners of the API. Changes in this release include:
The deprecated setNodeFactory() method in XSLTransform has been removed. This is the only API-level change in this release.
The strings returned by toString in Comment, ProcessingInstruction, Attribute, and Text
are all now truncated if they get too long. Furthermore any embedded
line breaks and tabs are escaped as \n, \r, and \t. This makes the
objects easier to inspect in various debuggers and loggers.
SAXConverter no longer converts XOM xml:base attributes into SAX attributes. Instead the xml:base attributes are used to determine the URI information the Locator reports. Providing xml:base attributes as well would risk double counting some relative URLs.
Windows users may have a little trouble with the zip archive, because it contains some files used to test the conversion of file names to URIs when the file names have illegal characters such as angle brackets that Windows doesn't like. You may, therefore, see some error messages while unzipping. Ignore them. The only practical effect this has is that seven of the 964 unit tests will fail on Windows. This will be fixed in the next release. All platforms may also have trouble with a file named resumé.xml, included to test the conversion of file names with non-ASCII characters to base URLs. In this case, all modern platforms should be able to handle the file. However, the Ant zip and tar tasks are mangling the é character when they add the file to the archive. Either the CVS repository on java.net or the Eclipse CVS client has a similar problem. Regardless, the functionality of the core API is not affected, and XOM does work well with files whose names contain unusual characters, as these test cases were written to prove. I just can't seem to get them into the distro. Suggestions for fixing this are appreciated.