Advanced Topics

To close out this chapter, we're going to discuss some topics that I consider to be a little more advanced than what we've covered so far. These topics are namespaces, qualified and unqualified locals, and finally, schema file location.

Namespaces and Qualifications

Toward the beginning of this chapter, when we were working with the code in Listing 1.8, I told you that I would explain the usage of the element prefix xsd: later in this chapter. Well, that's what we're going to cover now.

Just as a DTD has a namespace called a target namespace to which its elements belong, so do schemas. We now have a new attribute for the <schema> element, the targetNamespace attribute. The targetNamespace enables distinction between definitions and declarations from different schema. For example, target namespaces would distinguish between the element in the XML schema language and a declaration for an element in a listing of the periodic table. The first element is part of the http://www.w3.org/1999/XMLSchema target namespace; the other is not.

To check that an instance document conforms to one or more schemas, we need to identify which element and attribute declarations and type definitions in the schemas should be used to check the corresponding elements and attributes in the instance document. That's what the target namespace is for.

Those of us who are writing or will be writing schema documents have several options that affect how the identities of elements and attributes are represented in instance documents. We have to decide whether or not locally declared elements and attributes in an instance document must be qualified when used in a namespace.

Earlier I defined what I called declaration scope. If an element or attribute declaration appears as an immediate child of the <xsd:schema> declaration and is external to any complexType declaration, then it is considered a global declaration.

Schemas allow us to determine whether or not local declarations need to be qualified either by using an explicit prefix or implicitly by default. These decisions we make have a number of consequences concerning the structure of schemas and instance documents.

To specify whether elements and attributes are qualified or unqualified, there are two new attributes for the <schema> element. The attribute attributeFormDefault specifies whether or not attributes are to be qualified or unqualified, and elementFormDefault specifies whether or not elements are to be qualified or unqualified.

We'll look at qualified local declarations first.

Qualified Locals

Here's the beginning of our resumes schema as we originally declared it:

 <schema xmlns="http://www.w3.org/2000/08/XMLSchema">     ...           <annotation>             <documentation> 

Now let's add some additional attributes to this declaration (see Listing 1.17).

Listing 1.17 Expanded Schema Declaration

 <schema xmlns=http://www.w3.org/2000/08/XMLSchema      xmlns:res="http://www.myorg.com/namespace"      targetNameSpace=" http://www.myorg.com/namespace"      elementFormDefault="qualified"      attributeFormDefault="unqualified"  >  <element name="resumes" type="res:resumesType"/>  <element name="comment" type="xsd:string"/>  < complexType name="resumesType">    <sequence>      <element name="applicant" type="res:address"/>      <element name="jobsAvailable" type="res:jobListType"/>      <element ref="comment" minOccurs="0"/>    </sequence>    <attribute name="applicationDate" type="date"/>  </complexType>  </schema> 

The first xmlns attribute specifies the W3C default schema namespace. All elements without a namespace prefix are assumed to belong to it. The second xmlns attribute specifies a local namespace that implements the prefix res and points to the same namespace as the target namespace. All locally declared elements, if required, must be qualified with this namespace prefix; otherwise , a schema processor will not know in which namespace to look for the element definition.

The next two attributes specify the qualifications. The attribute elementFormDefault says that all locally declared elements must be prefixed with the appropriate namespace prefix, in this case res . The attributeFormDefault states that attributes remain unqualified. Another point I'd like to mention here is that qualified is the default value for these two attributes, so it isn't really necessary to declare them. I recommend that you do, however, in the interest of good readability. There's no sense in making something harder than it already is.

An instance document that follows this schema declaration would look like what is shown in Listing 1.18.

Listing 1.18 XML Document that Adheres to the Expanded Schema

 <?xml version="1.0"?>  <res:resumes applicationDate="2000-12-20"  xmlns:res="http://www.myorg.com/namespace">    <res:applicant>      <res:name>Troy Miller</name>      <res:street>MBA Way</street>      <res:city>Roy</city>      <res:state>UT</state>      <res:zip>84067</zip>    </res:applicant>    <res:applicant>      <res:name>Mark Hilliard</name>      <res:street>1821 W. 2400 S.</street>      <res:city>Roy</city>      <res:state>UT</state>      <res:zip>84067</zip>    </res:applicant>    <res:comment>Can we hire one of these people, please?</comment>    <res:jobsAvailable>      <res:job num="1176A0">        <res:title>Programmer</title>        <res:positions>Emp 4</positions>        <res:salary>45000</salary>        <res:comment>What programming language?</comment>      </res:job>      <res:job num="A5-113-2">        <res:title>Claim Adjuster</title>        <res:position>Emp 6</position>        <res:salary >32000</salary>        <res:hiredate>2000-12-21</hiredate>      </res:job >    </res:jobsAvailable >  </res:resumes> 

Notice that the xmlns declaration matches the declaration in the schema declaration, as it should.

Here's the explanation for the use of the xsd prefix that we've used up to this point. If you look back at when this prefix was first used (in the "The Basics of Schema" section of this chapter), you'll see that the default namespace declared in this schema was assigned the prefix xsd . Here's the line that did this:

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

So, it was necessary to prefix all elements of the schema with that namespace identifier. Although it isn't dictated anywhere , if you do assign a prefix to W3C elements through the use of the xmlns attribute, the generally accepted standard is to use xsd .

Unqualified Locals

Listing 1.19 shows the resumes schema again. We'll keep the same attributes as the previous qualified examples, but we'll change the elementFormDefault to unqualified .

Listing 1.19 The Resumes Schema with unqualified Specifically Stated

 <schema xmlns=http://www.w3.org/2000/08/XMLSchema      xmlns:res="http://www.myorg.com/namespace"      targetNameSpace=" http://www.myorg.com/namespace"      elementFormDefault="unqualified"      attributeFormDefault="unqualified"  >  <element name="resumes" type="res:resumesType"/>  <element name="comment" type="xsd:string"/>  < complexType name="resumesType">    <sequence>      <element name="applicant" type="res:address"/>      <element name="jobsAvailable" type="res:jobListType"/>      <element ref="comment" minOccurs="0"/>    </sequence>    <attribute name="applicationDate" type="date"/>  </complexType>  </schema> 

The only thing different here is that the elementFormDefault attribute was changed to unqualified .

Listing 1.20 shows what the instance document looks like for this schema.

Listing 1.20 XML Document Conforming to Listing 1.19

 <?xml version="1.0"?>  <res:resumes applicationDate="2000-12-20"  xmlns:res="http://www.myorg.com/namespace">    <applicant>      <name>Troy Miller</name>      <street>MBA Way</street>      <city>Roy</city>      <state>UT</state>      <zip>84067</zip>    </applicant>    <applicant>      <name>Mark Hilliard</name>      <street>1821 W. 2400 S.</street>      <city>Roy</city>      <state>UT</state>      <zip>84067</zip>    </applicant>    <res:comment>Can we hire one of these people, please?</comment>    <jobsAvailable>      <job num="1176A0">        <title>Programmer</title>        <positions>Emp 4</positions>        <salary>45000</salary>        <comment>What programming language?</comment>      </job>      <job num="A5-113-2">        <title>Claim Adjuster</title>        <position>Emp 6</position>        <salary >32000</salary>        <hiredate>2000-12-21</hiredate>      </job >    </jobsAvailable >  </res:resumes> 

As expected, all locally declared elements are unqualified. The globally declared elements, though, are still prefixed with the namespace prefix.

Schema File Location

There's one last topic concerning XML schema that I'd like to cover before moving on: how to specify the location and name of schema files in an instance document. This specification requires the introduction of one more namespace definition.

We know that the default namespace for XML schema is http://www.w3.org/1999/XMLSchema. This is used to qualify all constructs that appear in schema documents. To qualify any XML schema attributes that might appear in instance documents, we declare the namespace http://www.w3.org/1999/XMLSchema-instance. Makes sense, doesn't it? Keep the names consistent and everything is much easier to read. The generally accepted default prefix for this namespace, if required, is xsi: . You'll see its implementation next.

The schema specification defines the attribute schemaLocation to provide the functionality of specifying a schema's location. The schemaLocation attribute contains a whitespace-delimited list of whitespace-delimited namespace-location pairs. Listing 1.21 shows an XML document fragment.

Listing 1.21 Declaring a Schema Location

 <?xml version="1.0"?>  <resumes xmlns:res="http://www.myorg.com/namespace"           xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"           xsi:schemaLocation="http://www.myorg.com                              "http://www.myorg.com/resumes.xsd"  >    <res:applicant>      <res:name>Tracy Lance</name>      <res:street>Intranet Avenue</street>  . 

Here we declare the instance namespace first to define the xsi: prefix. Next we declare the location and name of the schema document that applies to this XML document. The xsi:schemaLocation specifies that the schema that applies to this document is located at http://www.myorg.com and the filename associated with this schema is resumes.xsd .

We've covered a lot in this chapter. You now have the capability to write basic DTDs and schema documents. Although you probably feel a little overwhelmed, it will all come in time. If you have further questions about any topic in this chapter, I refer you to any of the excellent texts out there that cover this topic. Also, you should obtain a copy of the W3C specification and keep it close.

It's time to take a break from XML and move on to other topics. In the following chapter, we'll discuss the Extensible Stylesheet Language Transformations. It is a language that enables you to take an XML document and transform it into just about any other format you can think of: HTML, another XML document, and so on. So let's get going.