Java & XML, 2nd Edition 1

Java & XML, 2nd Edition
Brett McLaughlin
Publisher: O'Reilly
Second Edition September 2001
ISBN: 0-596-00197-5, 528 pages

New chapters on Advanced SAX, Advanced DOM, SOAP and data binding, as well as new
examples throughout, bring the second edition of Java & XML thoroughly up to date. Except
for a concise introduction to XML basics, the book focuses entirely on using XML from Java
applications. It's a worthy companion for Java developers working with XML or involved in
messaging, web services, or the new peer-to-peer movement

Java & XML, 2nd Edition 2
Java & XML, 2nd Edition 3
Table of Contents

Preface ___________________________________________________________7
Organization ________________________________________________ 7
Who Should Read This Book? ___________________________________9
Software and Versions ________________________________________ 9

4
5.1 The Document Object Model _______________________________ 90
5.2 Serialization ____________________________________________ 93
5.3 Mutability______________________________________________ 104
5.4 Gotcha! _______________________________________________ 104
5.5 What's Next?___________________________________________ 106
Chapter 6. Advanced DOM ____________________________________107
6.1 Changes ______________________________________________ 107
6.2 Namespaces___________________________________________ 116
Overloaded? ___________________________________________________117
6.3 DOM Level 2 Modules ___________________________________ 119
6.4 DOM Level 3___________________________________________ 131
6.5 Gotcha! _______________________________________________ 134
6.6 What's Next?___________________________________________ 135
Chapter 7. JDOM _______________________________________________137
7.1 The Basics ____________________________________________ 137
7.2 PropsToXML___________________________________________ 140
7.3 XMLProperties _________________________________________ 149
7.4 Is JDOM a Standard? ____________________________________ 159
7.5 Gotcha! _______________________________________________ 159
7.6 What's Next?___________________________________________ 161
Chapter 8. Advanced JDOM ___________________________________162
8.1 Helpful JDOM Internals___________________________________ 162
8.2 JDOM and Factories_____________________________________ 166
8.3 Wrappers and Decorators_________________________________ 170
8.4 Gotcha! _______________________________________________ 181
8.5 What's Next?___________________________________________ 183
Chapter 9. JAXP________________________________________________184
9.1 API or Abstraction_______________________________________ 184
9.2 JAXP 1.0______________________________________________ 185

13.4 Putting It All Together ___________________________________ 291
13.5 What's Next?__________________________________________ 307
Chapter 14. Content Syndication _____________________________308
14.1 The Foobar Public Library _______________________________ 308
14.2 mytechbooks.com______________________________________ 316
14.3 Push Versus Pull ______________________________________ 324
14.4 What's Next?__________________________________________ 332
Chapter 15. Data Binding _____________________________________333
15.1 First Principles ________________________________________ 334
15.2 Castor _______________________________________________ 338
15.3 Zeus ________________________________________________ 345
15.4 JAXB________________________________________________ 352
15.5 What's Next?__________________________________________ 358
Chapter 16. Looking Forward _________________________________360
16.1 XLink________________________________________________ 360
Java & XML, 2nd Edition 6
16.2 XPointer _____________________________________________ 361
16.3 XML Schema Bindings __________________________________ 364
16.4 And the Rest. . . _______________________________________ 365
16.5 What's Next?__________________________________________ 366
Appendix A. API Reference ___________________________________367
A.1 SAX 2.0 ______________________________________________ 367
A.2 DOM Level 2 __________________________________________ 377
A.3 JAXP 1.1 _____________________________________________ 384
A.4 JDOM 1.0 (Beta 7) ______________________________________ 389
Appendix B. SAX 2.0 Features and Properties _______________399
B.1 Core Features _________________________________________ 399

This book is structured in a very particular way: the first half of the book, Chapter 1
through Chapter 9
, focuses on grounding you in XML and the core Java APIs for handling
XML. For each of the three XML manipulation APIs (SAX, DOM, and JDOM), I'll give you a
chapter on the basics, and then a chapter on more advanced concepts. Chapter 10
is a
transition chapter, starting to move up the XML "stack" a bit. It covers JAXP, which is an
abstraction layer over SAX and DOM. The remainder of the book, Chapter 11 through
Chapter 15
, focuses on specific XML topics that continually are brought up at conferences
and tutorials I am involved with, and seek to get you neck-deep in using XML in your
applications. These topics include new chapters on SOAP, data binding, and an updated
look at business-to-business. Finally, there are two appendixes to wrap up the book. The
summary of this content is as follows:
Chapter 1

We will look at what all the hype is about, examine the XML alphabet soup, and spend time
discussing why XML is so important to the present and future of enterprise development.
Chapter 2

This is a crash course in XML basics, from XML 1.0 to DTDs and XML Schema to XSLT to
Namespaces. For readers of the first edition, this is the sum total (and then some) of all the
various chapters on working with XML.
Chapter 3
The Simple API for XML (SAX), our first Java API for handling XML, is introduced and
covered in this chapter. The parsing lifecycle is detailed, and the events that can be caught
by SAX and used by developers are demonstrated.
Chapter 4

Java & XML, 2nd Edition


This chapter looks at what a web publishing framework is, why it matters to you, and how to
choose a good one. We then cover the Apache Cocoon framework, taking an in-depth look
at its feature set and how it can be used to serve highly dynamic content over the Web.
Chapter 11
In this chapter, we'll cover Remote Procedure Calls (RPC), its relevance in distributed
computing as compared to RMI, and how XML makes RPC a viable solution for some
problems. We'll then look at using XML-RPC Java libraries and building XML-RPC clients
and servers.
Chapter 12

In this chapter, we'll look at using configuration data in an XML format, and see why that
format is so important to cross-platform applications, particularly as it relates to distributed
systems and web services.
Chapter 13
Continuing the discussions of SOAP and web services, this chapter details two important
technologies, UDDI and WSDL.
Chapter 14

Continuing in the vein of business-to-business applications, this chapter introduces another
way for businesses to interoperate, using content syndication. You'll learn about Rich Site
Summary, building information channels, and even a little Perl.
Chapter 15

Moving up the XML "stack," this chapter covers one of the higher-level Java and XML APIs,
XML data binding. You'll learn what data binding is, how it can make working with XML a
Java & XML, 2nd Edition 9

concepts (such as Java servlets and Enterprise JavaBeans). If you have never coded Java
before or are just getting started with the language, you may want to read Learning Java by
Pat Niemeyer and Jonathan Knudsen (O'Reilly) before starting this book. I do not assume
that you know anything about XML, and start with the basics. However, I do assume that
you are willing to work hard and learn quickly; for this reason we move rapidly through the
basics so that the bulk of the book can deal with advanced concepts. Material is not
repeated unless appropriate, so you may need to reread previous sections or flip back and
forth as we use previously covered concepts in later chapters. If you know some Java, want
to learn XML, and are prepared to enter some example code into your favourite editor, you
should be able to get through this book without any real problem.

Software and Versions
This book covers XML 1.0 and the various XML vocabularies in their latest form as of July
of 2001. Because various XML specifications covered are not final, there may be minor
inconsistencies between printed publications of this book and the current version of the
specification in question.
All the Java code used is based on the Java 1.2 platform. If you're not using Java 1.2 by
now, start to work to get there; the collections classes alone are worth it. The Apache
Xerces parser, Apache Xalan processor, Apache SOAP library, and Apache FOP libraries
were the latest stable versions available as of June of 2000, and the Apache Cocoon web
publishing framework used is Version 1.8.2. The XML-RPC Java libraries used are Version
Java & XML, 2nd Edition 10
1.0 beta 4. All software used is freely available and can be obtained online from
, , and .
The source for the examples in this book is contained completely within the book itself. Both
source and binary forms of all examples (including extensive Javadoc not necessarily
included in the text) are available online from and

First, let me simply say that XML matters. I know that sounds like the beginning of a self-
help seminar, but it's worth starting with. There are still many developers, managers, and
executives who are afraid of XML. They are afraid of the perception that XML is "cutting-
edge," and of XML's high rate of change. (This is a second edition, a year later, right? Has
that much changed?) They are afraid of the cost of hiring folks like you and me to work in
XML. Most of all, they are afraid of adding yet another piece to their application puzzles.
To try and assuage these fears, let me quickly run down the major reasons that you should
start working with XML, today. First, XML is portable. Second, it allows an unprecedented
degree of interoperability. And finally, XML matters. . . because it doesn't matter! If that's
completely confusing, read on and all will soon make sense.
1.1.1 Portability
XML is portable. If you've been around Java long, or have ever wandered through Moscone
Center at JavaOne, you've heard the mantra of Java: "portable code." Compile Java code,
drop those .class or .jar files onto any operating system, and the code runs. All you need is
a Java Runtime Environment (JRE) or Java Virtual Machine (JVM), and you're set. This has
continually been one of Java's biggest draws, because developers can work on Linux or
Windows workstations, develop and test code, and then deploy on Sparcs, E4000s, HP-UX,
or anything else you could imagine.
As a result, XML is worth more than a passing look. Because XML is simply text, it can
obviously be moved between various platforms. Even more importantly, XML must conform
to a specification defined by the World Wide Web Consortium (W3C) at

. This means that XML is a standard. When you send XML, it
conforms to this standard; when some other application receives it, the XML still conforms
to that standard. The receiving application can count on that. This is essentially what Java
provides: any JVM knows what to expect, and as long as code conforms to those
expectations, it will run. By using XML, you get portable data. In fact, recently you may have
heard the phrase "portable code, portable data" in reference to the combination of Java and
XML. It's a good saying, because it turns out (as not all marketing-type slogans do) to be
true.

the ebXML project at
and see what's going on. Here, businesses
are working together to develop standards built upon XML that allow global electronic
commerce. The telecommunications industry has undertaken similar efforts. Soon, vertical
markets across the world will have agreed upon standards for exchanging data, all built on
XML.
[1]
A vertical standard, or vertical market, refers to a standard or market targeting a specific business.
Instead of moving horizontally (where common functionality is preferred), the focus is on moving
vertically, providing functionality for a specific audience, like shoe manufacturers or guitar makers.
1.1.3 It Doesn't Matter
When all is said and done, XML matters because it doesn't matter. I said this earlier, and I
want to say it again, because it's at the root of why XML is so important. Proprietary
solutions for data, formats that are binary and must be decoded in certain ways, and other
data solutions all matter in the final analysis. They involve communication with other
companies, extensive documentation, coding efforts, and reinvention of tools for
transmission. XML is so attractive because you don't need any special expertise and can
spend your time doing other things. In Chapter 2
, I describe in 25 or so pages most of
what you'll ever need to author XML. It doesn't require documentation, because that
documentation is already written. You don't need special encoders or decoders; there are
APIs and parsers already written that handle all of this for you. And you don't have to incur
risk; XML is now a proven technology, with millions of developers working, fixing, and
extending it every day.
XML is important because it becomes such a reliable, unimportant part of your application.
Write your constraints, encode your data in XML, and forget about it. Then go on to the
important things; the complex business logic and presentation that involves weeks and
months of thought and hard work. Meanwhile, XML will happily chug along representing
your data with nary a whimper or whine (OK, I'm getting a bit dramatic, but you get the
idea).

quite a bit of time on these APIs, as they are the basis for everything else you'll do in XML.
I've also devoted a chapter to JAXP, Sun's Java API for XML Processing, which provides a
thin abstraction layer over SAX and DOM.
1.2.2 High-Level APIs
High-level APIs are the next step up the ladder. Instead of offering direct access to a
document, they rely on low-level APIs to do that work for them. Additionally, these APIs
present the document in a different form, either more user-friendly, or modeled in a certain
way, or in some form other than a basic XML document structure. While these APIs are
often easier to use and quicker to develop with, you may pay an additional processing cost
while your data is converted to a different format. Also, you'll need to spend some time
learning the API, most likely in addition to some lower-level APIs.
In this book, the main example of a high-level API is XML data binding. Data binding allows
for taking an XML document and providing that document as a Java object. Not a tree-
based object, mind you, but a custom Java object. If you had elements named "person" and
"firstName", you would get an object with methods like getPerson( ) and
setFirstName( ). Obviously, this is a simple way to quickly get going with XML; hardly
any in-depth knowledge is required! However, you can't easily change the structure of the
document (like making that "person" element become an "employee" element), so data
binding is suited for only certain applications. You can find out all about data binding in
Chapter 14
.
1.2.3 XML-Based Applications
In addition to APIs built specifically for working with a document or its content, there are a
number of applications built on XML. These applications use XML directly or indirectly, but
are focused on a specific business process, like displaying stylized web content or
communicating between applications. These are all examples of XML-based applications
that use XML as a part of their core behavior. Some require extensive XML knowledge,
some require none; but all belong in discussions about Java and XML. I've picked out the
most popular and useful to discuss here.
First, I'll cover web publishing frameworks, which are used to take XML and format them as

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 (
), 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
Java & XML, 2nd Edition 15
parsers are validating, which means they offer the option to validate your XML with a DTD

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
.
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
and
/>, respectively. I'll also take some time to look at
Zeus, available at
. All of these packages contain any needed
dependencies within the downloaded bundles.
1.3.4 Application Software
Java & XML, 2nd Edition 16
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.

this book be read with a copy of Elliotte Harold and Scott Means' excellent book XML in a
Nutshell (O'Reilly) open. That will give you all the information you need on XML concepts,
and then I can focus on Java ones.
Finally, I'm big on examples. I'm going to load the rest of the chapters as full of them as
possible. I'd rather give you too much information than barely engage you. To get started
along those lines, I'll introduce several XML and related documents in this chapter to
illustrate the concepts in this primer. You might want to take the time to either type these
into your editor or download them from the book's web site
(
), as they will be used in this chapter and throughout the
rest of the book. It will save you time later on.
2.1 The Basics
It all begins with the XML 1.0 Recommendation, which you can read in its entirety at
/>. Example 2-1 shows a simple XML document that
conforms to this specification. It's a portion of the XML table of contents for this book (I've
only included part of it because it's long!). The complete file is included with the samples for
the book, available online at /> and

. I'll use it to illustrate several important concepts.
Example 2-1. The contents.xml document
<?xml version="1.0"?>
<!DOCTYPE book SYSTEM "DTD/JavaXML.dtd">

<! Java and XML Contents >
<book xmlns="
xmlns:ora=""
>
<title ora:series="Java">Java and XML</title>

<! Chapter List >

<topic name="Gotcha!" />
<topic name="What&apos;s Next?" />
</chapter>
<chapter title="DOM" number="5">
<topic name="The Document Object Model" />
<topic name="Serialization" />
<topic name="Mutability" />
<topic name="Gotcha!" />
<topic name="What&apos;s Next?" />
</chapter>

<! And so on >

</contents>

<ora:copyright>&OReillyCopyright;</ora:copyright>
</book>
2.1.1 XML 1.0
A lot of this specification describes what is mostly intuitive. If you've done any HTML
authoring, or SGML, you're already familiar with the concept of elements (such as
contents and chapter in the example) and attributes (such as title and name). In
XML, there's little more than definition of how to use these items, and how a document must
be structured. XML spends more time defining tricky issues like whitespace than introducing
any concepts that you're not at least somewhat familiar with.
An XML document can be broken into two basic pieces: the header, which gives an XML
parser and XML applications information about how to handle the document; and the
content, which is the XML data itself. Although this is a fairly loose division, it helps us
differentiate the instructions to applications within an XML document from the XML content
itself, and is an important distinction to understand. The header is simply the XML
declaration, in this format:

pairs, which can really help readability. This is only a good practice, though, and not
required, so don't depend on it.
Other than that, the bulk of your XML document should be content; in other words,
elements, attributes, and data that you have put into it.
2.1.1.1 The root element
The root element is the highest-level element in the XML document, and must be the first
opening tag and the last closing tag within the document. It provides a reference point that
enables an XML parser or XML-aware application to recognize a beginning and end to an
XML document. In our example, the root element is book:
<book xmlns="
xmlns:ora=""
>
<! Document content >
</book>
This tag and its matching closing tag surround all other data content within the XML
document. XML specifies that there may be only one root element in a document. In other
words, the root element must enclose all other elements within the document. Aside from
this requirement, a root element does not differ from any other XML element. It's important
to understand this, because XML documents can reference and include other XML
documents. In these cases, the root element of the referenced document becomes an
enclosed element in the referring document, and must be handled normally by an XML
parser. Defining root elements as standard XML elements without special properties or
behavior allows document inclusion to work seamlessly.
2.1.1.2 Elements
So far I have glossed over defining an actual element. Let's take an in-depth look at
elements, which are represented by arbitrary names and must be enclosed in angle
Java & XML, 2nd Edition 20

tag, there can be any number of additional elements or textual data. However, you cannot
mix the order of nested tags: the first opened element must always be the last closed
element. If any of the rules for XML syntax are not followed in an XML document, the
document is not well-formed. A well-formed document is one in which all XML syntax rules
are followed, and all elements and attributes are correctly positioned. However, a well-
formed document is not necessarily valid, which means that it follows the constraints set
upon a document by its DTD or schema. There is a significant difference between a well-
formed document and a valid one; the rules I discuss in this section ensure that your
document is well-formed, while the rules discussed in the constraints section allow your
document to be valid.
As an example of a document that is not well-formed, consider this XML fragment:
<tag1>
<tag2>
</tag1>
</tag2>
The order of nesting of tags is incorrect, as the opened <tag2> is not followed by a closing
</tag2> within the surrounding tag1 element. However, if these syntax errors are
corrected, there is still no guarantee that the document will be valid.
While this example of a document that is not well-formed may seem trivial, remember that
this would be acceptable HTML, and commonly occurs in large tables within an HTML
document. In other words, HTML and many other markup languages do not require well-
formed XML documents. XML's strict adherence to ordering and nesting rules allows data to
Java & XML, 2nd Edition 21
be parsed and handled much more quickly than when using markup languages without
these constraints.
The last rule I'll look at is the case of empty elements. I already said that XML tags must
always be paired; an opening tag and a closing tag constitute a complete XML element.

start and end tag into a single tag.
2.1.1.3 Attributes
In addition to text contained within an element's tags, an element can also have attributes.
Attributes are included with their respective values within the element's opening declaration
(which can also be its closing declaration!). For example, in the chapter tag, the title of the
chapter was part of what was noted in an attribute:
<chapter title="Advanced SAX" number="4">
<topic name="Properties and Features" />
<topic name="More Handlers" />
<topic name="Filters and Writers" />
<topic name="Even More Handlers" />
<topic name="Gotcha!" />
<topic name="What&apos;s Next?" />
</chapter>
In this example, title is the attribute name; the value is the title of the chapter, "Advanced
SAX." Attribute names must follow the same rules as XML element names, and attribute
values must be within quotation marks. Although both single and double quotes are
allowed, double quotes are a widely used standard and result in XML documents that model
Java programming practices. Additionally, single and double quotation marks may be used
in attribute values; surrounding the value in double quotes allows single quotes to be used
as part of the value, and surrounding the value in single quotes allows double quotes to be
used as part of the value. This is not good practice, though, as XML parsers and processors
often uniformly convert the quotes around an attribute's value to all double (or all single)
quotes, possibly introducing unexpected results.
In addition to learning how to use attributes, there is an issue of when to use attributes.
Because XML allows such a variety of data formatting, it is rare that an attribute cannot be
represented by an element, or that an element could not easily be converted to an attribute.
Although there's no specification or widely accepted standard for determining when to use
an attribute and when to use an element, there is a good rule of thumb: use elements for
multiple-valued data and attributes for single-valued data. If data can have multiple values,

data values. For example, a common way to represent a path to an installation directory is
<path-to-Cocoon>. Here, the user would replace the text with the appropriate choice of
installation directory. In this example, the chapter that discusses web applications must give
some details on installing and using Apache Cocoon, and might need to represent this data
within an element:
<topic>
<heading>Installing Cocoon</heading>
<content>
Locate the Cocoon.properties file in the <path-to-Cocoon>/bin
directory.
</content>
</topic>
The problem is that XML parsers attempt to handle this data as an XML tag, and then
generate an error because there is no closing tag. This is a common problem, as any use of
angle brackets results in this behavior. Entity references provide a way to overcome this
problem. An entity reference is a special data type in XML used to refer to another piece of
data. The entity reference consists of a unique name, preceded by an ampersand and
followed by a semicolon: &[entity name];. When an XML parser sees an entity
reference, the specified substitution value is inserted and no processing of that value
occurs. XML defines five entities to address the problem discussed in the example: &lt;
for the less-than bracket, &gt; for the greater-than bracket, &amp; for the ampersand sign
itself, &quot; for a double quotation mark, and &apos; for a single quotation mark or
apostrophe. Using these special references, you can accurately represent the installation
directory reference as:
<topic>
<heading>Installing Cocoon</heading>
<content>
Locate the Cocoon.properties file in the
&lt;path-to-Cocoon&gt;/bin directory.
</content>

</unparsed-data>
In this example, the information within the CDATA section does not have to use entity
references or other mechanisms to alert the parser that reserved characters are being
used; instead, the XML parser passes them unchanged to the wrapping program or
application.
At this point, you have seen the major components of XML documents. Although each has
only been briefly described, this should give you enough information to recognize XML tags
when you see them and know their general purpose. With existing resources like O'Reilly's
XML in a Nutshell by your side, you are ready to look at some of the more advanced XML
specifications.
2.1.2 Namespaces
Although I will not delve too deeply into XML namespaces here, note the use of a
namespace in the root element of Example 2-1
. An XML namespace is a means of
associating one or more elements in an XML document with a particular URI. This
effectively means that the element is identified by both its name and its namespace URI. In
this XML example, it may be necessary later to include portions of other O'Reilly books.
Because each of these books may also have Chapter, Heading, or Topic elements, the
document must be designed and constructed in a way to avoid namespace collision
problems with other documents. The XML namespaces specification nicely solves this
problem. Because the XML document represents a specific book, and no other XML
document should represent the same book, using a namespace associated with a URI like
/> can create a unique namespace. The namespace
specification requires that a unique URI be associated with a prefix to distinguish the
elements in the namespace from elements in other namespaces. A URL is recommended,
and supplied here:
<book xmlns="
xmlns:ora=""
Java & XML, 2nd Edition


</name>
<email></email>
</person>
</addressBook>
Several things happen here, and it is important to understand them all. First, the XML
Schema instance namespace is defined and associated with a URL. This namespace,
abbreviated xsi, is used for specifying information in XML documents about a schema,
exactly as is being done here. Thus, the first line makes the elements in the XML Schema
instance available to the document for use. The next line defines the namespace for the
XML document itself. Because the document does not use an explicit namespace, like the
one associated with /> in earlier examples, the default
namespace is declared. This means that all elements without an explicit namespace and
associated prefix (all of them, in this example) will be associated with this default
namespace.
With both the document and XML Schema instance namespaces defined like this, we can
then actually do what we want, which is to associate a schema with this document. The
schemaLocation attribute, which belongs to the XML Schema instance namespace, is
used to accomplish this. I've prefaced this attribute with its namespace (xsi), which was
just defined. The argument to this attribute is actually two URIs: the first specifies the
namespace associated with a schema, and the second the URI of the schema to refer to. In
the example, this results in the first URI being the default namespace just declared, and the
second a file on the local filesystem called mySchema.xsd. Like any other XML attribute,
the entire pair is enclosed in a single set of quotation marks. And as simple as that, you
have referenced a schema in your XML document!
Seriously, it's not simple, and is to date one of the most misunderstood portions of using
namespaces and XML Schema. I look more at the mechanics used here as we continue.