W3C XML Schema: A Brief Overview

The schema language supported directly by the XQuery recommendation is W3C XML Schema, which is a W3C Recommendation with two normative parts:[*]

Part 1 Structures

Defines a language for defining schemas, which express constraints on XML documents.

Part 2 Datatypes

Defines a rich set of built-in types that can be applied to XML documents through schemas, as well as through other mechanisms.

The XML Schema built-in types defined in Part 2 are the basis for the atomic types used in XQuery. Regardless of whether schemas are present, these types can be used in queries to represent common datatypes such as strings, numbers, dates, and times. All XQuery implementations support this basic set of types.

XQuery also interacts with Part 1 of XML Schema. Schema definitions can be used in queries to validate input documents, intermediate values, and result elements.

XQuery does not currently provide specific support for other schema languages or validation mechanisms such as DTDs, RELAX NG, or Schematron. However, a processor can be written that validates a document using one of these schema languages and annotates its elements and attributes with appropriate types.

Element and Attribute Declarations

Elements and attributes are the most basic components of an XML document. The catalog schema has a declaration for each of the different kinds of elements and attributes in the catalog, such as product, number, and dept. Elements are declared in the schema using an xs:element element, while attributes are declared with xs:attribute.

Element and attribute declarations can be declared globally or locally. The catalog and product element declarations are global, meaning that they appear as a child of xs:schema in the schema document. The other element declarations, along with the attribute declaration, are local, and their scope is the type (ProductType or NameType) in which they are declared. If you're writing a schema with XQuery in mind, you should use a global declaration for any elements that you want to validate separately. That's because you can only validate against a global element declaration.

Types

Every element and attribute is associated with a type. Types are used to specify a class of elements (or attributes), including their allowed values, the structure of their content, and/or their attributes.

Simple and complex types

Types in XML Schema can be either simple or complex. Simple types are those that allow text content, but no child elements or attributes. In our catalog.xml document, the elements number and colorChoices have simple types because they have neither children nor attributes. Attributes themselves always have simple types because they always have simple values.

Complex types, by contrast, allow children and/or attributes. In catalog.xml, the elements catalog, product, and desc have complex types because they have children. The name element also has a complex type, even though it does not have children, because it can have an attribute.

Complex types are further divided into four different content types. The different content types vary in whether they allow child elements and text content. Table 13-1 lists the four content types and provides examples for each. The content type is not affected by the presence of attributes; all complex types allow attributes, regardless of content type.

Table 13-1. Content types for complex types

Content type

Allows children?

Allows text content?

Example

Simple

No

Yes

<name lang="en">Shirt</name>

Element-only

Yes

No

<product dept="MEN">

  <number>784</number>

</product>

Mixed

Yes

Yes

<desc>Our <i>best</i> shirt!</desc>

Empty

No

No

<discounted value="true"/>

User-defined types

XML Schema allows user-defined types to be created based on existing types. A new simple type can be defined that is a restriction of another type. Example 13-1 shows a simple type LangType that is derived from the built-in type xs:string. New complex types can also be derived from other complex types, either by restriction (further constraining the base type) or extension (adding new attributes or child elements). For example, based on the schema in Example 13-1 you could define a new complex type ShirtType that extends ProductType to add child elements that are relevant only to shirts, such as sleeve length, not to products in general.

As with the built-in types, these type derivations result in a type definition hierarchy that is in some ways analogous to an object-oriented hierarchy of sub- and superclasses.

List types

A list type is a different variety of atomic type that represents whitespace-separated lists of values. The type of each item in the list is known as the item type. In our example schema, the colorChoices element is declared to be of a type that is a list of xs:string values. Therefore, the element:

<colorChoices>navy black</colorChoices>

has content that is treated like two separate values, navy and black. An XQuery processor treats it somewhat differently than if it had an atomic type: it treats it like a sequence of two atomic values, in this case strings. If you test the value for equality, as follows:

doc("catalog.xml")//product[colorChoices = 'navy']

it will return that element (the first product in the catalog). If colorChoices were of type xs:string, or untyped, the product would not be selected because the value navy black would be treated as one string.

Namespaces and XML Schema

When a target namespace is indicated in a schema, all of the globally declared elements and attributes take on that target namespace as part of their name. Example 13-2 shows the beginning of the catalog schema, which specifies a target namespace, http://datypic.com/prod, using the targetNamespace attribute on the xs:schema element.

Example 13-2. Beginning of the catalog schema with target namespace

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified"
           targetNamespace="http://datypic.com/prod"
           xmlns:prod="http://datypic.com/prod">
  <xs:element name="catalog" type="prod:CatalogType"/>
  <xs:complexType name="CatalogType">
  <!-- ... -->

Using this schema, the catalog element would have to be associated with a namespace in an instance document (and in any queries on that instance document). In addition, named type definitions also have names that are qualified by the target namespace. To refer to CatalogType, you use its qualified nameā€”for example, prod:CatalogType if the prefix prod is mapped to the namespace http://datypic.com/prod.



[*] Full coverage of XML Schema is outside the scope of this book. For detailed coverage, please see Definitive XML Schema by Priscilla Walmsley (Prentice Hall PTR).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.58.51.36