home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam    

Book HomeXML SchemaSearch this book

Chapter 3. Giving Some Depth to Our First Schema

Our first schema was very flat, and all its components were defined at the top level. Our second attempt will give it more depth and show how local components may be defined.

3.1. Working From the Structure of the Instance Document

For this second schema, we follow a style opposite from the one we used in Chapter 2, "Our First Schema", and we define all the elements and attributes locally where they appear in the document.

Following the document structure, we will start by defining our document element library. This element was defined in the earlier schema as:

<xs:element name="library">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="book" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

In our new schema, we will keep the same construct and the same structure, but we will replace the reference to the book element with the actual definition of this element:

<xs:element name="library">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="book" maxOccurs="unbounded">
        <xs:complexType>
          <xs:sequence>
            <xs:element ref="isbn"/>
            <xs:element ref="title"/> 
            <xs:element ref="author" minOccurs="0"
              maxOccurs="unbounded"/> 
            <xs:element ref="character" minOccurs="0"
              maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute ref="id"/>
          <xs:attribute ref="available"/>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
</xs:element>

Because the definition of the book element is contained inside the definition of the library element, other definitions of book elements could be done at other locations in the schema without any risk of confusion--except maybe by human readers.

If all the elements and attributes still referenced in this schema are defined as global, this piece of schema is valid and accurately describes our schema. The only differences between the first schema and this intermediary step are that the definition of the book element cannot be reused elsewhere, and the book element can no longer be a document element any longer.

We can also reiterate the same operation and perform the definitions of all the elements and all the attributes locally:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="library">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="book" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="isbn" type="xs:integer"/>
              <xs:element name="title">
                <xs:complexType>
                 <xs:simpleContent>
                 <xs:extension base="xs:string">
                 <xs:attribute name="lang" type="xs:language"/>
                 </xs:extension>
                 </xs:simpleContent>
                </xs:complexType>
              </xs:element> 
              <xs:element name="author" minOccurs="0"
                maxOccurs="unbounded">
                <xs:complexType>
                 <xs:sequence>
                 <xs:element name="name" type="xs:string"/>
                 <xs:element name="born" type="xs:date"/>
                 <xs:element name="dead" type="xs:date"/>
                 </xs:sequence>
                 <xs:attribute name="id" type="xs:ID"/>
                </xs:complexType>
              </xs:element> 
              <xs:element name="character" minOccurs="0"
                maxOccurs="unbounded">
                <xs:complexType>
                 <xs:sequence>
                 <xs:element name="name" type="xs:string"/>
                 <xs:element name="born" type="xs:date"/>
                 <xs:element name="qualification" type="xs:string"/>
                 </xs:sequence>
                 <xs:attribute name="id" type="xs:ID"/>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute name="id" type="xs:ID"/>
            <xs:attribute name="available" type="xs:boolean"/>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Apart from an obvious difference in style, this new schema is validating the same instance document as in Chapter 2, "Our First Schema". It is not, strictly speaking, equivalent to the first one: it is less reusable (the document element is the only one that could be reused in another schema) and more strict, since it validates only the documents that have a library document element. Chapter 2, "Our First Schema"'s schema must validate documents having any of the elements as a document element.

TIP: The price we pay to constrain the value of the document root element with W3C XML Schema is a loss of reusability. This has been widely criticized without affecting the decision of its editors. We will see, fortunately, that there are some workarounds to limit this loss for applications that need to constrain the value of the document element.



Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.











??????????????@Mail.ru