Validating XML with DTDs
You might have noticed that until now we haven't said much about what operating system you're using. That's because it doesn't matter. XML is just text and can be created on any operating system where you can create a text file.
Actually programming, however, is generally much more restrictive than that. After all, you can't just take a program written for, say, the Apple Macintosh and run it on Windows 98, right?
Well, of course, that used to be correct, and for good reason. The internal workings of each operating system and computer are different, so, of course, a program would have to know the right language to speak to them. This, as you might imagine, doesn't really fit well with the nature of the Web, where the same content can be accessed on virtually any type of system. So, it was only a matter of time before someone proposed a universal language of sorts.
That someone, in this case, was Sun Microsystems. Sun already had a decent foothold in the Internet space when it announced that it was working on Java, a programming language that would run in a variety environments, because at that time virtually all Internet servers ran on an operating system called UNIX, and a large percentage of those used Sun's flavor of UNIX, Solaris.
Of course, there weren't too many desktop machines using UNIX at the time, so the discrepancy between software that would run on the server and software that could run on the browser, or client, was huge.
Java would change all that.
The key to Java is the idea of the Java Virtual Machine, or JVM. The JVM sits between the code and the operating system, working as an interpreter, as illustrated in Figure 3.1.
){kind=link}
Figure 3.1 A single Java program can run on any operating system, as long as a Java Virtual Machine is available.
So, as long as there is a Java Virtual Machine for your operating system, be it Windows 98, UNIX, or even something you've written yourself, the same Java code will run on it. Hence the slogan, "Write Once, Run Anywhere."
Note - Purists will note that in the late 1990s there was a bit of corporate ugliness over certain vendors producing versions of Java optimized for particular operating systems, leading to code that wouldn't necessarily run anywhere. This led to Sun's "100% Pure Java" and "Java Compatible" programs. For the purposes of this book, we won't be touching those discrepancies, and we'll rely only on Pure Java software.
The choice of words to describe the JVM as an interpreter was intentional. Programmers experienced in languages such as C++ will note that there are two types of languages: compiled and interpreted. A compiled language, such as C or C++, is written and then translated into the native language of the system on which it will run, which makes it fast. The downside is that because it's already been translated into that system's particular native language, it generally can't be used in a different environment. On the other hand, an interpreted language, such as BASIC or any scripting language, isn't translated into the native language until it's run, which makes it much more portable.
So, where does Java fall into that spectrum?
Somewhere in the middle, actually. A Java program is compiled into byte-code, which is then interpreted by the JVM when it's run. In the years since Java's introduction, Sun has also added a Just In Time, or JIT compiler, which compiles the code just before it's run, leading to improvements in performance. For the sake of portability, however, we'll think of Java as an interpreted language for now.
So, what does that all mean to us?
It means that Java, which is not tied to any particular operating system, is a natural choice for developing XML applications, which are not tied to any particular platform. The vast majority of XML tools and applications are produced in Java, and we're going to follow that trend.
If you don't have any Java experience, don't panic! We'll walk through each concept as it's needed, so you'll feel comfortable with what we're doing, and we won't pull any surprises.
Installing the Java 2 Software Development Kit
Before we can even think about running any Java applications, much less writing any, we need to install a few things. First, we need a Java Virtual Machine. We also need the base "classes," or programs that form the underlying structure of the language. Finally, we need the compiler that will turn our programs into byte-code that the JVM understands.
Locating the Java 2 SDK
Where to get all this depends on what operating system you're running. Sun Microsystems maintains versions for Microsoft Windows, Linux, and, of course, Solaris. There are Java Virtual Machines available from other companies, such as Apple, Microsoft, and IBM, as well. To download from Sun, point your browser to
We are going to use Java 2 SDK Version 1.3 for the examples in this book, but if this page shows a newer version, you should be fine using it. If your operating system isn't shown on this page, go to
http://java.sun.com/cgi-bin/java-ports.cgi
for a list of available versions. Make sure that you get the Software Development Kit, or SDK, and not just a runtime environment. For instance, if you're running MacOS and you follow the preceding link, you'll find a page that describes the necessary steps to get the Macintosh Runtime for Java, or MRJ 2.2.2. Although you will need this, if you want to actually build Java programs (as we will be doing throughout the rest of the book), you will also need the MRJ SDK. To get it, follow the links to
http://developer.apple.com/java/download.html
and click the MRJ 2.2 SDK link in the sidebar. If you have trouble locating it, the direct download link is
ftp://ftp.apple.com/developer/Development_Kits/MRJ_SDK_2.2_Install.sit.bin
This version of the SDK is only Java 1.1.8, but this shouldn't be a problem for any of the coding that we're doing. The only potential problems stem from the applications that we'll be downloading, and all of them have instructions for those who are still using Java 1.1.8.
Excursion
What Do All These Acronyms Mean?
The programming world has been awash in acronyms since long before BASIC came into play. Unfortunately, now that marketing has entered into the picture, it's become even worse.
The software we need to build Java applications used to be known as the JDK, or Java Developer's Kit. (Some developers, in fact, still refer to it that way.) This included the JVM, or Java Virtual Machine, the compiler, javac, and several other tools. The first version was released as JDK 1.0.
Eventually, improvements were made, all the way up to JDK 1.1.8. At that time, Sun changed the focus of development (and the way many features were implemented) and decided to rename the platform as Java 2.
Unfortunately, Sun didn't change the version numbers. This means that Java 2 is actually what would have been called JDK 1.2, but is now Java 2 Software Developers Kit version 1.2. (Or, in our case, version 1.3.)
So, don't be alarmed if you can't find "the JDK." It's there; it's just been renamed.
Installation
Because the Java SDK is an application like any other, it normally comes in the form of an installer, with a wizard to guide you through your installation choices. Installation generally involves the following steps on Windows, with a similar set for other platforms:
Close any open applications.
-
Double-click the downloaded file (for example, j2sdk1_3_0-win.exe) to start the installer.
Read and accept the license agreement.
Choose a destination folder, as shown in Figure 3.2. You can choose whatever destination makes sense for you, but all instructions in this book will assume that you have installed the JDK in the root directory. This makes the destination folder c:\jdk1.3.
){kind=link}
Figure 3.2 Install the JDK in the root directory.
-
Determine what to install, as shown in Figure 3.3. To build and run Java applications, we'll need the program files but not the actual source files. If you're short on disk space, feel free to uncheck Java Sources.
After the installer is complete, you can delete the downloaded file to recover disk space.
The next two steps are actually optional right now but will save us a significant amount of typing. (We'll also need to set these two variables for future applications, so we might as well take care of it now.)
){kind=link}
Figure 3.3 The actual Java source files are not necessary for this project.
Set the PATH. Although we are striving for a browser-based environment, we will be doing some work from the command line. This means that we'll be typing instructions into a command prompt (or similar) window. If we wanted to use, say, javac, we would need to type
c:/jdk1.3/bin/javac myFile.java
Although there's nothing actually wrong with that, it can get tiresome in a hurry, and it is just that much more likely to cause typos. Fortunately, Windows provides a way to shortcut that process, using the PATH variable. If you type, instead,
javac myFile.java
Windows checks any directory listed in the PATH variable, looking for a program called javac. We'll want to add this to the PATH variable permanently (as opposed to every time we use it). The way to do this varies by operating system.
For Windows 95/98, we're going to put it into the AUTOEXEC.bat file, which runs every time the machine restarts.
Warning - MAKE A BACKUP OF THE AUTOEXEC.bat FILE BEFORE YOU CHANGE IT. Errors in this file can be a nightmare and can prevent the machine from operating properly, or even booting up. Please be careful!
After making a backup of AUTOEXEC.bat, open the file in Notepad (NOT WordPad!) and find the PATH statement. It typically looks something like this:
PATH C:\WINDOWS\COMMAND;C:\WINDOWS;
Add the bin directory, so that the statement looks something like this:
PATH C:\WINDOWS\COMMAND;C:\WINDOWS;c:\jdk1.3\bin;
Save the file.
To test the PATH (and make sure that you haven't introduced errors into AUTOEXEC.bat), open a command prompt window by choosing Start, Programs, MS-DOS Prompt (or the equivalent for your operating system). Type
autoexec
and press the Enter key. This runs the same script that runs when you start your computer. If there were errors, go back and fix them. If necessary, make a copy of the backup you made before you changed anything and start again.
If everything ran correctly, check the PATH by typing
path
at the prompt. You should see a string of directories that includes the one we added.
For Windows NT or Windows 2000, the process is much simpler. Choose Start, Control Panel, System, Environment. Under User Variables, look for PATH and highlight it. This gives you the opportunity to change the value. Add c:\jdk1.3\bin; (or the appropriate directory) to the end of the PATH variable. Do the same thing under System Variables.
Warning - For both Windows 9x and Windows NT/2000 users: If you have a previous version of the JDK installed, make sure that you either update or remove the reference to it, or at least make sure that the new reference comes first because only the first instance will be used.
Accept the changes and test them by opening a command prompt and typing PATH.
-
Set the CLASSPATH. Earlier versions of the Java SDK required users to add a variable called CLASSPATH, which told the application where to look for various code it needed. Java 2 actually works without a CLASSPATH being set, and there are other ways to pass that information into an application, if necessary. Other tools we'll be installing, however, require the CLASSPATH to work properly, so we'll go ahead and set it now.
For Windows 95/98, we'll follow almost the same procedure as setting the path. Make a backup of the AUTOEXEC.bat file and open it in Notepad. If you don't have a CLASSPATH variable being set, add a line under the PATH declaration that looks like this:
SET CLASSPATH=.;
Save the file and run it.
This will tell the application to start looking in the current directory for any code it needs. If you have an existing CLASSPATH setting with information needed by other applications, feel free to leave it, as long as you add the current directory as shown.
For Windows NT/2000, follow the same steps as for the PATH variable to make the preceding changes.
To test the CLASSPATH setting, type the following into a command prompt window:
set
This displays a list of all the current settings and what their values are. You should see a listing for the CLASSPATH.
-
Test the installation. At this point, we don't want to actually write any Java. We just want to be sure that it's installed correctly. To do that, type the following two lines at the command prompt:
cd c:\jdk1.3\demo\jfc\Stylepad
java -jar Stylepad.jar
After a few seconds, this should bring up a word-processor–like window with a page from Lewis Carroll's Alice in Wonderland.
Note - If you downloaded a different version of the JDK, it might have different demos. Typically, they'll fall into two categories: Java foundation classes, or jfc, and applets. We will not be using applets at all, but if they are the only demos you have to test the installation, you'll need to use appletviewer for the test. For example, the standard JDK includes an applet called TicTacToe. To test the installation against this applet, type the following two lines:
cd c:\jdk1.3\demo\applets\TicTacToe appletviewer example1.htmlThis should bring up a small game of Tic Tac Toe.
If you have difficulty with the installation, troubleshooting information can be found at
or on the site from which you downloaded the JDK itself.