New Lessons (XML Schema)

Although this schema describes the same document as the one in Chapter 2, "Our First Schema", it illustrates very different aspects of W3C XML Schema.

3.2.1. Depth Versus Modularity?

Even though we will present features to balance this fact in the next chapters--xs:complexType and xs:group--we have sacrificed the modularity of our first schema to gain the depth and structure of the second one. This is a general tendency in W3C XML Schema.

In practice, you will probably want to keep a balance between these two opposite styles and allow a certain level of depth under several global elements.

There are two cases, however, in which these two styles are not equivalent. The first is when elements with the same name need to be defined with different contents at different locations. In this case, local element definitions should be used (at least at all the location except one) since the elements are identified by their names.

In our example, the element name appears both within author and character with the same datatype. We may want to define the element name with different content models in author and character, as in this instance document:

<?xml version="1.0"?>
<library>
  <book id="b0836217462" available="true">
    <isbn>
      0836217462
    </isbn>
    <title lang="en">
      Being a Dog Is a Full-Time Job
    </title>
    <author id="CMS">
      <name>
        <first>
          Charles
        </first>
        <middle>
          M.
        </middle>
        <last>
          Schulz
        </last>
      </name>
      <born>
        1922-11-26
      </born>
      <dead>
        2000-02-12
      </dead>
    </author>
    <character id="Snoopy">
      <name>
        Snoopy
      </name>
      <born>
        1950-10-04
      </born>
      <qualification>
        extroverted beagle
      </qualification>
    </character>
  </book>
</library>

Since we can define only one global element named name, we need to define at least one of the name elements locally under its parent.

The W3C Schema for XML Schema gives several examples of elements having different types depending on their location. We will see this used in the next section in our Russian doll schema: global definitions of elements have a different type in the schema for schema than local definitions or references, even though they use the same element name (xs:element).

TIP: Whether defining elements with the same name and different datatypes is good practice or not is subject to discussion. It may be confusing for human authors and more difficult to document, but W3C XML Schema gives, through local definitions, a way to avoid any confusion for the applications that will process these documents. In our example, for instance, we have two occurrences of a name element under author and under character. It is perfectly possible to define different constraints and even contents on those two elements. Although this could be presented as overloaded element names ("character/name" versus "author/name"), I find this practice unreliable, since we often don't have a clear and simple way to identify those two contexts.

Another example is recursive schema, in which an element can be included within an element of the same type directly or indirectly in a child element. In this case, a flat design employing references must be used since the depth of these recursive structures is unlimited.

W3C XML Schema offers several examples of such elements with local definitions of elements that can be recursively nested, as is the case in our second schema. A flat design must be used since these elements need to be referenced if we don't want to limit the maximum depth of the structure, and the schema for schema uses a reference mechanism. (The actual mechanism used in this case involves an element group, a feature we have not seen yet but is equivalent to an actual reference to an element.)

3.2. New Lessons

3.2.1. Depth Versus Modularity?

3.2.2. Russian Doll and Object-Oriented Design

3.2.3. Where Have the Element Types Gone?