Schemas and Namespaces

One of the big ideas behind schemas was to allow XML processors to validate documents that use namespaces (which DTDs have a problem with). Toward that end, the <schema> element has a new attribute: targetNamespace .

The targetNamespace attribute specifies the namespace the schema is targeted to (that is, intended for). This means that if an XML processor is validating a document and is checking elements in a particular namespace, it will know what schema to check based on the schema's target namespace. That's the idea behind target namespacesyou can indicate what namespace a schema is targeted to so that an XML processor can determine which schema(s) to use to validate a document. For an example using the targetNamespace attribute, see "Using XML Schemas in Internet Explorer," at the beginning of this chapter.

You can also specify whether the elements and attributes that were locally declared in a schema need to be qualified when used in a namespace. We've seen globally declared elements and attributes in schemas: They're declared at the top level in the schema, directly under the <schema> element. All the other elements and attributes declared in a schemathat is, those not declared as direct children of the <schema> elementare locally declared. Schemas allow you to indicate whether locals need to be qualified when used in a document.

Using Unqualified Locals

I'll start looking at how schemas work with target namespaces and locals by beginning with unqualified locals (which don't need to be qualified in a document). To indicate whether elements need to be qualified, you use the elementFormDefault attribute of the <schema> element; to indicate whether attributes need to be qualified, you use the attributeFormDefault attribute of the same element. You can set the elementFormDefault and attributeFormDefault attributes to either "qualified" or "unqualified" .

I'll take a look at an example to see how this works. Here, I'm indicating that the target namespace of a schema is "http://www.starpowder.com/namespace" . I'm also making the W3C XML schema namespace, "http://www.w3.org/2001/XMLSchema" , the default namespace for the document so that I don't have to qualify the XML schema elements such as <annotation> and <complexType> with a prefix such as xsd .

However, I have to be a little careful: When an XML processor dealing with this schema wants to check, say, the transactionType complex type, it will need to know what namespace to searchand it won't find the transactionType type in the default namespace, which is the W3C XML schema namespace. For that reason, I'll define a new namespace prefix, t , and associate that prefix with the same namespace as the target namespace. Now I can use t: to prefix types defined in this schema so that an XML processor will know what namespace to search for their definitions.

I'll also indicate that both elements and attributes should be unqualified in this case. Here's what this new schema looks like (note that I qualify types defined in this schema with the t prefix, but not types, such as string , that are defined in the default "http://www.w3.org/2001/XMLSchema" namespace):

  <schema xmlns="http://www.w3.org/2001/XMLSchema"   xmlns:t="http://www.starpowder.com/namespace"   targetNamespace="http://www.starpowder.com/namespace"   elementFormDefault="unqualified"   attributeFormDefault="unqualified">  <annotation>         <documentation>             Book borrowing transaction schema.         </documentation>     </annotation>     <element name="transaction" type="t:transactionType"/>     <complexType name="transactionType">         <sequence>             <element name="Lender" type="t:address"/>             <element name="Borrower" type="t:address"/>             <element ref="note" minOccurs="0"/>             <element name="books" type="t:books"/>         </sequence>         <attribute name="borrowDate" type="date"/>     </complexType>     <element name="note" type="string"/>     <complexType name="address">         <sequence>             <element name="name" type="string"/>             <element name="street" type="string"/>             <element name="city" type="string"/>             <element name="state" type="NMTOKEN"/>         </sequence>         <attribute name="phone" type="string"             use="optional"/>     </complexType>     <complexType name="books">         <sequence>             <element name="book" minOccurs="0" maxOccurs="10">                 <complexType>                     <sequence>                         <element name="bookTitle" type="string"/>                         <element name="pubDate" type="date" minOccurs='0'/>                         <element name="replacementValue" type="decimal"/>                         <element name="maxDaysOut">                             <simpleType>                                 <restriction base="integer">                                     <maxExclusive value="14"/>                                 </restriction>                              </simpleType>                         </element>                     </sequence>                     <attribute name="bookID" type="t:catalogID"/>                 </complexType>             </element>         </sequence>     </complexType>     <simpleType name="catalogID" base="string">         <restriction base="string">             <pattern value="\d{3}-\d{4}-\d{3}"/>         </restriction>     </simpleType> </schema> 

So how does a document that conforms to this schema look? The following code is an example. Note that locals are unqualified, but I do need to qualify globals such as <transaction> , <note> , and <books> . (Note also that the namespace of this document is the same as the target namespace of the schema that specifies its syntax, as it should be.)

 <?xml version="1.0"?>  <at:transaction xmlns:at="http://www.starpowder.com/namespace"     borrowDate="2003-10-15">     <Lender phone="607.555.2222">         <name>Doug Glass</name>         <street>416 Disk Drive</street>         <city>Medfield</city>         <state>MA</state>     </Lender>     <Borrower phone="310.555.1111">         <name>Britta Regensburg</name>         <street>219 Union Drive</street>         <city>Medfield</city>         <state>CA</state>     </Borrower>     <at:note>Lender wants these back in two weeks!</at:note>     <at:books>         <book bookID="123-4567-890">             <bookTitle>Earthquakes for Breakfast</bookTitle>             <pubDate>2003-10-20</pubDate>             <replacementValue>15.95</replacementValue>             <maxDaysOut>14</maxDaysOut>         </book>         .         .         .     </at:books> </at:transaction> 

Using Qualified Locals

You can also require that locals be qualified. Here's an example schema that requires that element names be qualified in conforming documents:

 <schema xmlns="http://www.w3.org/2001/XMLSchema"      xmlns:t="http://www.starpowder.com/namespace"     targetNamespace="http://www.starpowder.com/namespace"  elementFormDefault="qualified"  attributeFormDefault="unqualified">     <annotation>         <documentation>             Book borrowing transaction schema.         </documentation>     </annotation>     .     .     . 

What does a document that conforms to this schema look like? Here's an example. Note that I qualify all elements explicitly:

 <?xml version="1.0"?>  <at:transaction xmlns:at="http://www.starpowder.com/namespace"     borrowDate="2003-10-15">     <at:Lender phone="607.555.2222">         <at:name>Doug Glass</at:name>         <at:street>416 Disk Drive</at:street>         <at:city>Medfield</at:city>         <at:state>MA</at:state>     </at:Lender>     <at:Borrower phone="310.555.1111">         <at:name>Britta Regensburg</at:name>         <at:street>219 Union Drive</at:street>         <at:city>Medfield</at:city>         <at:state>CA</at:state>     </at:Borrower>     <at:note>Lender wants these back in two weeks!</at:note>     <at:books>         <at:book bookID="123-4567-890">             <at:bookTitle>Earthquakes for Breakfast</at:bookTitle>             <at:pubDate>2003-10-20</at:pubDate>             <at:replacementValue>15.95</at:replacementValue>             <at:maxDaysOut>14</at:maxDaysOut>         </at:book>         .         .         .     </at:books> </at:transaction> 

Another way of creating a document that conforms to this schema is to replace the explicit qualification of every element with an implicit qualification by using a default namespace. Here's what that looks like:

 <?xml version="1.0"?>  <transaction xmlns="http://www.starpowder.com/namespace"  borrowDate="2003-10-15">     <Lender phone="607.555.2222">         <name>Doug Glass</name>         <street>416 Disk Drive</street>         <city>Medfield</city>         <state>MA</state>     </Lender>     <Borrower phone="310.555.1111">         <name>Britta Regensburg</name>         <street>219 Union Drive</street>         <city>Medfield</city>         <state>CA</state>     </Borrower>     <note>Lender wants these back in two weeks!</note>     <books>         <book bookID="123-4567-890">             <bookTitle>Earthquakes for Breakfast</bookTitle>             <pubDate>2003-10-20</pubDate>             <replacementValue>15.95</replacementValue>             <maxDaysOut>14</maxDaysOut>         </book>         .         .         .     </books> </transaction> 

So far, we've indicated that all locals must be either qualified or unqualified. However, there is a way of specifying that individual locals can be either qualified or unqualified, and you do that with the form attribute.

Here's an example. In this case, I'll leave all locals unqualified except the bookID attribute, which I'll specify must be qualified:

 <schema xmlns="http://www.w3.org/2001/XMLSchema"      xmlns:t="http://www.starpowder.com/namespace"     targetNamespace="http://www.starpowder.com/namespace"     elementFormDefault="unqualified"     attributeFormDefault="unqualified">     <annotation>         <documentation>             Book borrowing transaction schema.         </documentation>     </annotation>     <element name="transaction" type="t:transactionType"/>         .         .         .     <complexType name="books">         <sequence>             <element name="book" minOccurs="0" maxOccurs="10">                 <complexType>                     <sequence>                         <element name="bookTitle" type="string"/>                         <element name="pubDate" type="date" minOccurs='0'/>                         <element name="replacementValue" type="decimal"/>                         <element name="maxDaysOut">                             <simpleType base="integer">                                 <restriction base="integer">                                     <maxExclusive value="14"/>                                 </restriction>                              </simpleType>                         </element>                     </sequence>  <attribute name="bookID" type="t:catalogID"   form="qualified"/>  </complexType>             </element>         </sequence>     </complexType>     <simpleType name="catalogID">         <restriction base="string">             <pattern value="\d{3}-\d{4}-\d{3}"/>         </restriction>     </simpleType> </schema> 

Here's a document that conforms to this schema. Note that all locals are unqualified except the bookID attribute, which is qualified:

 <?xml version="1.0"?>  <at:transaction xmlns:at="http://www.starpowder.com/namespace"     borrowDate="2003-10-15">     <Lender phone="607.555.2222">         <name>Doug Glass</name>         <street>416 Disk Drive</street>         <city>Medfield</city>         <state>MA</state>     </Lender>     <Borrower phone="310.555.1111">         <name>Britta Regensburg</name>         <street>219 Union Drive</street>         <city>Medfield</city>         <state>CA</state>     </Borrower>     <at:note>Lender wants these back in two weeks!</at:note>     <at:books>  <book at:bookID="123-4567-890">  <bookTitle>Earthquakes for Breakfast</bookTitle>             <pubDate>2003-10-20</pubDate>             <replacementValue>15.95</replacementValue>             <maxDaysOut>14</maxDaysOut>         </book>         .         .         .     </at:books> </at:transaction> 

There's plenty more power wrapped up in schemas. For example, you can have one schema inherit functionality from another, and you can restrict the inheritance process, much as you would in an object-oriented programming language. This standard is one that's still evolvingand still expanding. Let's hope that it won't expand past the capabilities of XML processor authors and that we'll see more processors that support schemasat least partiallyin the future. You can find a good list of tools that handle schemas today at http://www.w3.org/XML/Schema.