1.3.1. An Operating System and Java

I say this almost tongue in cheek; if you expect to get through this book with no OS (operating system) and no Java installation, you just might be in a bit over your head. Still, it's worth letting you know what I expect. I wrote the first half of this book and the examples for those chapters on a Windows 2000 machine, running both JDK 1.2 and JDK 1.3 (as well as 1.3.1). I did most of my compiling under Cygwin (from Cygnus), so I usually operate in a Unix-esque environment. The last half of the book was written on my (at the time) brand new Macintosh G4 running OS X. That system comes with JDK 1.3, and is a beauty, for those of you who are curious.

In any case, all the examples should work unchanged with Java 1.2 or above; I used no features of JDK 1.3. However, I did not write this code to compile under Java 1.1, as I felt using the Java 2 Collections classes was important. Additionally, if you're working with XML, you need to take a long hard look at updating your JDK if you're still on 1.1 (I know some of you have no choice). If you are stuck on a 1.1 JVM, you should be able to get the collections from Sun (http://java.sun.com), make some small modifications, and be up and running.

1.3.2. A Parser

You will need an XML parser. One of the most important layers to any XML-aware application is the XML parser. This component handles the important task of taking a raw XML document as input and making sense of the document; it will ensure that the document is well-formed, and if a DTD or schema is referenced, it may be able to ensure that the document is valid. What results from an XML document being parsed is typically a data structure that can be manipulated and handled by other XML tools or Java APIs. I'm going to leave the detailed discussions of these APIs for later chapters. For now, just be aware that the parser is one of the core building blocks to using XML data.

Selecting an XML parser is not an easy task. There are no hard and fast rules, but two main criteria are typically used. The first is the speed of the parser. As XML documents are used more often and their complexity grows, the speed of an XML parser becomes extremely important to the overall performance of an application. The second factor is conformity to the XML specification. Because performance is often more of a priority than some of the obscure features in XML, some parsers may not conform to finer points of the XML specification in order to squeeze out additional speed. You must decide on the proper balance between these factors based on your application's needs. In addition, most XML parsers are validating, which means they offer the option to validate your XML with a DTD or XML Schema, but some are not. Make sure you use a validating parser if that capability is needed in your applications.

Here's a list of the most commonly used XML parsers. The list does not show whether a parser validates or not, as there are current efforts to add validation to several of the parsers that do not yet offer it. No overall ranking is suggested here, but there is a wealth of information on the web pages for each parser:

• Apache Xerces: http://xml.apache.org

• IBM XML4J: http://alphaworks.ibm.com/tech/xml4j

• James Clark's XP: http://www.jclark.com/xml/xp

• Oracle XML Parser: http://technet.oracle.com/tech/xml

• Sun Microsystems Crimson: http://xml.apache.org/crimson

• Tim Bray's Lark and Larval: http://www.textuality.com/Lark

• The Mind Electric's Electric XML: http://www.themindelectric.com/products/xml/xml.html

• Microsoft's MXSML Parser: http://msdn.microsoft.com/xml/default.asp

WARNING: I've included Microsoft's MSXML parser in this list in deference to their efforts to address numerous compliance issues in their latest versions. However, their parser still tends to be "doing its own thing" and is not guaranteed to work with the examples in this book because of that. Use it if you need to, but be willing to do a little extra work if you make this decision.

Throughout this book, I tend to use Apache Xerces because it is open source. This is a huge plus to me, so I'd recommend you try out Xerces if you don't already have a parser selected.

1.3.3. APIs

Once you've gotten the parser part of the equation taken care of, you'll need the various APIs I'll be talking about (low-level and high-level). Some of these will be included with your parser download, while others need to be downloaded manually. I'll expect you to either have these on hand, or be able to get them from an Internet web site, so ensure you've got web access before getting too far into any of the chapters.

First, the low-level APIs: SAX, DOM, JDOM, and JAXP. SAX and DOM should be included with any parser you download, as those APIs are interface-based and will be implemented within the parser. You'll also get JAXP with most of these, although you may end up with an older version; hopefully by the time this book is out, most parsers will have full JAXP 1.1 (the latest production version) support. JDOM is currently bundled as a separate download, and you can get it from the web site at http://www.jdom.org.

As for the high-level APIs, I cover a couple of alternatives in the data binding chapter. I'll look briefly at Castor and Quick, available online at http://castor.exolab.org and http://sourceforge.net/projects/jxquick, respectively. I'll also take some time to look at Zeus, available at http://zeus.enhydra.org. All of these packages contain any needed dependencies within the downloaded bundles.

1.3.4. Application Software

Last in this list is the myriad of specific technologies I'll talk about in the chapters. These technologies include things like SOAP toolkits, WSDL validators, the Cocoon web publishing framework, and so on. Rather than try and cover each of these here, I'll address the more specific applications in appropriate chapters, including where to get the packages, what versions are needed, installation issues, and anything else you'll need to get up and running. I can spare you all the ugly details here, and only bore those of you who choose to be bored (just kidding! I'll try to stay entertaining). In any case, you can follow along and learn everything you need to know.

In some cases, I do build on examples in previous chapters. For example, if you start reading Chapter 6, "Advanced DOM" before going through Chapter 5, "DOM", you'll probably get a bit lost. If this occurs, just back up a chapter and you'll see where the confusing code originated. As I already mentioned, you can skim Chapter 2, "Nuts and Bolts" on XML basics, but I'd recommend you go through the rest of the book in order, as I try to logically build up concepts and knowledge.