C.2 Creating a Simple Schema


As a simple example to get you started building schemas, examine the structure of Example C-1. You may have seen the document before (it was Example A-1 in Appendix A), but this time do an inventory of the parts it contains.

Example C-1. A simple XML document for definition in a schema
<?xml version="1.0" encoding="us-ascii"?> <authors>     <person >         <name>Edward Lear</name>         <nationality>British</nationality>     </person>     <person >         <name>Isaac Asimov</name>         <nationality>American</nationality>     </person>     <person /> </authors>

This document contains an authors element, which itself contains multiple person elements. Each person element has an id attribute and may contain a name and a nationality element. For now, we'll treat all of the textual content of the elements and attributes as text. One way to define this document in a schema is with a schema whose structure mirrors the document shown in Example C-2, called a "Russian doll" schema after the wooden matruschkas. The names of the elements being defined are in bold to make it easier to read.

Example C-2. A "russian doll" schema that describes Example C-1.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >   <xs:element name="authors">      <xs:complexType>         <xs:sequence>            <xs:element name="person" maxOccurs="unbounded">               <xs:complexType>                 <xs:sequence minOccurs="0" >                    <xs:element name="name" type="xs:string" />                    <xs:element name="nationality" type="xs:string"  />                 </xs:sequence>                 <xs:attribute name="id" type="xs:string" use="required"/>               </xs:complexType>            </xs:element>         </xs:sequence>      </xs:complexType>   </xs:element> </xs:schema>

This schema starts by defining the authors element, which will be the root element for the document, and its contents. Because the authors element contains more than simple text, it is defined as an xs:complexType. That type contains a sequence of person elements. The parts of the declaration that pertain only to the authors element are shown here:

<xs:element name="authors">    <xs:complexType>       <xs:sequence>          <xs:element name="person" maxOccurs="unbounded">             ...           </xs:element>       </xs:sequence>    </xs:complexType> </xs:element>

The definition of the person element itself contains an xs:complexType containing an xs:sequence, this time specifying that name and nationality elements (each of which only contain a string) may appear in that sequence. The xs:complexType for the person element also contains a definition for the id attribute.

<xs:element name="person" maxOccurs="unbounded">   <xs:complexType>     <xs:sequence minOccurs="0" >       <xs:element name="name" type="xs:string" />       <xs:element name="nationality" type="xs:string"  />     </xs:sequence>     <xs:attribute name="id" type="xs:string" use="required"/>   </xs:complexType> </xs:element>

Because the name and nationality elements and the id attribute just contain strings, they are "simple" relative to the complex types used for the elements that contain them, so a declaration like:

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

is sufficient to say "the name element will appear here and contain a string."

There are a few other pieces to examine in Example C-2, notably the maxOccurs and minOccurs attributes on xs:element, and the use attribute on xs:attribute.

You can write the same schema in a more modular way, shown in Example C-3. Again, the names of elements are bolded.

Example C-3. A different style of schema that describes Example C-1
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >       <xs:element name="authors">     <xs:complexType>       <xs:sequence>         <xs:element maxOccurs="unbounded" ref="person"/>       </xs:sequence>     </xs:complexType>   </xs:element>       <xs:element name="person">     <xs:complexType>       <xs:sequence minOccurs="0">         <xs:element ref="name"/>         <xs:element ref="nationality"/>       </xs:sequence>       <xs:attribute ref="id" use="required"/>     </xs:complexType>   </xs:element>       <xs:element name="name" type="xs:string"/>       <xs:element name="nationality" type="xs:string"/>       <xs:attribute name="id" type="xs:string"/>     </xs:schema>

Instead of nesting all the declarations into one xs:element, this version separates all the declarations into separate pieces. Only one new piece is needed to do this, the ref attribute on xs:element and xs:attribute. Writing schemas this way is frequently simpler, as it allows you to reuse the same elements in multiple places and because it separates information about how often an element or attribute may appear (maxOccurs, minOccurs, and use, which go with the ref) from the information about an element or attribute's content (the type attribute, xs:complexType child element, and so on).

When the xs:element and xs:attribute declarations are moved out to be immediate children of the xs:schema element, they become global elements and attributes, accessible for use in any declaration. Elements also become possible root elements for the document, so Office applications may ask which element to use as the root if given schemas written in this style. (It's generally easier to keep xs:attribute declarations inside of the elements that use them, or in attribute groups, described later, rather than as globals.)

If you load either of these schemas into an Excel XML map (as described in Chapter 6) and load Example C-1 into the map, you'll get the result shown in Figure C-1.

Figure C-1. An XML map using the schema in Example C-2 and Example C-3, loaded with the data from Example C-1
figs/oxml_ac01.gif


While the two schemas are different, the model they describe to Excel (or Word, or any other schema-processing software) is exactly the same. For some record/field based vocabularies, the simple structures presented in Examples Example C-2 and Example C-3 are more than enough to get work accomplished.



Office 2003 XML
Office 2003 XML
ISBN: 0596005385
EAN: 2147483647
Year: 2003
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net