Tuesday 2 June 2009

Book review - Processing XML Documents with JDeveloper 11g

I was recently asked to write a book review on Processing XML Documents with JDeveloper 11g by Deepak Vohra, among several other bloggers here, here, here and here.

The thing about book reviews, like movie reviews, is the interpretation by the reviewer is subjective. The trick is for you the review reader to work out does the reviewer have the same tastes and likes as you. If yes that should mean that the book review will be relevant to you potentially giving a recommendation that suits your needs. If no you might miss a really good book or waste a couple of those hard earned squid.

So where do I come from to help you assess if I'm "your" type of reviewer? I'm a both a consultant *and* a trainer. I'm interested in how the story is told as much as what is told. I'm looking for clear examples, a logical A-B-C progression path, and like everyone else something to keep me interested, especially important in the often dreary world of computing. In addition I use XML and JDeveloper in my day to day job, so I should be a prime candidate for this book.

In considering the book's title and what I'd expect to find between the book's covers, I'd want to see a discussion around the XML facilities in JDev 11g vs earlier versions, a comparison of JDev's XML facilities against the other IDEs, then a road-show through the XML features vs the common XML tasks in Java of creating/parsing XML, XML schemas & validation etc. Let's see how the book fairs.

Firstly the Who-is-this-book-for section somewhat incorrectly states readers need to know just XML basics: "what an XML document is, what XSLT is, what XPath is, and what an XML schema is." In the very first chapter it introduces the DOM and SAX parsing methods without any explanation of how they work or the differences, so it actually assumes more knowledge than stated. Anybody with a limited knowledge of XML should definitely look at a book tailor fitted to explaining XML alone before reaching for this book.

The book does receive bonus points for including the latest version of JDeveloper 11g. On average, computing books have short half-lives because the technology they're based on is updated or replaced regularly. As a book purchaser you want your investment to last long as possible without becoming instantly redundant. The fact this book is written against the latest JDev 11g release should help extend that investment, until Oracle does another rewrite of the IDE.

Yet on considering my expectations for the book, it doesn't take the opportunity to discuss JDeveloper in general, nor its XML feature support. This is a shame as it doesn't help to "sell" JDeveloper and its benefits in any direct manner.

But in addressing my expectations again the book takes you through typical stuff you want to do with XML via Java, such as creating and parsing XML, working with XML schemas, XML validation, XPath and so on very much in a cookbook like fashion – here's a recipe now you follow it. I somewhat don't understand the inclusion of chapters on XML to PDF, XML to Excel, and XML Publisher, as the book's title is about processing XML in JDeveloper, those chapters relate to specific XML use cases not a generalised XML requirement. Their exclusion could have made this a concise JDev-XML guide.

If I consider the writing style used, personally from reading around a zillion technical books I tend to lump technical books into 3 styles:

a) the "Head First" series which takes an extreme narrative style
b) the other end which is just reams of code and specifications which isn't a book but rather a printed manual, it typically gives no narrative, just cold hard "this is how you do it" facts
c) and the books that lie in between

For me a good book is one that lies in that nice gray area "c". I want the writer to keep me interested with a narrative style while reading the boring technical bits, information about the pros and cons, some background information, but not bury me in opinions and jokes (and crosswords and word puzzles for that matter).

For me this book falls closer to "b", you can tell it's written by a programmer by its dry clinical dry style. For instance chapter 1 introduces the fact that Oracle XDK 11g provides an API that extends JAXP, but then doesn't discuss what the Oracle XDK 11g is, why Oracle chose to override JAXP, and what benefits you'll get over using the non-standard libraries. So you get a "this is how you do it" style rather than any discussion on the "why", which I think is important for learning. Some readers might be smart enough (I know I'm not ;-) to conclude the "why" without any explicit description, so this book might suit you directly.

If we take the fact the book includes a large amount of code, in particular XML, care by the author and the publisher needs to be taken to present code in a concise way, well laid out code that is documented clearly, because code is central to the book's value. There are numerous examples in the book where code stretches across several pages without explanation, code layout is messy in areas, and given the quantity of code at times it's hard to work out which bit I should be focusing on (a problem that is often magnified by the "over-wordiness" of XML). I've no doubt given the amount of code in the book achieving this consistency is a very hard task, but again it detracts from the quality of the book.

Finally I mentioned that it's important for technical books to present a logical A-B-C progression path in assisting the reader to learn. Given this book's clinical style, where in each chapter it discusses the JDev environment setup, then a bullet point section walk through of the code, and how to run and see the results in the end, it does achieve this goal. Again the "why" is often missing in this book, but you do see the A-B-C progression path which is important.

In summary would I recommend this book? If you're simply looking for a cookbook like style technical book the answer is yes, but (and there is always a but).... for myself I miss the "why" in this book, the part that helps me learn the peripheral issues, so the answer is no.

No comments: