Getting into XML with the Microsoft Office System

 

Bill Coan
Wordsite

February 2004

Applies to:
    Microsoft® Office Word 2003
    Microsoft Office Excel 2003
    Microsoft Office Access 2003
    Microsoft Office InfoPath™ 2003
    Microsoft Office System

Summary: With great wit and enthusiasm, Bill Coan provides a beginner's walk through of XML and reviews the benefits of XML across all XML-enabled Microsoft Office 2003 programs. (28 printed pages)

Important The information set out in this topic is presented exclusively for the benefit and use of individuals and organizations outside the United States and its territories or whose products were distributed by Microsoft before January 2010, when Microsoft removed an implementation of particular functionality related to custom XML from Word. This information may not be read or used by individuals or organizations in the United States or its territories whose products were licensed by Microsoft after January 10, 2010; those products will not behave the same as products licensed before that date or licenses for use outside the United States.

Contents

Introduction
Why the Microsoft Office System Isn't Your Father's Office
The Impact of XML
Sneaking a Peek inside an XML Data File
Schemas and Transforms: The Key to the XML Highway
Sneaking a Peek Inside a Schema File
Sneaking a Peek Inside a Transform File
Putting the Pieces Together with Office Professional Edition 2003
Things You Can Do with XML Data in an Office 2003 Application
Experiencing the Power of XML for Yourself

Introduction

The XML support in the release of the Microsoft® Office System is the most dramatic change in Microsoft Office since Word and Excel were first bundled nearly twenty years ago. Up until now, your favorite Office programs helped you input data, manipulate data, and format data. Now those same programs have the capability to understand the meaning of your data, help you work with it more effectively, and present it with greater flexibility than ever before. For example, now you can:

• Establish rules for each type of document. If a document violates a rule, you can tell Office not to print or save the document until the violation is corrected.
• Instantly transform a document to suit multiple purposes at the click of a button.
• Save documents as XML data files that can be opened and edited with any industry standard XML editor.

Why the Microsoft Office System Isn't Your Father's Office

Microsoft Office was always littered with what the cognoscenti like to refer to as "undocumented" features but the most important new feature of Microsoft Office Professional Edition 2003 isn't so much undocumented as it is unheralded. You might say it's hiding in plain sight.

I'm talking about XML support across the most popular Office 2003 programs, Word, Excel, and Access, and even the new Microsoft Office InfoPath™ program.

No one at Microsoft denies that Office Professional Edition 2003 supports XML but I don't see the company going out of its way to promote or explain this incredibly useful new functionality. Instead, the company is touting changes in the interface for Microsoft Office Outlook® 2003 and talking up Microsoft Office OneNote® and InfoPath and the brave new world of collaborative workspaces.

I'm all in favor of Outlook's new interface. I'm totally convinced and completely accepting of the fact that OneNote and InfoPath and collaborative workspaces are the new new thing. To me, though, nothing about the Microsoft Office System is as exciting or as immediately useful as XML support. In fact, in my opinion XML support is the most dramatic change in Office since Word and Excel first got bundled together for marketing purposes nearly twenty years ago. In this article, I discuss the benefits of XML across all XML-enabled Microsoft Office 2003 programs, but my examples focus on using Word.

**Important   **The Microsoft Office Small Business Edition 2003, Microsoft Office Standard Edition 2003, and the Microsoft Office Student and Teacher Edition 2003 do not offer the most powerful aspects of XML in Office. In these editions, you can save your documents in a native XML file format that you can manipulate and search by using any industry standard XML editor, and that's great, but that's all. The real power of XML isn't available to you unless you purchase Office Professional Edition 2003.

The Impact of XML

XML has been around since 1998 but most of us didn't care because it was a fairly arcane technology aimed at specialists and geared toward database compatibility. Since then, XML has grown up and learned a thing or two about validating and formatting all types of data and presenting a single body of data in different ways to different users.

Oops, was I starting to bore you with all that talk about data? Don't go to sleep on me just yet.

Sure, XML is all about data and that's nice for database designers and database administrators and database users. But XML isn't just about data-data. Starting with Office Professional Edition 2003, it's about Word documents and Excel spreadsheets and data from other Office programs. In other words, it's about you and the kind of data you work with on a day-in, day-out basis.

With the Microsoft Office System you can create an XML document in Word and at the click of a button instantly transform it to suit multiple purposes. For example, you can create a training guide and at the click of a button transform it into a teacher guide or a student guide or a self-quiz. (Stay tuned to learn how. It's easier than you think.)

Another benefit of XML is that it allows you to establish rules for each type of document. For example, you can specify that a fax number must appear at the top of each fax cover sheet and must always include a valid area code. If a document violates this or any other rule, you can tell Office to refuse to print or save the document until the violation is corrected.

Best of all, since the Microsoft Office System produces files that you can open and edit with any XML editor, you can share your work with other users in new and exciting ways.

Perhaps the best way to sum up the impact of all this is to state the following: Up until Office Professional Edition 2003, your favorite Office programs helped you input data, manipulate data, and format data. Now those same programs are capable of understanding what your data means and helping you work with it more effectively and allowing you to present it with greater flexibility than ever before.

Does this mean that every user of Office Professional Edition 2003 needs to become an XML geek? Notonyerlife. But it does mean that every user owes it to himself or herself to experience the incredible power that derives from working with XML data in Office.

The rest of this article provides some additional background and a simple set of procedures that any user of Office Professional Edition 2003 can carry out in minutes in order to experience personally and directly the amazing power of XML data in Office.

Note   If you lack the time to carry out even these simple procedures, you can download a sample file from the sites listed at the end of this article. Don't stop reading, though. The sample file will dazzle you but you won't have any idea how it was put together unless you take a few minutes to read through the discussion that follows.

A word before we begin: The fundamentals of XML are extremely simple to understand, so that's what you'll find here. What I'm about to explain is so easy to understand that even your boss should be able to follow along. In fact, I'll go out on a limb and say that even your boss's boss should be able to follow along.

Remember, the point of what follows is not to turn you into an XML geek but rather to show you how powerful and easy-to-use XML technology has become with the advent of Office Professional Edition 2003. If this leaves you hungry for more information, so much the better. In that case, you'll appreciate the references I've provided at the end of the article, which lead you to more information about the technical nitty-gritty of XML.

Sneaking a Peek Inside an XML Data File

XML stands for eXtensible Markup Language. This tells you that XML belongs to the same family of languages as HTML (HyperText Markup Language) and SGML (Standard Generalized Markup Language), which many users have tried to learn without success.

Fortunately, XML is dramatically easier to learn and use than other markup languages. I've identified six key concepts that are worth learning even if you're not the type who normally looks under the hood. It should take you a few minutes to grasp these concepts but only a few minutes and not because I'm such a great communicator but because the concepts are very easy to grasp.

XML 101: Data is Divided into Elements

Consider the following example of XML "code."

<ARGUMENT>
  <FACT>One way to learn a language is to immerse yourself in it.</FACT>
  <FACT>If you're reading this, you're immersed in XML.</FACT>
  <CONCLUSION>One way to learn XML is to read this.</CONCLUSION>
</ARGUMENT>
<ARGUMENT>
  <FACT>I made up these tags to suit my purpose.</FACT>
  <FACT>My purpose was to help you read XML.</FACT>
  <CONCLUSION>I made up these tags to help you.</CONCLUSION>
</ARGUMENT>

Before I even bother to explain what you just read, I want to pause and give you a chance to celebrate the progress you've already made toward mastery of XML.

Did you notice any of the following?

1. That each element of data started with a <TAG> of some kind and ended with a matching </TAG>?
2. That the tags have friendly, meaningful names that describe each element of data?
3. That some elements were nested inside other elements?

If you noticed all that, then you're ready to graduate from XML 101. If you didn't notice all that, then take a minute to read through the code example again before proceeding.

Did you also notice that I snuck into this discussion the technical term, "element"?

XML data is divided into elements so that you can tag each element separately from all the other elements. That way, you can make the meaning of each element clear and nest elements inside each other according to their natural relationships. This approach makes data much easier to manage than if it were stored as one large, undifferentiated, unlabeled mass.

In the previous example, there's nothing special about the element names except that they suited my purpose (or so it seemed to me). I used ARGUMENT, FACT, and CONCLUSION but I could just as easily have used SYLLOGISM, PREMISE, and CONCLUSION or almost any other names that reflect the type of data contained in each element.

A side note, there are a couple of rules you have to follow when naming elements, regarding placement of alpha and numeric characters and the use of punctuation and space characters. Also, an element of data can contain almost any text but some characters have to be represented using special techniques. These details are fully explained in the references listed at the end of this article.

XML 102: Getting at the Root of the Matter

You can store as many elements of data in an XML file as desired but the file can have only one "root" element. The root element is the first element in the file. All of the other elements must be nested inside the root. In the XML example below, the <EXAMPLES_OF_LOGIC> element serves as the root element. All of the other elements are nested inside that element.

<EXAMPLES_OF_LOGIC>
  <ARGUMENT>
    <FACT>One way to learn a language is to immerse yourself in it.</FACT>
    <FACT>If you're reading this, you're immersed in XML.</FACT>
    <CONCLUSION>One way to learn XML is to read this.</CONCLUSION>
  </ARGUMENT>
  <ARGUMENT>
    <FACT>I made up these tags to suit my purpose.</FACT>
    <FACT>My purpose was to help you read XML.</FACT>
    <CONCLUSION>I made up these tags to help you.</CONCLUSION>
  </ARGUMENT>
</EXAMPLES_OF_LOGIC>

If you promise to remember that an XML file can have only one root element and that all of the other elements in the file must be nested inside the root element, then you're ready to graduate from XML 102.

XML 103: Elements are like Pockets, Sometimes They're Empty.

Some XML elements contain no data. The following example contains three ARGUMENT elements. The middle one (i.e., the second one) contains no data.

<EXAMPLES_OF_LOGIC>
  <ARGUMENT>
    <FACT>One way to learn a language is to immerse yourself in it.</FACT>
    <FACT>If you're reading this, you're immersed in XML.</FACT>
    <CONCLUSION>One way to learn XML is to read this.</CONCLUSION>
  </ARGUMENT>
  <ARGUMENT/>
  <ARGUMENT>
    <FACT>I made up these tags to suit my purpose.</FACT>
    <FACT>My purpose was to help you read XML.</FACT>
    <CONCLUSION>I made up these tags to help you.</CONCLUSION>
  </ARGUMENT>
</EXAMPLES_OF_LOGIC>

Did you find the empty element? Here's another look at it:

<ARGUMENT/>

In the following code example, you'll see an ARGUMENT element that contains two FACT elements and a CONCLUSION element. The FACT elements are empty. So is the CONCLUSION element. The ARGUMENT element isn't empty, however, because it contains the FACT elements and the CONCLUSION element.

<ARGUMENT>
  <FACT/>
  <FACT/>
  <CONCLUSION/>
</ARGUMENT>

Did you notice the following?

• That an empty element needs only one <TAG/>?
• That the tag for an empty element includes a slash immediately before the closing angle bracket?

If you noticed both of these things, then you're ready to graduate from XML 103. If you missed either of them, then take a minute to read through the code examples again before proceeding.

XML 104: Attributes are Just Properties that Have Moved Uptown

Sometimes naming an element isn't sufficient to convey everything there is to know about the element. For that reason, XML allows you to assign other properties to an element besides a name. The other properties are called "attributes." Don't let the terminology throw you. Attributes are just properties by another name. Many elements have no attributes. Some have just one attribute (besides a name). Some have multiple attributes.

In the following example, each ARGUMENT element is assigned an attribute that tells whether the element is convincing. The "convincing" attribute of the first ARGUMENT element is set to "Yes" but the attributes of the other two ARGUMENT elements are set to "No." See if you can figure out why.

<EXAMPLES_OF_LOGIC>
  <ARGUMENT convincing="Yes">
    <FACT>All virtues are laudable.</FACT>
    <FACT>Kindness is a virtue.</FACT>
    <CONCLUSION>Kindness is laudable.</CONCLUSION>
  </ARGUMENT>
  <ARGUMENT convincing="No"/>
  <ARGUMENT convincing="No">
    <FACT>Socrates was a man.</FACT>
    <FACT>All  men are created equal.</FACT>
    <CONCLUSION>Socrates was Plato.</CONCLUSION>
  </ARGUMENT>
</EXAMPLES_OF_LOGIC>

Note   I used uppercase letters for the element names and lower case letters for the attribute names. I didn't have to do that. I did it to make it easier to distinguish the names from the attributes. There are a couple of rules to follow when naming attributes, explained in the references listed at the end of this article.

Did you notice the following?

• That attributes are placed inside an element's start tag?
• That an empty element can have attributes just like any other element?

If you noticed both of these things, then you're ready to graduate from XML 104. If you missed either of them, then take a minute to read through the code examples again before proceeding.

XML 105: My Baloney Has a First Name and So Do All My XML Elements

The great thing about XML is that you get to name your own data elements. The bad thing about XML is that everyone else gets to name their own data elements, too, which means that naming conflicts can occur.

Naming conflicts aren't unique to XML. They can occur in all sorts of situations where people are allowed to name things. They can occur even with something as simple as file names.

For example, I have a Web site and one of the files at my Web site is called index.html. The New York Times has a Web site and one of the files there is called index.html, too.

Fortunately, there's no danger of the two files being confused, because they exist in different domains. The domain name for my Web site is http://www.wordsite.com. The domain name for the New York Times Web site is http://www.nytimes.com.

When you include the domain name as part of a file name, you eliminate the possibility of a naming conflict. For example, the full name of the index.html file at my Web site is http://www.wordsite.com/index.html and the full name of the index.html file at the New York Times Web site is http://www.nytimes.com/index.html. Since these names are unique, no one will ever confuse my file and the New York Times file.

What's needed for XML is something like a domain name, to prevent like-named elements from being confused. XML uses namespaces for this purpose. Namespaces are a lot like domain names. They act like a first name for each element. When you include a unique namespace name as part of an element name, you eliminate the possibility of a naming conflict.

For example, I may have an XML element called <TITLE> and the New York Times may have an XML element called <TITLE> but a naming conflict can be avoided if the full name of my element is: {http://www.wordsite.com/namespace1}<TITLE> and the full name of the New York Times element is: {http://www.nytimes.com/namespace1}<TITLE>.

By the way, there's no rule saying that a namespace name has to look like a domain name, but why argue with success? I know that my domain name is unique and I know that the New York Times domain name is unique, so why not use the domain names as part of the namespace names? That way, I can be sure that the names are unique. (This idea isn't new with me. Domain names are widely used as namespace names precisely because they are unique.)

In actual practice, namespaces are never explicitly listed in full next to each data element. Instead, they are typically listed near the top of the XML file. There are two common ways to do this.

The simplest way to associate elements with a particular namespace is to assign a namespace to the root element of the XML file, using an attribute called xmlns, which stands for XML namespace. The following example shows how this is done:

<EXAMPLES_OF_LOGIC xmlns="http://www.wordsite.com/namespace1">
  <ARGUMENT convincing="Yes">
    <FACT>All virtues are laudable.</FACT>
    <FACT>Kindness is a virtue.</FACT>
    <CONCLUSION>Kindness is laudable.</CONCLUSION>
  </ARGUMENT>
  <ARGUMENT convincing="No"/>
  <ARGUMENT convincing="No">
    <FACT>Socrates was a man.</FACT>
    <FACT>All  men are created equal.</FACT>
    <CONCLUSION>Socrates was Plato.</CONCLUSION>
  </ARGUMENT>
</EXAMPLES_OF_LOGIC>

In the above example, the namespace assigned to the root element is considered to be the default namespace for all of the elements nested inside the root element. That is to say, the root element and all of the elements nested inside it are considered to be in the default namespace. For example, you can think of the full name of each "<FACT>" element as "{http://www.wordsite.com/namespace1}<FACT>."

XML files that use default namespaces are highly readable, because the tags aren't all weighted down with a reference to a namespace. For this reason, many XML practitioners prefer to use a default namespace whenever possible and practical.

Unfortunately, using a default namespace isn't always possible or practical. For example, in a long file it can be more practical to include a reference to a namespace for each element, so that a human reader of the file doesn't have to refer back to the beginning of the file to find out what namespace is involved. Also, if a file happens to contain elements from two different namespaces, the only way to indicate which namespace an element belongs to is to include a reference to the namespace within each element tag.

The following code example shows how this is done. In this example, the namespace is assigned to a prefix and the prefix is used to "qualify" the various elements in the file. The constant repetition of the prefix makes the file harder to read for a human being, but it makes explicit which namespace each element belongs to.

<wsns1:EXAMPLES_OF_LOGIC xmlns:wsns1="http://www.wordsite.com/namespace1">
  <wsns1:ARGUMENT convincing="Yes">
    <wsns1:FACT>All virtues are laudable.</wsns1:FACT>
    <wsns1:FACT>Kindness is a virtue.</wsns1:FACT>
    <wsns1:CONCLUSION>Kindness is laudable.</wsns1:CONCLUSION>
  </wsns1:ARGUMENT>
  <wsns1:ARGUMENT convincing="No"/>
  <wsns1:ARGUMENT convincing="No">
    <wsns1:FACT>Socrates was a man.</wsns1:FACT>
    <wsns1:FACT>All  men are created equal.</wsns1:FACT>
    <wsns1:CONCLUSION>Socrates was Plato.</wsns1:CONCLUSION>
  </wsns1:ARGUMENT>
</wsns1:EXAMPLES_OF_LOGIC>

**Note   **In this discussion, we've seen that you can designate a default namespace for an entire file. We've also seen that you can incorporate an explicit reference to a namespace into the start tag for each element in a file. Both of these approaches are easy to grasp and easy to follow and that's why I presented them. If you snoop around some XML files, you'll find these approaches mixed and matched in surprising ways. For example, in many XML files with explicit references to one or more namespaces, elements nested inside other elements may not include a reference to a namespace. The reason for this is that many software programs assume that nested elements belong to the same namespace as their parent element.

The key thing to remember about namespaces in XML is that they act just like domains on the Internet. That is, they allow you to use any name you like within a namespace without having to worry about conflicts with names in other namespaces.

Since namespaces should be unique and since Internet URLs are an excellent example of uniqueness, namespaces are sometimes referred to as Universal Resource Identifiers. This emphasizes the similarity of namespaces to URLs but at the same time emphasizes the difference between namespaces and URLs. The key difference is this: An URL is a unique name that happens to point to an actual location. A URI is a unique name used for identification purposes only. For example, http://www.wordsite.com/index.html is an URL because it points to an actual location while http://www.wordsite.com/namespace1 is only a URI because it is a unique identifier but it doesn't point to a location.

Unfortunately, e-mail programs and many other programs, including Word, often convert URIs into hyperlinks, even though URIs don't point to a real location. This makes you think you can click on a URI and go somewhere but usually where you go is to a "Page Not Found" error page.

XML 106: I Do Declare (and I Do Comment)

Some of the statements in an XML data file have nothing to do with the elements of data in the file. For example, the very first statement in an XML file typically is the XML declaration, which looks as follows:

<?xml version="1.0"?>

An XML declaration is known as a processing instruction. Within the angle brackets of a processing instruction, the first and last characters must be question marks. XML files can contain many different types of processing instructions. Processing instructions are fully explained in the references listed at the end of this article.

**Note   **The XML standard doesn't require an XML file to start with an XML declaration or with any other processing instruction. If an XML declaration is included in a file, though, the standard says it must appear at the start of the file.

The primary purpose of an XML declaration is to declare that a file contains XML data that conforms to a particular version of the XML standard. The current XML standard is version 1.0. Without this information, the software that processes the file may misinterpret some of the data in the file.

An XML declaration may include attributes other than the version attribute shown above. For example, an encoding attribute may be included to designate the character encoding scheme used in the file. If a file is encoded using the utf-8 encoding scheme, the XML declaration statement would look as follows:

<?xml version="1.0" encoding="utf-8"?>

According to the XML standard, all software used with XML files is assumed to be capable of reading characters encoded in utf-8 and utf-16 encodings. Therefore, when a file is encoded in utf-8 or utf-16, the XML declaration needn't explicitly declare the encoding.

Since ASCII files are utf-8 compliant and the vast majority of Unicode files use utf-16 encoding, most of us can safely omit the encoding attribute from an XML declaration statement except in files where some other encoding scheme is used.

In addition to an XML declaration, many XML data files contain comments. Comments are easily recognizable.

<!-- Comments are always enclosed in angle brackets. -->
<!-- Comments always start with an exclamation point and two hyphens. -->
<!-- Comments always end with two hyphens. -->
<!-- Comments typically are ignored by software programs. -->

XML 501: The Graduate Course

Now that you've completed XML 101 through XML 106, you're ready for a graduate course in XML.

OK, I'm exaggerating a bit. If you're curious, there is plenty more to learn about XML. If you're like most users, though, the topics we've covered so far enable you to make highly effective use of XML data in Microsoft Office Professional Edition 2003.

**Note   **When an XML data file adheres to the rules that are discussed so far, the file is said to be well-formed. Well-formed files can be read successfully not only by humans but also by software. Files with "well-formedness" errors can cause an inconvenience for humans and far more serious problems for software. For more information about well-formed files, see the links at the end of this article.

The next example shows an XML data file that incorporates all the concepts that we've discussed so far, namely, elements (including root elements and empty elements), attributes, namespaces, declarations, and comments.

If you have any questions about what an element is or what a root element is or what an empty element is, you may want to back up and review those concepts.

If you have any questions about what an attribute is or what a namespace is or what a declaration is or what a comment is, you may want to back up and review those concepts.

If all of these concepts seem vaguely familiar to you (even if you're a little fuzzy on one or two of them), then you probably needn't back up and review anything. Instead, simply read through this XML data file and see if you aren't surprised by your own knowledge of XML:

<?xml version="1.0"?>
<!-- This XML data file includes extensive comments. --> 
<!-- Comments are ignored by software but can be helpful to human readers of a file. --> 
<!-- The following element is the root element for this file. --> 
<!--All other elements are nested inside the root element. -->
<TRAINING_MODULE xmlns="http://www.wordsite.com/NameSpace1">
<!-- The root element declares a default namespace for this file -->
<!-- NOTE   All elements and attributes in this file are assumed to be in the -->
<!-- default namespace unless explicitly assigned to some other namespace -->
<!-- The data in this file is divided into BUILDING_BLOCK elements. -->
<!-- There are six BUILDING_BLOCK elements, named as follows: -->
<!-- Element, Root Element, Empty Element, Attribute, Declaration, and Comment. -->
<!-- Each BUILDING_BLOCK element is further divided into four -->
<!-- sub-elements: NAME, DESCRIPTION, FUNCTION and NOTE -->
  <BUILDING_BLOCK>
    <NAME>Element</NAME>
    <DESCRIPTION>An element consists of a start tag, an end tag, and the data that lies between
 the start and end tags. For example, this sentence is part of a DESCRIPTION element.</DESCRIPTION>
    <FUNCTION>Stores data.</FUNCTION>
    <NOTE>Elements can be nested inside other elements. For example, this NOTE element is nested
 inside a BUILDING_BLOCK element. The preceding NAME element, DESCRIPTION element, and FUNCTION
 element are also nested inside the same BUILDING_BLOCK element.</NOTE>
  </BUILDING_BLOCK>
  <BUILDING_BLOCK>
    <NAME>Root Element</NAME>
    <DESCRIPTION>The first element in an XML file and the one that all other elements are
 nested inside of.</DESCRIPTION>
    <FUNCTION>Serves as a container for all the other elements and data in an XML file.</FUNCTION>
    <NOTE>An XML file can have only one root element.</NOTE>
  </BUILDING_BLOCK>
  <BUILDING_BLOCK>
    <NAME>Empty Element</NAME>
    <DESCRIPTION>An element that has only one tag, which ends with a slash character just before
 the closing angle bracket</DESCRIPTION>
    <FUNCTION>Allows a file to exhibit a uniform structure even if the file contains no data
 for a particular element.</FUNCTION>
    <NOTE>An empty element contains no data but may still have attributes assigned to it.</NOTE>
  </BUILDING_BLOCK>
  <BUILDING_BLOCK>
    <NAME>Attribute</NAME>
    <DESCRIPTION>A property of an element that can be set independently of the data stored in the element.
 For example, an ARGUMENT element could have an attribute called, say, convincing, which could
 be set to Yes or No independently of the data or other elements stored in it.</DESCRIPTION>
    <FUNCTION>Stores a property of an element.</FUNCTION>
    <NOTE>Elements can have zero attributes, one attribute, or multiple attributes.</NOTE>
  </BUILDING_BLOCK>
  <BUILDING_BLOCK>
    <NAME>Namespace</NAME>
    <DESCRIPTION>A unique name that confers uniqueness on the names of elements and attributes
 in an XML file.</DESCRIPTION>
    <FUNCTION>Prevents elements and attributes developed by one user from being confused with
 like-named elements and attributes developed by a different user.</FUNCTION>
    <NOTE>Namespaces often incorporate Internet domain names because Internet domain names
 are unique. Unlike an URL, however, a namespace doesn't refer to an actual location of
 anything. It is merely a unique identifier for the elements and attributes in that 
namespace. A namespace is often referred to as a Universal Resource Identifier or URI.</NOTE>
  </BUILDING_BLOCK>
  <BUILDING_BLOCK>
    <NAME>XML Declaration</NAME>
    <DESCRIPTION>A statement at the top of an XML file confirming that the file contains XML data 
that conforms to a particular version of the XML standard..</DESCRIPTION>
    <FUNCTION>Allows human readers and software to confirm that the file contains XML data.</FUNCTION>
    <NOTE>The first statement in an XML file should always be an XML declaration.</NOTE>
  </BUILDING_BLOCK>
  <BUILDING_BLOCK>
    <NAME>Comment</NAME>
    <DESCRIPTION>A string of text stored in an XML file but not interpreted as XML data.</DESCRIPTION>
    <FUNCTION>Provides clues to human readers about the contents an XML file.</FUNCTION>
    <NOTE>Comments can be very useful to human readers of an XML file but are typically ignored by software that 
interprets XML data.</NOTE>
  </BUILDING_BLOCK>
<!-- The following statement marks the end of -->
<!-- the root element of this file -->
</TRAINING_MODULE>

Schemas and Transforms: the Key to the XML Highway

If you've read this far, you're probably thinking, "This XML stuff is dirt simple. What's so hard about elements and attributes and namespaces and comments and processing instructions?"

If that's what you're thinking, you're exactly right. XML data files are amazingly easy to interpret. They're easy to create, too. In fact, in case it hasn't occurred to you, you could fire up Notepad and in no time at all type up the complete contents of the sample XML file listed above. Then you could save the file with an XML extension and your first XML data file would be under your belt. Ideally you'd be wearing a black belt at the time, because you would be a master of the form.

In the world of XML, though, data files are just a foundation. To experience the real power of XML in Office and elsewhere, you need to understand two other types of files: schemas and transforms.

That's the bad news. The good news is, schemas and transforms are XML data files, so you can read them the same way you read any other XML data file.

**Note   **Because schemas and transforms contain XML data, you'll sometimes see them stored in files with .xml extensions. More commonly, though, you'll see schema files with an .xsd extension, which stands for Xml Schema Definition. You'll see transforms more commonly with an .xsl extension, which stands for eXtensible Stylesheet Language. However, don't let the terminology scare you. Technically speaking, extensible stylesheet language isn't a separate language from XML. Rather, it is more like a specialized XML vocabulary.

I'll help you look deep inside a schema and a transform shortly. First, I want to discuss what these files do and why you need them.

According to Webster, a schema is a structured framework or plan or a set of rules. That's exactly how the term is used in the world of XML, too. That is, a schema is a file that describes the structure of an XML data file and the rules for what kind of data can be stored there.

Software programs rely on schemas to determine whether an XML data file conforms to the structure and rules established for it. A file that conforms to the structure and rules is considered "valid." The process of checking a file's validity is known as "validation."

Let me repeat: The structure of a body of data and the rules governing that data can be described in a schema. Based on that schema, a software program can detect whether your data is valid.

This is a watershed event in the history of computing! Up until this point, software programs had no way of knowing whether your data was valid. The validity of your data was up to you and to you alone. Not anymore!

A transform is a file that tells how to transform the contents of an XML data file for presentation to users. The process of transformation can include filtering data to remove elements that aren't needed or aren't of interest, sorting elements of data into a particular order, formatting elements in a particular way, and/or adding material to help users better understand the data.

Think about what this means: Up until now, there hasn't been a method for describing how to transform a file for presentation to users. As a result, a file of data was always presented to all users in the same way. If you wanted to present a body of data in two different ways to two different sets of users, you had to clone your original file and alter the clone independently of the original.

Now there's a computer-readable method for describing how to transform a file for presentation, which means your computer can do the transformation for you. And since computers are fast and don't get tired, you can develop as many transforms as you want and switch from one to another with a click of your mouse. Best of all, you'll never again need to clone your data files. Instead, you can keep your data in a single file and simply transform it in different ways for presentation to different audiences.

**Note   **It's no accident that the development of XML was followed almost immediately by the development of schemas and transforms. Computer scientists were seeking ways to automate the validation and transformation of data for decades. Neither of these processes could be automated until data itself became more consistent and predictable. Thanks to XML, now nearly any kind of data can be 100% consistent and predictable, so the barriers to automation have fallen away and schemas and transforms are at last a reality.

One of the benefits of storing schemas in separate schema files and transforms in separate transform files is that this arrangement makes it possible for XML data to be managed by content experts, while validation rules can be managed by experts in data structure and transformation rules can be managed by experts in presentation.

Office Professional Edition 2003, for example, enables you to create complex, 100% valid XML data and to present the data powerfully and effectively to a variety of audiences even if you have no idea what's inside a schema file or a transform file. Step-by-step procedures for accomplishing this are presented later in this article.

Sneaking a Peek Inside a Schema File

Since a schema describes the structure of an XML data file, the first step in creating a schema is to analyze the data that you want to store in your XML data file. The easiest way to illustrate this is to consider a concrete example.

Let's say you're planning an XML training program and you decide to break the program into separate "BUILDING_BLOCKS" of knowledge. This makes sense, because XML is a big subject. If you break it into smaller, easier-to-manage BUILDING_BLOCKS of knowledge, then trainees can focus on one BUILDING_BLOCK at a time.

Not only does this help the trainees learn faster, it helps you create your training program faster, because you yourself can focus on one BUILDING_BLOCK at a time.

While breaking XML knowledge into separate BUILDING_BLOCKS of knowledge, it may occur to you to treat each BUILDING_BLOCK in a similar manner. For example, you may decide to discuss each BUILDING_BLOCK's NAME, DESCRIPTION, and FUNCTION. If there's anything else to know about the BUILDING_BLOCK, you may decide to convey the remaining information in the form of a NOTE.

Does that sound familiar? That's exactly what I did when I sat down to write this article. Now let's see how this structure can be described in a schema.

As noted earlier, a schema not only describes the structure and rules for the data in an XML data file, the schema is itself an example of an XML data file. Therefore, a schema file exhibits a number of characteristics that are already familiar to you, including the following:

• The schema file starts with an XML declaration.
• The data inside the schema file is divided into elements.
• There is one root element and all the other elements are nested inside the root element.
• Most of the elements consist of a start tag, an end tag, and the data that lies between the start and end tags.
• Elements that contain no data consist of a single tag with a slash character immediately before the closing angle bracket.
• Some elements have no attributes, some have one attribute, and some have more than one attribute.
• To avoid naming conflicts with other XML data elements, the names of the elements in the schema file are associated with a unique namespace.

That's a lot to know about a file before you even peek inside it. The fact that you can know so much about a schema file without even looking at it tells you something about the power of XML. Namely, it tells you that XML data is more uniform and consistent than any other type of data, which explains why it can be manipulated by computers more easily than any other type of data.

The following schema is heavily commented to help you interpret it. Even so, you'll want to allow a bit of time to acquaint yourself with it. If any questions arise, keep in mind the following:

• Once a schema is developed, it can be used over and over again. Therefore, time spent developing or interpreting a schema is time well spent, especially since a well-conceived schema helps you produce valid XML data files in a fraction of the time it otherwise takes.
• In the future, everyone will work with XML data but most users will rely on schemas created by others. Many, many schemas will be created by industry groups and product vendors and placed into the public domain for the benefit of all. Other schemas will be created by consultants and power users. Any costs associated with schema development will be rapidly paid back in the form of higher quality data and higher productivity of workers.
• One way to improve your understanding of schemas is to search for simple schemas on the Internet and compare one to another. It also helps to compare the data stored in an XML data file with the schema that is used to validate the data.

<?xml version="1.0"?>
<!-- The root element of this file is an element called "schema"  -->
<!-- The root element belongs to a very special namespace,  -->
<!-- namely, the namespace for XML Schemas established by  -->
<!-- w3.org, the Internet standards organization.  -->
<!-- Note that a prefix (xsd) is established for this namespace.  -->
<!-- All elements in this file that belong to this namespace -->
<!-- are marked with the xsd prefix.  -->
<!-- The root element also declares a default namespace.  -->
<!-- Any unqualified element in this file, i.e., an element without -->
<!-- a prefix, is assumed to be in the default namespace  -->
<!-- The root element also declares a "target" namespace. -->
<!-- Any XML data files that use the target namespace -->
<!-- had better follow the rules in this schema or the sun -->
<!-- won't come up tomorrow.  -->
<!-- The root element further declares that elements -->
<!-- in an XML data file that uses the target namespace -->
<!-- must be fully qualified, i.e., they must be associated -->
<!-- with a namespace, either the default namespace for -->
<!-- that file or else some other namespace explicitly -->
<!-- prefixed to the element. -->
<!-- OK, here's the start tag for the root element:  -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://www.wordsite.com/NameSpace1"
  targetNamespace="http://www.wordsite.com/NameSpace1"
  elementFormDefault="qualified">
<!-- In plain English, the statements below translate to the following:  -->
<!-- In order to comply with this schema, an XML data file must contain  -->
<!-- a root element called TRAINING_MODULE. Inside the root  -->
<!-- element there can be anywhere from zero to an infinite number of  -->
<!-- BUILDING_BLOCK elements. BUILDING_BLOCK elements  -->
<!-- are a special type of element known as a BuildingBlockData type. -->
<!-- This type of element is defined later in this schema.  -->
 <xsd:element name="TRAINING_MODULE">
   <xsd:complexType>
     <xsd:sequence>
       <xsd:element name="BUILDING_BLOCK" type="BuildingBlockData" 
          minOccurs="0" maxOccurs="unbounded"/>
     </xsd:sequence>
   </xsd:complexType>
 </xsd:element>
<!-- In plain English, the statements below translate to the following: -->
<!-- A BuildingBlockData element must contain a specific -->
<!-- sequence of elements, starting with a NAME element -->
<!-- followed by a DESCRIPTION element followed by a -->
<!-- FUNCTION element followed by a NOTE element. -->
<!-- Each of these elements can contain string data, which is to -->
<!-- say, plain text data. -->
 <xsd:complexType name="BuildingBlockData">
   <xsd:sequence>
     <xsd:element name="NAME" type="xsd:string"/>
     <xsd:element name="DESCRIPTION" type="xsd:string"/>
     <xsd:element name="FUNCTION" type="xsd:string"/>
     <xsd:element name="NOTE" type="xsd:string"/>
   </xsd:sequence>
 </xsd:complexType>
<!-- The following statement marks the end of -->
<!-- the root element of this file -->
</xsd:schema>

Sneaking a Peek Inside a Transform File

Since a transform file indicates to your computer how to transform the contents of an XML data file for presentation to a particular audience, the number of transforms you need depends on how many audiences your data is presented to. Actually, even if you're the only one who will ever work with a particular body of data, multiple transforms may be needed so that you can view your data in a variety of different ways.

For the body of data in an XML training program, you may want to transform the data into a teacher's guide and also into a student guide and also into a self-quiz. Below you'll find a transform file for a teacher's guide. The transform files for a student guide and a self-quiz are available in the download file listed at the end of this article.

As noted earlier, a transform not only has the ability to transform the contents of an XML data file for presentation to viewers, it is itself an example of an XML data file. Therefore, a transform file exhibits a number of characteristics that are already familiar to you, including the following:

• The transform file starts with an XML declaration.
• The data inside the transform file is divided into elements.
• There is one root element and all the other elements are nested inside the root element.
• Most of the elements consist of a start tag, an end tag, and the data that lies between the start and end tags.
• Elements that contain no data consist of a single tag with a slash character immediately before the closing angle bracket.
• Some elements have no attributes, some have one attribute, and some have more than one attribute.
• In order to avoid naming conflicts with other XML data elements, the names of the elements in the transform file are associated with a unique namespace.

The following transform is heavily commented to help you interpret it. Even so, you'll want to allow a bit of time to acquaint yourself with it. If any questions arise, keep in mind the following:

• Once a transform is developed, it can be used over and over again. Therefore, time spent developing or interpreting a transform is time well spent, especially since a well-conceived transform will help you present XML data files in different ways to different users at the click of a button.
• In the future, everyone will work with XML data but most users will rely on transforms created by others. Many, many transforms will be created by industry groups and product vendors and placed into the public domain for the benefit of all. Other transforms will be created by consultants and power users. Any costs associated with transform development will be rapidly paid back in the form of higher quality presentations of data and higher productivity of workers.
• One way to improve your understanding of transforms is to search for simple transforms on the Internet and compare one to another. It also helps to compare the data stored in an XML data file with the transform that was used to present the data to users.

<?xml version="1.0"?>
<!-- The root element of this file is an element called "stylesheet"  -->
<!-- The root element belongs to a very special namespace,  -->
<!-- namely, the namespace for eXtensible Stylesheet Language-->
<!-- Transforms established by w3.org, the Internet standards -->
<!-- organization.  -->
<!-- The root element includes a version attribute so that  -->
<!-- software programs that work with this file will know that  -->
<!-- conforms to version 1.0 of the XSLTransform standard.  -->
<!-- Note that a prefix (xsl) has been established for this namespace.  -->
<!-- All elements in this file that belong to this namespace -->
<!-- are marked with the xsl prefix.  -->
<!-- The root element also declares a prefix ns1 for the.  -->
<!-- namespace called http://www.wordsite.com/NameSpace1 -->
<!-- OK, here's the start tag for the root element:  -->
<xsl:stylesheet
   version="1.0" 
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns:ns1="http://www.wordsite.com/NameSpace1">
<!-- In plain English, the statements below translate to the following:  -->
<!-- This file will serve as a transform for the root element  -->
<!-- of the XML data file. For that root element, it will output -->
<!-- some HTML tags and some text, including a table header. -->
<!-- The purpose of this output is to display some introductory -->
<!-- material before the elements nested inside the root element are output. -->
   <xsl:template match="/">
      <HTML>
      <HEAD>
         <TITLE>Building Blocks of XML: A Teacher Guide</TITLE>
      </HEAD>
      <BODY>
      <H2>Building Blocks of XML: A Teacher Guide</H2>
      <H3>Instructions for teacher:</H3>
      <H3>For each building block in turn ... call out the name of the building block, then call
 on a student to read aloud the description of the building block, then call on another student 
to read aloud the function of the building block. Ask a third student to describe the building 
block in his/her own words, then read aloud the note for the building block and ask for questions
 or comments before proceeding to the next building block.</H3>
      <TABLE BORDER="1" CELLPADDING="5">
         <THEAD>
            <TH>Building Block</TH>
            <TH>Description</TH>
            <TH>Function</TH>
            <TH>Note</TH>
         </THEAD>
<!-- In plain English, the statements below translate to the following:  -->
<!-- For each BUILDING_BLOCK element, this transform  -->
<!-- will output an HTML table row, placing the value of each. -->
<!-- NAME, DESCRIPTION, FUNCTION, and NOTE in a separate -->
<!-- table cell. -->
         <xsl:for-each select="ns1:TRAINING_MODULE/ns1:BUILDING_BLOCK">
            <TR ALIGN="LEFT" VALIGN="TOP">
               <TD width="96">
                  <xsl:value-of select="ns1:NAME"/>
               </TD>
               <TD width="216">
                  <xsl:value-of select="ns1:DESCRIPTION"/>
               </TD>
               <TD width="216">
                  <xsl:value-of select="ns1:FUNCTION"/>
               </TD>
               <TD width="216">
                  <xsl:value-of select="ns1:NOTE"/>
               </TD>
            </TR>
         </xsl:for-each>
      </TABLE>
      </BODY>
      </HTML>
   </xsl:template>
<!-- The following statement marks the end of -->
<!-- the root element of this file. -->
</xsl:stylesheet>

Putting the Pieces Together with Office Professional Edition 2003

What happens when you open an XML data file in an Office 2003 program that supports XML? The answer varies according to which application is involved but in general the application tries to locate a schema for validating the data and at least one transform for presenting the data to the user.

Let's follow the process from start to finish as it unfolds in Microsoft Office Word 2003:

When Word opens an XML data file, it starts by creating a blank Word document. Then it loads into the document the various data elements from the file and displays on the XML Structure task pane a complete list of those elements. You can use the list of elements to navigate the document. When you click an element in the list, Word selects that element in the document.

**Note   **Word keeps track of the attributes assigned to each element but doesn't display the attributes in the document. To view the attributes for a particular element, right-click the element either in the document or in the list on the XML Structure task pane and choose Attributes. . .. This displays a dialog box that allows you to add, modify, or delete the attributes for that element.

While loading XML data, Word detects the namespace associated with each element and checks the Word schema library for a schema targeted at that namespace. If no such schema is found, then nothing further happens. No validation or transformation of data takes place. On the other hand, if such a schema is indeed found, three important things happen.

First, Word attaches the schema to the document and immediately validates the data elements in the document against the schema. If any validation errors are detected, Word updates the list of elements on the XML Structure task pane to reflect the validation status of each element. Elements that caused validation errors are marked with special error icons. If you move your mouse over an error icon, Word displays a brief description of the error.

Second, at the bottom of the XML Structure task pane Word displays a list of the various types of data elements defined by the schema. If you select some text in the document and then click one of the element types in this list, Word applies that element to the selected text by inserting before and after the text the start and end tags for that element type.

Third, Word displays on the XML Document task pane a list of available custom transforms from the schema library plus a built-in data-only transform. The transforms are identified to the user as "data views." When a user selects a data view, Word instantly transforms the XML data and displays the results to the user. This allows the user to switch back and forth between different transforms with a click of the mouse.

**Note   **The schema library maintains a separate list of transforms for each schema in the library. It is up to a user or an administrator to add schemas to the library and also to add transforms to the schemas stored there.

Things You Can Do With XML Data in an Office 2003 Application

Now that you have become more familiar with XML and its benefits in Microsoft Office 2003, let's take a look at some common tasks you may want to do in Office. For clarity and simplicity, the examples provided below all pertain to Word. A similar set of examples could be cited for Microsoft Office Excel 2003, Microsoft Office Access 2003, and InfoPath. The concepts are similar while the step-by-step instructions differ.

Add Transforms and Schemas to the Schema Library

Adding schemas and transforms to the schema library for Word is very easy to accomplish. The following procedures assume that you have access to at least one schema file and at least one transform file. At the end of this article you can find a list of Web sites where you can download a sample XML project that contains such files.

**Note   **Since transforms are organized by schema and a separate list of transforms is maintained for each schema, you can't add a transform to the library until you've added at least one schema.

Add a schema to the schema library for Word:

1. On the Tools menu, click Templates and Add-Ins.

2. In the Templates and Add-Ins box, click the XML Schema tab.

3. Click Schema Library.

4. Click Add Schema, select a schema file, and then click Open.

   When prompted, type a friendly name for the schema. Use a short, easily recognized value because this is how the schema is listed in the library and also in the list of available schemas on the XML Schema tab of the Templates and Add-Ins dialog box.

5. Click OK to close the Schema Library dialog box.

6. Click OK to close the Templates and Add-Ins dialog box.

Add a transform to a schema in Word 2003's schema library:

1. On the Tools menu, click Templates and Add-Ins.

2. In the Templates and Add-Ins box, click the XML Schema tab.

3. Click Schema Library.

4. In the Select a schema list, select the schema to which you want to add a transform.

5. Click Add Solution.

6. Select a transform file, and then click Open.

   When prompted, type a friendly name for the transform. Use a short, easily recognized value because this is how the transform is listed under Data Views on the XML Document task pane.

7. Click OK to close the Schema Library dialog box.

8. Click OK to close the Templates and Add-Ins dialog box.

Open An Existing XML Data File As A Word 2003 Document

When you open an XML data file, Word assumes that your first priority is to view the data. As a result, Word displays the XML Document task pane, which lets you choose an appropriate data view for the file. At minimum, you can choose the built-in data-only data view. Other data views may be available too, but only if the document is attached to a schema that has one or more custom transforms associated with it in the schema library.

Open an Existing XML Data File With An XSL Transform

Rather than opening an XML data file and then viewing it through a transform, you may prefer to open it through a transform in the first place. To do this, on the File menu click Open. Select an XML data file, and then click the drop-down arrow next to the Open button and click Open with Transform.

Attach an XML Schema to a Word Document

To attach a Word document to an XML schema, on the Tools menu click Templates and Add-Ins, then click the XML Schema tab. Select a schema, and then click OK. When you do this, Word displays a list of the various types of data elements defined by the schema at the bottom of the XML Structure task pane. In addition, Word displays a list of any custom transforms associated with that schema in the schema library on the XML Document task pane. However, this list of transforms only appears when the document is initially opened. The only way for the list of transforms to reappear is to close down and restart Word for this dialog to re-present itself.

Apply XML Element Tags to Text in a Word Document

To apply XML element tags to text in a Word document, the document must be attached to an XML schema. Assuming this the case, simply select some text in the document and then click one of the element types listed at the bottom of the XML Structure task pane. In response, Word applies that element to the selected text by inserting before and after the text the start and end tags for that element type.

View XML Data through a Custom Transform

To view XML data through a custom XSLT transform, you must attach the schema containing the XML data that has one or more custom transforms associated with it in the schema library to a document. Assuming these conditions are met, simply select the desired data view (transform) on the XML Document task pane. Again, this dialog for selecting the desired transform will only appear when the document is initially opened. You must close down Word and restart to be presented this option once again.

View the Validation Status of the XML Elements in a Word Document

To view the validation status of XML elements in a Word document, you must attach an XML schema to the document. Assuming this is done, simply display the XML Structure task pane and look for validation error icons next to the data elements listed there.

Save a Word Document as an XML Document File

The fact that you can save a Word document as an XML file is a testament to the robustness of the XML standard. It's also a testament to the ingenuity of the Microsoft engineers who wrote the WordML schema that governs how Word documents are represented in XML.

Like any schema, the WordML schema requires that XML data consist of a single root element with other elements nested inside the root element. The root element for a WordML file is an element called "wordDocument". The elements nested inside this root include elements called "DocumentProperties," "Fonts," "Styles," "body," "section," and "p" (which stands for paragraph). As you may expect, you can nest many, many other elements within these elements.

To save a Word document as an XML file validated by the WordML schema, on the File menu choose Save As, and then in the Save as type list, click XML Document.

Save a Word Document as an XML Data-Only File

If a Word document contains data elements validated by a custom schema, you can save those data elements in an XML data-only file that is free of WordML elements and which therefore contains only the data elements and tags called for by the custom schema. To do this, follow these steps:

1. With an open document containing data, on the File menu, click Save As.
2. In the Save as type list, click XML Document, select the Save data only box.
3. Type a name for the document and then click Save.

Save a Word Document through an XSL Transform

When viewing XML data through a custom transform in Word, you can save the transformed data. To do so, on the File menu, click Save As. In the Save as type list, click the format such as HTML or another file type. Alternatively, whether you view a document through a custom transform or not, you can choose Save As and in the Save as type list, click XML Document, select the Apply transform box.

Automate Word in Powerful New Ways

You can automate all of the XML capabilities built into Word by using Microsoft Visual Basic® for Applications (VBA) macro programming or by using any of the .NET-compatible programming languages. In addition, some Word fields, such as the INCLUDETEXT field, now offer exciting new XML data capabilities, including support for transforms and the incredibly powerful XML Path language also known as XPath.

The XML Path language is available directly within the Microsoft Visual Basic editor, too. This language makes it possible to reach deep down inside an XML data file and extract very, very precise bits of data. For example, it can extract just the third element in a series of elements, or just the elements whose contents begin with the letter B, and so on.

Word automation has always offered the possibility to reduce hours and hours of work to a single click of your mouse but with the new capabilities inherent in XML support, the potential is greater than ever before.

Experiencing the Power of XML for Yourself

To help you experience the power of XML for yourself, I've prepared a sample XML project complete with a sample XML data file, a sample XML schema, and three sample extensible stylesheet language (xsl) transforms.

Ordinarily, you must download all four files and add the sample schema to the Word schema library and then, after that, add the transforms to the schema in the library. Then you would open the sample XML data file and use the XML Document task pane to view the data through each of the transforms and use the XML Structure task pane to check the validity of the data against the schema.

To make this whole process faster and easier, I created an installer that automatically installs the schema and transforms into the Word schema library and opens the sample XML data file for you.

Users who have seen the sample project are dazzled at the power of XML in Office Professional Edition 2003. That doesn't mean you should be satisfied just to install the project and view the data through the transforms and validate the data against the schema (all of which can be completed in less than two minutes).

Instead, after doing those things, you may want to refer to the list presented earlier of things you can do with XML data in Word. Why not try each of the items on that list, using the sample XML project for your trials? You can probably try all of the listed items in less than ten minutes. From there, you could turn to Excel, Access, or InfoPath and map your experiences with XML to those programs.

If you do this, I predict that you'll join me in saying that nothing about Office Professional Edition 2003 is as exciting or as immediately useful as XML support across Word, Excel, Access, and InfoPath.

Links to more information about XML

• Online access to this article: http://www.wordsite.com/downloads/xmlarticle.
• Sample XML Project: http://www.wordsite.com/downloads/xmlproject.htm
• XML Standard: http://www.w3.org/TR/REC-xml
• XML Schemas: http://www.w3.org/TR/xmlschema-0/
• XSL Transforms: http://www.w3.org/TR/xslt
• Extensible Stylesheet Language: http://www.w3.org/TR/xsl/
• XML Path Language: http://www.w3.org/TR/xpath

About the Author and Wordsite Office Automation

Wordsite is a division of Coan and Company, Inc., Hortonville, Wisconsin 54944 USA. Founder and President, Bill Coan, has specialized in document design, automation, and process improvement since the early 1980s. He is a recognized leader in the development of custom Microsoft Office solutions. His work and his thoughts on Microsoft Office and other software technologies have been featured in eWeek, PC Magazine, PC PRO, Information Week, Microsoft Developer Network, and nearly a score of other print and electronic media outlets.

Code Library

In the course of helping thousands of users and organizations solve Office automation problems and achieve business objectives, Wordsite developed one of the largest code libraries in the world dedicated to Office automation. The solution to your problem may already exist in our library. At the very least, large portions of the required code may already exist there. As a result, we can create solutions faster and more economically than other providers, which enables us to provide shorter turnaround times and lower costs for you.

Experience

Wordsite has developed solutions for all kinds of processes and all kinds of users in nearly every type of industry and organization. No other solution provider is better qualified to help you help you automate your work. We understand the importance of your office automation needs and we can help you meet those needs efficiently and consistently.

Free Analysis

Some of the largest organizations in the world rely on us for customized templates and macros for Microsoft Office. So do some of the smallest. Regardless of the size of your organization, we want to understand your needs, solve your problems, and help you achieve your business objectives.

Check out our examples. Check out our customer successes. Then request a free analysis of your own situation and needs: http://www.wordsite.com/services/services.htm

© Microsoft Corporation. All rights reserved.