The XSD language is defined by the elements and attributes that can be used within it, as well as their relationship to one another. At the heart of XSD are data types, which determine the type of data that can be represented by a particular piece of markup code. For example, numeric data in XSD is coded differently than text data and therefore has an associated data type that is used when creating a schema with XSD. There are two different general types of data used in XSDs: simple data and complex data. Simple data corresponds to basic pieces of information such as numbers, strings of text, dates, times, lists, and so on. Complex data, on the other hand, represents more involved information such as mixed elements and sequences of elements. Generally speaking, complex data types are built upon simple data types.

Simple data types can be used with both elements and attributes and provide a means of describing the exact nature of a piece of information. The xsd:element element is used to create elements of a simple type, whereas the xsd:attribute element is used to create attributes. Following are a few examples of each:

<xsd:element name="name" type="xsd:string"/>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="occupation" type="xsd:string"/>
<xsd:attribute name="birthdate" type="xsd:date"/>
<xsd:attribute name="weight" type="xsd:integer"/>

Although these examples show how simple data types enter the picture with elements and attributes, they don’t reveal the relationship between elements and attributes, which is critical in any XSD document. These relationships are established by complex data types, which are capable of detailing the content models of elements. Following is an example of how simple data types can be used within a complex type to describe the content model of an element named person:

<xsd:element name="person">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="name" type="xsd:string"/>
      <xsd:element name="title" type="xsd:string"/>
      <xsd:element name="occupation" type="xsd:string"/>
    </xsd:sequence>

    <xsd:attribute name="birthdate" type="xsd:date"/>
    <xsd:attribute name="weight" type="xsd:integer"/>
  </xsd:complexType>
</xsd:element>

Keep in mind that this XSD code describes a custom markup language that is used to create XML documents. In order to fully understand how the schema code works, it’s a good idea to take a look at what XML code might look like that adheres to the schema. Following is an example of some XML document data that follows the data structure laid out in the prior XSD schema code:

<person birthdate="1969-10-28" weight="160">
  <name>Milton James</name>
  <title>Mr.</title>
  <occupation>mayor</occupation>
</person>

This code should look much more familiar to you as it is basic XML code with custom elements and attributes. It doesn’t take too much analysis to see that this code adheres to the XSD schema code you just saw. For example, the person element includes two attributes, birthdate and weight, as well as three child elements: name, title, and occupation. Unlike a DTD, the schema is able to carefully describe the data type of each element and attribute. For example, the birthdate attribute is a date (xsd:date), not just a string that happens to store a date, and the weight attribute is an integer number (xsd:integer).

You now have a basic knowledge of how a schema is used to establish a markup language that in turn is used to create XML documents. What you don’t know is how a schema is actually associated with such documents. If you recall, a DTD is associated with a document by way of a document type declaration. XSDs don’t rely on a document type declaration and instead use a special attribute called noNamespaceSchemaLocation. To associate a schema with an XML document for validation purposes, you set this attribute of the root element to the location of the schema document. However, in order to use this attribute you must first declare the namespace to which it belongs. Following is how this is accomplished in XML code:

<contacts xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="contacts.xsd">
  <person birthdate="1969-10-28" weight="160">
    <name>Milton James</name>
    <title>Mr.</title>
    <occupation>mayor</occupation>
  </person>
</contacts>

This code shows how to declare the appropriate namespace and then set the noNamespaceSchemaLocation attribute for the schema document. Assuming the schema for the contacts document is located in the file named contacts.xsd, this XML document is ready for validation. This brings up an important point regarding schema documents—they are coded in XML but they are stored in files with a .xsd extension. This makes it possible to determine quickly if a file is an XSD schema.

The string type represents a string of text and is represented in the type attribute by the xsd:string value. The string type is probably the most commonly used type in XSD. Following is an example of how to use the xsd:string value to create a string element:

<xsd:element name="name" type="xsd:string"/>

In an XML document, this element might be used like this:

<name>Milton James</name>

The Boolean type represents a true/false or yes/no value and is represented in the type attribute by the xsd:boolean value. When using a Boolean type in an XML document, you can set it to true or false, or 1 or 0, respectively. Following is an example of an attribute that is a Boolean type:

<xsd:attribute name="retired" type="xsd:boolean"/>

In an XML document, this attribute might be used like this:

<person retired="false">
  <name>Milton James</name>
</person>

Number types are used in XSD to describe elements or attributes with numeric values. The following number types are available for use in schemas to represent numeric information:

To create an element or attribute for a numeric piece of information, you simply select the appropriate number type in the XSD. Following is an example of a couple of attributes that are number types:

<xsd:attribute name="height" type="xsd:decimal"/>
<xsd:attribute name="weight" type="xsd:integer"/>

In an XML document, this attribute might be used like this:

<person height="5.75" weight="160">
  <name>Milton James</name>
</person>

XSD includes support for date and time types, which is very useful when it comes to modeling such information. Following are the different date and time types that are supported in XSD:

To create an element or attribute for a date or time, you must select the appropriate date or time type in the XSD. Following is an example of an attribute that is a date type:

<xsd:attribute name="birthdate" type="xsd:date"/>

This attribute is of type xsd:date, which means that it can be used in XML documents to store a day in time, such as October 28, 1969. You don’t just set the birthdate attribute to October 28, 1969, however. Dates and times are actually considered highly formatted pieces of information, so you must enter them according to predefined formats set forth by the XSD language. The format for the xsd:date type is ccyy–mm–dd, where cc is the century (19), yy is the year (69), mm is the month (10), and dd is the day (28). The following code shows how you would specify this date in the birthdate attribute using the CCYY-MM-DD format:

<person birthdate="1969-10-28" height="5.75" weight="160">
  <name>Milton James</name>
</person>

Other date and time types use similar formats. For example, the xsd:month type uses the format ccyy–mm, xsd:year uses ccyy, and xsd:century uses the succinct format cc. The xsd:recurringDate type uses – mm-dd to format recurring dates, whereas the xsd:recurringDay type uses---dd. Following is an example of the xsd:recurringDate type so that you can see how the dashes fit into things:

<person birthday="–10--28" height="5.75" weight="160">
  <name>Milton James</name>
</person>

In this example, an attribute named birthday is used instead of birthdate, with the idea being that a birthday is simply a day and month without a birth year (a birth date implies a specific year). Notice that an extra dash appears at the beginning of the birthday attribute value to serve as a placeholder for the intentionally missing year.

The remaining time types are xsd:duration, xsd:time, and xsd:timeInstant. The xsd:duration type uses an interesting format to represent a length of time—to specify a value of type xsd:duration you must enter the length of time according to the format PyyYmmMddDThhHmmMssS. The P in the format indicates the period portion of the value, which consists of the year (yy), month (mm), and day (dd). The T in the format begins the optional time portion of the value and consists of hours (hh), minutes (mm), and seconds (ss). You can precede a time duration value with a minus sign (-) to indicate that the duration of time goes in the reverse direction (back in time). Following is an example of how you would use this format to code the time duration value 3 years, 4 months, 2 days, 13 hours, 27 minutes, and 11 seconds:

<worldrecord duration="P3Y4M2DT13H27M11S">
</worldrecord>

The xsd:time type adheres to the format hh:mm:ss.sss. In addition to specifying the hours (hh), minutes (mm), and seconds (ss.sss) of the time, you may also enter a plus (+) or minus (-) sign followed by hh:mm to indicate the offset of the time from Universal Time (UTC). As an example, the U.S. Central Standard Time zone is six hours behind UTC time, so you would need to indicate that in an xsd:time value that is in Central Standard Time (CST). Following is an example of a CST time:

<meeting start="15:30:00-06:00">
</meeting>

Notice in the code that the hours in the time are entered in 24-hour form, also known as “military time,” meaning that there is no a.m. or p.m. involved. The time specified in this example is 3:30 p.m. CST.

The xsd:timeInstant type follows the type ccyy–mm–ddThh:mm:ss.sss and is essentially an xsd:time type with the year, month, and day tacked on. As an example, the previous xsd:time type could be coded as a xsd:timeInstant type with the following code:

<meeting start="2002-02-23T15:30:00-06:00">
</meeting>

One of the neatest things about XSD is how it allows you to cook up your own custom data types. Custom data types allow you to refine simple data types to meet your own needs. For example, you can limit the range of numbers for a number type, or constrain a string type to a list of possible strings. Regardless of how you customize a type, you always begin with the xsd:simpleType element, which is used to create custom simple types. Most of the time your custom types will represent a constraint of a simple type, in which case you’ll also need to use the xsd:restriction element. The restriction element supports a type named base that refers to the base type you are customizing. Following is the general structure of a custom simple type:

<xsd:simpleType name="onetotenType">
  <xsd:restriction base="xsd:integer">
  </xsd:restriction>
</xsd:simpleType>

This code merely sets up the type to be created; the actual restrictions on the custom type are identified using one of several different elements. To constrain the range of values a number may have, you use one of the following elements:

These types allow you to set lower and upper ranges on numeric values. Following is an example of how you would limit a numeric value to a range of 1 to 10:

<xsd:simpleType name="onetotenType">
  <xsd:restriction base="xsd:integer">
    <xsd:minInclusive value="1"/>
    <xsd:maxInclusive value="10"/>
  </xsd:restriction>
</xsd:simpleType>

It’s important to note that this code only establishes a custom type named onetotenType; it doesn’t actually create an element or attribute of that type. In order to create an element or attribute of a custom type, you must specify the type name in the type attribute of the xsd:element or xsd:attribute element:

<xsd:element name="rating" type="onetotenType">

Although this approach works fine, if you plan on using a custom type with only a single element or attribute, you may want to declare the type directly within the element or attribute, like this:

<xsd:element name="rating">
  <xsd:simpleType>
    <xsd:restriction base="xsd:integer">
      <xsd:minInclusive value="1"/>
      <xsd:maxInclusive value="10"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

In addition to controlling the bounds of simple types, it is also possible to control the length of them. For example, you might want to limit the size of a string of text. To do so, you would use one of the following elements:

Because the xsd:length element specifies the exact length, you can’t use it with the xsd:minlength or xsd:maxlength elements. However, you can use the xsd:minlength and xsd:maxlength elements together to set the bounds of a string’s length. Following is an example of how you might control the length of a string type:

<xsd:element name="password">
  <xsd:simpleType>
    <xsd:restriction base="xsd:string">
      <xsd:minLength value="8"/>
      <xsd:maxLength value="12"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

In this example, a password element is created that must have at least 8 characters but no more than 12. This shows how to control the length of strings, but it is also possible to control the length of numbers. More specifically, you can use the xsd:precision and xsd:scale elements to control how many digits appear to the left or right of a decimal point; this is known as the precision of a number. The xsd:precision element determines how many total digits are allowed in a number, whereas xsd:scale determines how many of those digits appear to the right of the decimal point. So, if you wanted to allow monetary values up to $9999.00 with two decimal places, you would use the following code:

<xsd:element name="balance">
  <xsd:simpleType>
    <xsd:restriction base="xsd:decimal">
      <xsd:precision value="6"/>
      <xsd:scale value="2"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

Keep in mind that the xsd:precision and xsd:scale elements set the maximum allowable number of digits for the total number and to the right of the decimal place, which means that all of the following examples are valid for the balance element:

<balance>3.14</balance>
<balance>12.95</balance>
<balance>1.1</balance>
<balance>524.78</balance>

One other customization I’d like to mention at this point has to do with default and fixed values. In the event that an element or attribute isn’t specified in a document, you may want to declare a default value that is assumed. You may also want to limit an element or attribute so that it can have only one possible value, which is known as a fixed value. Default and fixed values are established with the default and fixed attributes of the xsd:element and xsd:attribute elements. Following are a few examples of default and fixed elements and attributes:

<xsd:element name="balance" type="xsd:decimal" default="0.0"/>
<xsd:element name="pi" type="xsd:decimal" fixed="3.14"/>
<xsd:attribute name="expired" type="xsd:boolean" default="false"/>
<xsd:attribute name="title" type="xsd:string" fixed="Mr."/>

The balance element has a default value of 0.0, which means it will assume this value if it isn’t used in a document. The same thing goes for the expired attribute, which assumes the default value of false if it goes unused. The pi element is fixed at the value 3.14, which means if it is used it must be set to that value. Similarly, the title attribute must be set to Mr. if it is used. Notice that none of the examples are defined as having both default and fixed values; that’s because you aren’t allowed to define both a default and a fixed value for any single element or attribute.

In addition to customizing simple types as you’ve seen thus far, you can also do some other interesting things with custom types. The next few sections explore the following data types, which are considered slightly more advanced custom types:

<xsd:element name="team">
  <xsd:simpleType>
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="Nashville Predators"/>
      <xsd:enumeration value="Detroit Red Wings"/>
      <xsd:enumeration value="St. Louis Blues"/>
      <xsd:enumeration value="Chicago Blackhawks"/>
      <xsd:enumeration value="Columbus Blue Jackets"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

<xsd:element name="rainfall">
  <xsd:simpleType>
    <xsd:list base="xsd:decimal">
      <xsd:length value="12"/>
    </xsd:list>
  </xsd:simpleType>
</xsd:element>

<rainfall>1.25 2.0 3.0 4.25 3.75 1.5 0.25 0.75 1.25 1.75 2.0 2.25</rainfall>

<xsd:element name="cities">
  <xsd:simpleType>
    <xsd:list base="xsd:string"/>
  </xsd:simpleType>
</xsd:element>

<xsd:element name="phonenum">
  <xsd:simpleType>
    <xsd:restriction base="xsd:string">
      <xsd:pattern value="ddd-ddd-dddd"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

<xsd:pattern value="d{3}-d{3}-d{4}"/>

<xsd:element name="pizza">
  <xsd:simpleType>
    <xsd:restriction base="xsd:string">
      <xsd:pattern value="(small|medium|large)-(thin|deep)-(sausage+)?
        (pepperoni+)?(mushroom+)?(peppers+)?(onions+)?(anchovies+)?"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

<pizza>medium-deep-sausage+mushroom+</pizza>

Empty elements contain no text content or child elements but are capable of having attributes. In fact, attributes are the only way to associate information with empty elements. You create empty elements using the xsd:complexType element in conjunction with the xsd:complexContent element. Following is an example of how you create an empty element:

<xsd:element name="automobile">
  <xsd:complexType>
    <xsd:complexContent>
      <xsd:extension base="xsd:anyType">
        <xsd:attribute name="vin" type="xsd:string"/>
        <xsd:attribute name="year" type="xsd:year"/>
        <xsd:attribute name="make" type="xsd:string"/>
        <xsd:attribute name="model" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:element>

Although this may seem like a lot of work to simply create an empty element with a few attributes, it is necessary. The xsd:complexType and xsd:complexContent elements are necessary to establish that this is a complex type, whereas the xsd:extension element is used to declare that there is no specific base type (xsd:anyType) for the element. Finally, the attributes for the element are created using the familiar xsd:attribute element. Following is an example of how you would use the automobile element in an XML document:

<automobile vin="SALHV1245SA661555" year="1995"
  make="Land Rover" model="Range Rover"/>

Element-only elements are elements that contain only child elements with no text content. They can also contain attributes, of course, but no text content is allowed within an element-only element. To create an element-only element, you simply use the xsd:complexType element. Following is an example of an element-only element that contains a single child element:

<xsd:element name="assets">
  <xsd:complexType>
    <xsd:element name="automobile" type="automobileType"/>
  </xsd:complexType>
</xsd:element>

This code presents a new wrinkle because the child element of assets is declared as type automobileType. This kind of named complex type is created much like the named simple types you saw earlier in the hour. Another approach to creating an element-only element involves coding the element as a named type. Following is an example of how you might code the automobileType named complex data type:

<xsd:complexType name="automobileType">
  <xsd:complexContent>
    <xsd:extension base="xsd:anyType">
      <xsd:attribute name="vin" type="xsd:string"/>
      <xsd:attribute name="year" type="xsd:year"/>
      <xsd:attribute name="make" type="xsd:string"/>
      <xsd:attribute name="model" type="xsd:string"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

This is the same empty complex type you saw in the previous section, except in this case it has been created as a named type with additional attributes. Following is an example of XML code that uses the assets element, automobile element, and automobileType complex type:

<assets>
  <automobile vin="SALHV1245SA661555" year="1995"
    make="Land Rover" model="Range Rover"/>
</assets>

You might be wondering exactly how useful the assets element is because it can contain only a single automobile element. In reality, practically all element-only elements are capable of storing multiple child elements, sometimes of different types. However, in order to allow for multiple child elements you must use a special construct known as a sequence. You learn about sequences a little later in this hour in the section titled “Sequences and Choices.”

Mixed elements contain both text and child elements and are the most flexible of all elements. Text-only elements are considered a type of mixed element and can contain only text with no child elements. You create text-only elements using the xsd:complexType element in conjunction with the xsd:simpleContent element. Following is an example of a text-only element:

<xsd:element name="distance">
  <xsd:complexType>
    <xsd:simpleContent>
      <xsd:extension base="xsd:decimal">
        <xsd:attribute name="units" type="xsd:string" use="required"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
</xsd:element>

The distance element can be used to store a distance traveled and is capable of using different units of measure to give meaning to the numeric content it stores. The actual distance is located in the element’s content, whereas the units are determined by the units attribute, which is a string. It’s important to notice the extra use attribute, which is set to required. This attribute setting makes the units attribute a requirement of the distance element, which means you must assign a value to the units attribute. Following is an example of how the distance element and units attribute might be used in an XML document:

<distance units="miles">12.5</distance>

Although text-only elements are certainly useful in their own right, there are some situations where it is necessary to have the utmost freedom in coding element content, and that freedom comes with the mixed element. Mixed elements are created similarly to other complex types but with the addition of the xsd:mixed attribute. Keep in mind that mixed types allow for text and child element content, as well as attributes. Following is an example of a mixed type:

<xsd:element name="message">
  <xsd:complexType mixed="true">
    <xsd:sequence>
      <xsd:element name="emph" type="xsd:string"/>
    </xsd:sequence>

    <xsd:attribute name="to" type="xsd:string" use="required"/>
    <xsd:attribute name="from" type="xsd:string" use="required"/>
    <xsd:attribute name="timestamp" type="xsd:timeInstant" use="required"/>
  </xsd:complexType>
</xsd:element>

In this example, a mixed element is created that can contain text, an emph element, and three attributes. Admittedly, I skipped ahead a little by placing the emph child element in a sequence, but that will be cleared up in the next section. Following is an example of how the message element might be used in an XML document:

<message to="you" from="me" timestamp="2001-03-14T12:45:00">
I hope you return soon. I've <emph>really</emph> missed you!
</message>

In this example the emph child element is used to add emphasis to the word “really” in the message.

One powerful aspect of complex types is the ability to organize elements into sequences and choices. A sequence is a list of child elements that must appear in a particular order, whereas a choice is a list of child elements from which only one must be used. You create a sequence with the xsd:sequence element, which houses the elements that comprise the sequence. Following is an example of creating a sequence:

<xsd:element name="quiz">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="question" type="xsd:string">
      <xsd:element name="answer" type="xsd:string">
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

In this example, the quiz element contains two child elements, question and answer, that must appear in the order specified. By default, a sequence can occur only once within an element. However, you can use the xsd:minOccurs and xsd:maxOccurs attributes to allow the sequence to occur multiple times. For example, if you wanted to allow the quiz element to contain up to 20 question/answer pairs, you would code it like this:

<xsd:element name="quiz">
  <xsd:complexType>
    <xsd:sequence minOccurs="1" maxOccurs="20">
      <xsd:element name="question" type="xsd:string">
      <xsd:element name="answer" type="xsd:string">
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Following is an example of how you might use the quiz element in an XML document:

<quiz>
  <question>What does XML stand for?</question>
  <answer>eXtensible Markup Language</answer>
  <question>Who is responsible for overseeing XML?</question>
  <answer>World Wide Web Consortium (W3C)</answer>
  <question>What is the latest version of XML?</question>
  <answer>1.0</answer>
</quiz>

If you want to allow an element to contain one of a series of optional elements, you can use a choice. A choice allows you to list several child elements and/or sequences, with only one of them allowed for use in any given element. Choices are created with the xsd:choice element, which contains the list of choice elements. Following is an example of a choice:

<xsd:element name="id">
  <xsd:complexType>
    <xsd:choice>
      <xsd:element name="ssnum" type="xsd:string">

      <xsd:sequence>
        <xsd:element name="name" type="xsd:string">
        <xsd:element name="birthdate" type="xsd:date">
      </xsd:sequence>

      <xsd:element name="licensenum" type="xsd:string">
    </xsd:choice>
  </xsd:complexType>
</xsd:element>

In this example, an element named id is created that allows three different approaches to providing identification: social security number, name and birth date, or driver’s license number. The choice is what makes it possible for the element to accept only one of the approaches. Notice that a sequence is used with the name and birth date approach because it involves two child elements. Following is an example of a few id elements that use each of the different choice approaches:

<id>
  <ssnum>123-89-4567</ssnum>
</id>
<id>
  <name>Milton James</name>
  <birthdate>1969-10-28</birthdate>
</id>
<id>
  <licensenum>12348765</licensenum>
</id>

One last topic worth covering before moving on to a complete XSD example has to do with how data types are referenced. With the exception of the root element, which is automatically referenced in an XSD, global document components must be referenced in order to actually appear as part of a document’s architecture. You should consider using a global component when you have an element or attribute that appears repeatedly within other elements. In most of the examples you’ve seen, the components have been declared locally, which means they are automatically referenced within the context that they appear. However, consider an element, such as the following one, which is declared globally:

<xsd:element name="password">
  <xsd:simpleType>
    <xsd:restriction base="xsd:string">
      <xsd:minLength value="8"/>
      <xsd:maxLength value="12"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

Although this element has been declared and is ready for use, it doesn’t actually appear within the structure of an XSD until you reference it. You reference elements using the ref attribute, which applies to both elements and attributes. Following is an example of how the password element might be referenced within another element:

<xsd:element name="login" >
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="userid" type="xsd:string"/>
      <xsd:element ref="password"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

In this example the userid element is created and used locally, whereas the password element is referenced from the previous global element declaration. Whether or not you use elements and attributes locally or globally primarily has to do with how valuable they are outside of a specific context; if an element or attribute is used only in a single location then you might as well simplify things and keep it local. Otherwise, you should consider making it a global component and then referencing it wherever it is needed using the ref attribute.

The first thing to understand about namespaces and schemas is that there is nothing magical about the prefix xsd. The prefix xsd is used with the XSD schema as a means of referencing elements and attributes that are used to construct schemas for your own custom markup languages. For example, following is the namespace declaration for the etml.xsd example schema document, which you will learn about in just a moment:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

This code shows how the prefix xsd is used to declare the XSD schema explicitly. Now that you understand how prefixes work with explicit namespace declarations, you know that this prefix could be named anything you want. Of course, there is no reason to deviate from xsd since it has become somewhat of a standard among XML developers, but I wanted to point out that there is nothing hardwired into XML when it comes to namespace prefixes.

In addition to providing a means of referencing the schema of a schema document, namespaces also play an important role in documents that rely on an XSD schema for validation. If this sounds confusing, I think a quick explanation will clear things up. In order to identify the physical schema document for a document, you must use a special attribute and assign the location of the schema document to it. There are two attributes you can use to accomplish this task:

These attributes are standard attributes that are located in a namespace named http://www.w3.org/2001/XMLSchema-instance. In order to properly reference either of these attributes, you must first explicitly declare the namespace in which they are located. It is standard to use the xsi prefix for this namespace, as the following attribute assignment shows:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

With this namespace declared, you can now use one of the schema location attributes to reference the physical schema document. Following is an example of how this task is carried out for the training log example document, which is based on the etml.xsd schema:

<trainlog
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="etml.xsd">

In this example the noNamespaceSchemaLocation attribute is used because you don’t care about associating the ETML schema with a namespace. If, however, you wanted to associate it with a namespace, you would use the schemaLocation attribute instead:

<trainlog
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.michaelmorrison.com/ns/etml etml.xsd">

Notice in the schemaLocation attribute that two pieces of information are provided: the namespace for the schema and the location of the schema document. The schemaLocation attribute is useful whenever you are working with a schema and you want to associate it with a namespace. It’s important to understand that this sample code doesn’t actually establish a schema prefix for the ETML document. Instead, it simply establishes that the etml.xsd schema document is associated with the ETML namespace. To establish prefix for the ETML tags and attributes, you must declare the ETML namespace, as shown in this code:

<trainlog
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:etml="http://www.michaelmorrison.com/ns/etml"
  xsi:schemaLocation="http://www.michaelmorrison.com/ns/etml etml.xsd">

Now the prefix etml can be used to reference tags and attributes as part of the ETML namespace, as in <etml:distance>.