Проверка правильности XML

Раздел 1. Введение

Нужен ли мне этот учебник?

При создании базы данных, использование модели данных в сочетании с ограничениями целостности дает гарантию, что структура и содержимое данных соответствуют требованиям. Но как вы проведете в жизнь этот вид контроля при использовании XML, когда ваши данные - это просто текст в файлах, которые можно редактировать вручную? К счастью, проверка правильности файлов и документов дает гарантию того, что данные соответствуют ограничениям. В этом учебнике вы изучите, что такое проверка правильности и как проверить документ по DTD или схеме XML документа.

DTD были исходно определены в XML 1.0 Recommendation и происходят из Standard Generalized Markup Language (SGML), предшественника HTML. Их синтаксис немного отличается от XML, что является одной из помех для их использования. Они также имеют ограничения в применении, что заставило разработчиков искать им альтернативу в схемах XML. Однако DTD все еще используются в значительном количестве сред, так что понимание их является важным.

Главной альтернативой DTD является рекомендация XML Schema, поддерживаемая консорциумом World Wide Web (W3C). (Во всем этом учебнике, "схема XML" является синонимом "схема XML W3C".) Схемы, которые также являются XML-документами, обеспечивают более знакомую и более мощную среду, в которой ограничения на данные могут существовать как XML-документ.

Примеры этого учебника, если вы решите их выполнить, требуют, чтобы вы установили следующие инструменты и убедились, что они работают правильно. Выполнение примеров не является обязательным для понимания материала.

Раздел 2. Основы проверки правильности

Что такое проверка правильности?

XML-файлы разрабатываются так, чтобы они могли легко читаться и редактироваться людьми. Они также разрабатываются для легкого обмена данными между разными системами и разными приложениями.

К сожалению, оба эти преимущества могут работать против того, чтобы данные были в специфическом формате. Проверка правильности позволяет подтвердить, что XML-данные следуют заданной предопределенной структуре. Эта структура может быть обеспечена несколькими различными способами, включая DTD и схемы XML.

Поскольку слово правильный (valid) имеет другие значения в английском языке, оно иногда конфликтует со специфическим термином XML правильно форматированный (well formed).

Правильно форматированный документ соответствует правилам XML. Все элементы имеют начальные и конечные теги, все значения атрибутов заключены в кавычки, вложенность всех элементов корректна и т.д. Документ не может быть разобран, если он не является правильно форматированным.

Однако, только то, что документ может быть разобран, еще не означает, что он правильный в терминах XML. Чтобы считаться правильным, документ должен быть разобран проверяющим парсером со сравнением с предопределенной структурой.

Когда XML изначально создавался, он был одним из приложений Стандартного Обобщенного Языка Разметки (Standard Generalized Markup Language - SGML). SGML дает возможность различным системам сообщаться друг с другом, позволяя авторам создавать DTD. Пока данные следуют DTD, каждая система может прочитать и интерпретировать их.

DTD определяют элементы, которые допустимы в документе, что они могут содержать и какие атрибуты они должны иметь.

Сравним этот простой документ с его DTD:

<?xml version="1.0"?>
<!DOCTYPE memories SYSTEM "memory.dtd">
<memories>
 <memory tapeid="23412">
  <subdate>5/23/2001</subdate>
  <donor>John Baker</donor>
  <subject>Fishing off Pier 60</subject>
 </memory>
 <memory tapeid="23692">
  <subdate>8/01/2001</subdate>
  <donor>Elizabeth Davison</donor>
  <subject>Beach volleyball</subject>
 </memory>
</memories>

DTD

<!ELEMENT memories (memory*) >
<!ELEMENT memory (subdate, donor, subject) >
<!ATTLIST memory tapeid CDATA #REQUIRED >
<!ELEMENT subdate (#PCDATA) >
<!ELEMENT donor (#PCDATA) >
<!ELEMENT subject (#PCDATA) >

DTD выполняют свою задачу, но существуют и серьезные ограничения.

Во-первых, использование самого XML для описания структуры было бы значительно более удобным. Во-вторых, DTD имеют ограничения в том, что они могут определять. Не обеспечиваются типы данных и в некоторых случаях невозможны ограничения на порядок элементов. Это только некоторые из ограничений, с которыми сталкиваются разработчики при использовании DTD.

Схемы XML являются одной из альтернатив, которая была разработана, чтобы заполнить некоторые из этих пробелов. Рассмотрим тот же XML-документ, на этот раз с документом схемы.

XML-документ:

<?xml version="1.0"?>
<memories xmlns:xsi=
    "http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation=="'memory.xsd">
 <memory tapeid="23412">
  <subdate>5/23/2001</subdate>
  <donor>John Baker</donor>
  <subject>Fishing off Pier 60</subject>
 </memory>
 <memory tapeid="23692">
  <subdate>8/01/2001</subdate>
  <donor>Elizabeth Davison</donor>
  <subject>Beach volleyball</subject>
 </memory>
</memories>

Схема XML:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="memories">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element name="memory" type="memoryType"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:complexType name="memoryType">
  <xsd:sequence>
   <xsd:element name="subdate" type="xsd:date"/>
   <xsd:element name="donor" type="xsd:string"/>
   <xsd:element name="subject" type="xsd:string"/>
   <xsd:attribute name="tapeid" type="idNumber" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:schema>

Полный пример XML-файла для проверки правильности в этом учебнике состоит из информации, которая является частью Проекта Памяти Тысячелетия, в котором собрана коллекция подаренных домашних видео и других записей личных историй для потомков.

Каждый экспонат содержит данные и информацию о них, такую, как имя дарителя, место и тема.

<?xml version="1.0"?>
<memories>
 <memory tapeid="T1">
  <media mediaid="T1" status="vhs" />
  <subdate>2001-05-23</subdate>
  <donor>John Baker</donor>
  <subject>Fishing with the grandchildren on beautiful day.</subject>
  <location><description>Pier 60</description></location>
 </memory>
 <memory tapeid="T2">
  <media mediaid="T2" status="vhs"/>
  <subdate>2001-05-18</subdate>
  <donor>Elizabeth Davison</donor>
  <subject>Beach volleyball</subject>
  <location><place>Asbury Park, NJ</place></location>
 </memory>
</memories>

Раздел 3. Проверка правильности документа

Как работает процесс проверки правильности

Документы, используемые для описания структуры файлов, являются простыми текстовыми файлами. Полезно, однако, понимать, как они используются приложением, которое выполняет конкретную проверку правильности. В этом учебники в примерах используется код Java, но вам необязательно действительно выполнять проверку правильности, чтобы понять конструкцию документов.

Прежде, чем XML-документы можно будет использовать, они должны быть разобраны, обычно с созданием либо документа DOM, либо потока SAX. В другом случае парсер рассматривает каждый символ документа и решает, является ли он элементом, атрибутом строкой данных и т.п.

Парсер может также проверять структуру документа по DTD или схеме, если он был сконфигурирован для этого. Это обычно делается в установках парсера или объекта, который создает парсер.

Класс обработчика ошибок обычно расширяет вспомогательный класс DefaultHandler, который реализует интерфейс ErrorHandler.

Обработчик ошибок служит одной и только одной цели: иметь дело с нарушениями, которые возникают в ходе разбора документа.

Три типа ситуаций, которые могут возникать:

• Предупреждения, которые обычно не требуют действий
• Ошибки, которые представляют реальные проблемы
• Фатальные ошибки (такие, как то, что документ не является правильно форматированным), которые не позволяют продолжить обработку

Каждая из этих ситуаций должна быть обработана соответствующим методом. В данном примере обработчик просто возвращает информацию о возникшей проблеме, а при появлении фатальной ошибке завершает работу.

Откомпилируйте этот класс, и он готов для того, чтобы к нему обращался парсер.

import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.SAXParseException;
public class ErrorChecker extends DefaultHandler
{
  public ErrorChecker() {
  }
  public void error (SAXParseException e) {
    System.out.println("Parsing error: "+e.getMessage());
  }
  public void warning (SAXParseException e) {
    System.out.println("Parsing problem: "+e.getMessage());
  }
  public void fatalError (SAXParseException e) {
    System.out.println("Parsing error: "+e.getMessage());
    System.out.println("Cannot continue.");
    System.exit(1);
  }
}

Проверка правильности в JAXP

Проверка правильности в Xerces Java

Раздел 4. Определения Типа Документа (DTD)

Внешние DTD

Для проверки правильности документа вы должны иметь стандарт, по которому выполняется проверка. Раньше предполагалось, что задание требований к XML-документам происходит в DTD.

Когда идет речь о DTD, большинство людей лучше знакомо с внешним вариантом, в котором объявление DOCTYPE ссылается на файл, содержащий действующие определения.

Может быть использовано несколько способов для определения местонахождения DTD. Например, файл XHTML может определить DTD, которое определяет, следует ли он рекомендациям XHTML Strict, XHTML Transitional или XHTML Frameset, разработанным W3C. Чтобы определить XHTML Transitional, автор может задать:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Объявление DOCTYPE состоит из нескольких частей:

• <!DOCTYPE: Показывает процессору, что это объявление DOCTYPE.
• html: Показывает имя корневого элемента для документа. Если документ начинается с чего-то, отличного от <html> , он будет немедленно признан неправильным.
• PUBLIC: DOCTYPE может определять распознаваемое публичное DTD, и хранить потенциальный путь к серверу для выборки его. Альтернатива, SYSTEM, показана ниже. Идентификатор SYSTEM показывает URI, по которому DTD может быть найдено.
• "-//W3C//DTD HTML 4.01 Transitional//EN": Действующий публичный идентификатор для DTD Transitional XHTML.

Для прикладных DTD разработчики обычно используют идентификатор SYSTEM, такой, как:

<!DOCTYPE memories SYSTEM "http://www.nicholaschase.com/memories.dtd">

Части оператора соответствуют таковым для идентификатора PUBLIC, кроме объявления, показывающего местонахождение DTD.

Обычно, однако, объявление DOCTYPE также задает идентификатор SYSTEM при использовании идентификатора PUBLIC на случай, если процессор не распознает последний:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

Внешнее DTD может определять содержимое многих разных документов, делая их в чем-то более легкими для управления. Однако иногда правильный документ нуждается в том, чтобы подтверждать сам себя. В этом случае вам нужно включать информацию DTD в сам документ.

<?xml version="1.0"?>
<!DOCTYPE memories [
<!ELEMENT memories (memory+) >
<!ELEMENT memory (#PCDATA) >
>
<memories>
<memory>TBD</memory>
<memory>TBD</memory>
</memories>

Независимо от того, имеем мы дело с внешними или внутренними DTD, элементы являются фундаментом XML-документов, так что они обычно определяются первыми.

Все определения элементов состоят из ключевого слова ELEMENT, имени элемента и содержимого, которое может в нем быть. Элемент может содержать текст, другие элементы или ничего вообще (в случае пустого элемента).

<!DOCTYPE memories [
<ELEMENT memories (memory) >
<ELEMENT memory (subdate, donor, subject, media) >
<ELEMENT subdate (#PCDATA) >
<ELEMENT donor (#PCDATA) >
<ELEMENT subject (#PCDATA) >
<ELEMENT media EMPTY >
]>

Элемент, который содержит текст, определяется с ключевым словом #PCDATA. Это сокращение для разбираемых символьных данных (parsed character data); оно относится к любому тексту внутри элемента и не может содержать разметку. Примерами являются элементы subdate, donor и subject.

Элементы memory и memories показывают синтаксис, используемый для задания элементов, которые содержат в себе только другие элементы.

Элемент может также быть определен как EMPTY, как элемент media. Пустые элементы обычно несут всю информацию в атрибутах. Например:

<media type="vhs" />

Переменное содержимое элемента

Иногда автор хочет допустить возможность выбора для содержимого элемента. Например, структура данных содержит элемент с именем location, который может содержать либо элемент place, либо элемент description. Это записывается следующим образом, с использованием символа вертикальной черты (|), разделяющего варианты:

<!ELEMENT location (place | description) > 
<!ELEMENT place (#PCDATA) >
<!ELEMENT description (#PCDATA) >

Модификаторы (*,+ и ?)

DTD, которое создавалось до сих пор, является весьма специфичным. Каждый элемент должен появляться один раз и точно в таком порядке. Единственным исключением из этого является location, где должен появляться либо place, либо description, но не оба вместе.

Модификаторы предлагают большую гибкость в проекте. Они таковы:

• * : Элемент, определенный с модификатором *, может появляться 0 или более раз.
• + : Элемент, определенный с модификатором +, должен появляться 1 или более раз.
• ? : Элемент, определенный с модификатором ?, должен появляться 0 или 1 раз.

Код, приведенный ниже, показывает DTD, модифицированный таким образом, что количество элементов memory является неограниченным. Он также показывает, что требуется хотя бы один элемент subject, но допускается и более одного. Наконец, элемент donor не является обязательным, но если оно есть, оно может появляться только один раз. Немодифицированные элементы должны появляться один и только один раз.

<!DOCTYPE memories [
<!ELEMENT memories (memory)*  >
<!ELEMENT memory (media,
subdate,
donor?, 
subject+,
location) >
<!ELEMENT subdate (#PCDATA) >
<!ELEMENT donor (#PCDATA) >
<!ELEMENT subject (#PCDATA) >
<!ELEMENT location (place |
description) >
<!ELEMENT description (#PCDATA) >
<!ELEMENT place (#PCDATA) >
<!ELEMENT media EMPTY >
]>

Порядок следования дочерних элементов может также быть определен по DTD. Парадоксально, но, хотя дочерние элементы должны всегда появляться в том порядке, в каком они появляются в DTD, DTD может быть написано так, чтобы дочерние элементы появлялись в любом порядке.

Коротко говоря, требуемый порядок не изменяется, но может выбираться. Например, это DTD задает, что элемент location может иметь либо place, либо description:

<!ELEMENT location (place|description) >

Если этот вариант может быть повторено, как в:

<!ELEMENT location (place|description)* >

то location может содержать place и description в любом порядке. То же самое может быть применено к элементу memory:

<!ELEMENT memory (media | subdate | donor?| subject+| location)* >

В этом случае элементы могут появляться в любом порядке, поскольку DTD разрешает неограниченное число вариантов. Сначала может быть выбран subdate, затем location, затем donor и т.д. Заметьте, однако, что если применен этот прием, то некоторые предыдущие ограничения становятся бесполезными. Поскольку варианты могут быть применены более одного раза, любой из заданных элементов может быть выбран любое число раз или вообще не выбран.

Одной из вариаций, которая не обсуждалась, являются элементы, которые имеют смешанное содержимое. Смешанное содержимое содержит и текст, и другие элементы. Хорошим примером является текст, содержащий разметку HTML. Рассмотрим следующий потенциальный subject:

<subject>
A reading of Charles Dickens' <i>A Christmas Carol</i>.
Absolutely marvelous!
</subject>

Это то, что называют смешанным содержимым, потому что здесь есть и символьные данные, и элемент (<i></i>). Чтобы сделать его доступным для проверяющего парсера, должен быть определен элемент i, и элементу subject должно быть разрешено иметь любое число вариантов либо #PCDATA, либо i. Чтобы допустить общепринятую разметку, в DTD нужно иметь:

<!ELEMENT i (#PCDATA) >
<!ELEMENT b (#PCDATA) >
<!ELEMENT h1 (#PCDATA) >
<!ELEMENT br EMPTY >
<!ELEMENT p (#PCDATA) >
<!ELEMENT subject (#PCDATA|i|b|h1|br|p)* >

Хотя и возможно создать структуру XML, которая не содержит ничего, кроме элементов, более общей ситуацией является ситуация элементов с атрибутами. Атрибуты должны также быть определены, если они появляются в элементах правильного документа.

Вы можете определить атрибуты несколькими способами. Первый - просто определить их как символьные данные или CDATA:

<!ATTLIST memory tapeid CDATA #REQUIRED >

В этом случае DTD назначает элементу memory атрибут tapeid. Атрибут tapeid состоит из символьных данных и является обязательным. Элемент может также быть определен как #IMPLIED или #FIXED, в этом случае должно быть также задано значение по умолчанию.

Некоторые атрибуты перечисляемые, это значит, что значение должно выбираться из предопределенного списка. Например:

<!ATTLIST media type (8mm | vhsc | vhs | audio) '8mm' #IMPLIED >

В этом случае документ должен выбрать значение из списка, если же значение не обеспечено, парсер использует значение по умолчанию 8mm. Это случай для любого документа, для которого существует DTD, даже, если парсер непроверяющий. В одном определении ATTLIST может быть определено много атрибутов:

<!ATTLIST media type (8mm | vhsc | vhs | audio) '8mm' #IMPLIED length CDATA >

У вас может появиться необходимость связать данные при помощи использования идентификаторов, работа которых соответствует первичным и внешним ключам в реляционной базе данных. Например, может потребоваться, чтобы идентификатор memory соответствовал идентификатору media, носителя, на котором эта запись размещена. Типы данных ID и IDREF позволяют вам обеспечить такую целостность данных:

<!ATTLIST media mediaid ID #REQUIRED >
<!ATTLIST memory tapeid IDREF #REQUIRED >

Эта запись добавляет в файл два ограничения. Во-первых, значение каждого mediaid должно быть уникальным, значение каждого tapeid должно соответствовать существующему mediaid.

Один из аспектов DTD, который часто игнорируется потому, что разработчики плохо его понимают, - сущности. Сущности появляются в двух разновидностях: параметрические сущности и общие сущности. Обе разновидности используются как макросы или переменные, обеспечивающие способ установить единственное значение, которое затем может быть использовано во многих местах.

DTD:

<!ELEMENT memories (memory)* >
<!ELEMENT memory (media | subdate | donor?| subject+| location)* >
<!ATTLIST memory tapeid IDREF #REQUIRED >
<!ELEMENT subdate (#PCDATA) >
<!ELEMENT donor (#PCDATA) >
<!ELEMENT subject (#PCDATA) >
<!ELEMENT location (place|description) >
<!ELEMENT description (#PCDATA) >
<!ELEMENT place (#PCDATA) >
<!ELEMENT media EMPTY >
<!ATTLIST media mediaid ID #REQUIRED
status CDATA #IMPLIED>

Документ:

<?xml version="1.0"?>
<!DOCTYPE memories SYSTEM "memory.dtd">
<memories>
 <memory tapeid="T1">
  <media mediaid="T1" status="vhs" />
  <subdate>2001-05-23</subdate>
  <donor>John Baker</donor>
  <subject>Fishing off Pier 60</subject>
  <location><description>Outside in the woods</description></location>
 </memory>
 <memory tapeid="T2">
  <media mediaid="T2" status="vhs"/>
  <subdate>2001-05-18</subdate>
  <donor>Elizabeth Davison</donor>
  <subject>Beach volleyball</subject>
  <location><place>Clearwater beach</place></location>
 </memory>
</memories>

Ограничения DTD

DTD чрезвычайно ограничены, если идет речь о реальных типах данных, которые могут в них включаться. Например, DTD не может ограничить данные только числовым типом или типом даты. Атрибуты могут быть ограничены уникальностью значений, как ID, но в DTD нет способа определить, какого типа данных они должны быть. (И, странно, ID не может быть числом, что противоречит общепринятой практике реляционных баз данных!)

Раздел 5. Схема XML

Документ экземпляра схемы XML

В отличие от DTD, документы схемы XML строятся на самом XML. Проверка правильности при помощи схемы требует двух документов: документа схемы и документа экземпляра.

Документ схемы - это документ, содержащий структуру, а документ экземпляра содержит сами XML-данные. Приложение определяет схему для документа экземпляра одним из двух способов:

Структура документа схемы

Документ схемы XML - это просто XML-документ с предопределенными элементами и атрибутами, описывающими структуру другого XML-документа.

Рассмотрим такой простой документ схемы:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="memories">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element name="memory" maxOccurs="unbounded" type="memoryType"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:complexType name="memoryType">
  <xsd:sequence>
   <xsd:element name="media">
    <xsd:complexType>
     <xsd:attribute name="mediaid" type="xsd:string" />
     <xsd:attribute name="status" type="xsd:string" />
    </xsd:complexType>
   </xsd:element>
   <xsd:element name="subdate" type="xsd:string"/>
   <xsd:element name="donor" type="xsd:string"/>
   <xsd:element name="subject" type="xsd:string"/>
   <xsd:element name="location" type="locationType" />
  </xsd:sequence>
  <xsd:attribute name="tapeid" type="xsd:string" />
  <xsd:attribute name="status" type="xsd:string" />
 </xsd:complexType>
 <xsd:complexType name="locationType">
  <xsd:choice>
   <xsd:element name="description" type="xsd:string" />
   <xsd:element name="place" type="xsd:string" />
  </xsd:choice>
 </xsd:complexType>
</xsd:schema>

XML-документы строятся из элементов. Определение элемента в документе схемы XML состоит в придании ему имени и типа. Например:

  <xsd:element name="subdate" type="xsd:date"/>
  <xsd:element name="donor" type="xsd:string"/>
  <xsd:element name="subject" type="xsd:string"/>
  <xsd:element name="description" type="xsd:string" />
  <xsd:element name="place" type="xsd:string" />

Это простые элементы, которые содержат только текст. Элемент subdate, однако, должен быть ограничен датой в формате yyyy-mm-dd, как определено в рекомендации W3C XML Schema.

42 простых типа определены как часть этой рекомендации, включая string, int, date, decimal, boolean, timeDuration и uriReference.

Кроме встроенных простых типов, вы можете создавать новые простые типы. Спектр этих типов - от текста в определенном формате (такого, как телефонный номер или артикул товара) до числового ряда или перечисляемого списка.

Для проекта-примера нужно два новых простых типа. Первый - idNumber:

  <xsd:simpleType name="idNumber">
   <xsd:restriction base="xsd:integer">
    <xsd:minInclusive value="1" />
    <xsd:maxInclusive value="100000" />
   </xsd:restriction> 
  </xsd:simpleType>

Вы можете использовать другой тип ограничения, создавая список перечислений, такой, как ограничивающий значения для типа носителя:

 <xsd:simpleType name="mediaType">
  <xsd:restriction base="xsd:string">
   <xsd:enumeration value="8mm" />
   <xsd:enumeration value="vhs" />
   <xsd:enumeration value="vhsc" />
   <xsd:enumeration value="digital" />
   <xsd:enumeration value="audio" />
  </xsd:restriction> 
 </xsd:simpleType>

Одно из ограничений для простого типа состоит в том, что такие элементы не могут содержать атрибутов. Чтобы добавить атрибуты в элемент, вы должны преобразовать его в complexType.

Одним из способов сделать это является использование анонимных сложных типов. Он включает в себя добавление элемента complexType как потомка элемента element.

<xsd:element name="media">
 <xsd:complexType>
  <xsd:attribute name="mediaid" type="xsd:integer" />
  <xsd:attribute name="status" type="mediaType" />
 </xsd:complexType> 
</xsd:element>

В данном примере элемент media имеет теперь два атрибута, включая атрибут перечисляемого типа mediaType.

Добавление в элемент потомков также требует использования сложных типов. Проще всего перечислить один или более дочерних элементов, используя элемент sequence:

<xsd:element name="memories">
 <xsd:complexType>
  <xsd:sequence> 
   <xsd:element name="memory" type="memoryType"/>
  </xsd:sequence> 
 </xsd:complexType>
</xsd:element>

Этот пример показывает только один дочерний элемент, но вам все же нужен элемент sequence.

В типе memoryType комбинируются несколько приемов, увиденных вами недавно:

<xsd:complexType name="memoryType">
 <xsd:sequence>
  <xsd:element name="media">
   <xsd:complexType>
    <xsd:attribute name="mediaid" type="xsd:integer" />
    <xsd:attribute name="status" type="mediaType" />
   </xsd:complexType>
  </xsd:element>
  <xsd:element name="subdate" type="xsd:date"/>
  <xsd:element name="donor" type="xsd:string"/>
  <xsd:element name="subject" type="xsd:string"/>
  <xsd:element name="location" type="locationType" />
 </xsd:sequence>
 <xsd:attribute name="tapeid" type="idNumber" />
 <xsd:attribute name="status" type="xsd:string" />
</xsd:complexType>

Элемент sequence показывает все возможные дочерние элементы для данного элемента. В некоторых случаях, однако, вы хотите выбрать один элемент из списка альтернатив. Для этого вам нужен элемент choice:

<xsd:complexType name="locationType">
 <xsd:choice>
  <xsd:element name="description" type="xsd:string" />
  <xsd:element name="place" type="xsd:string" />
 </xsd:choice> 
</xsd:complexType>

До сих пор все элементы и атрибуты, добавляемые в схему, должны были появляться ровно один раз. Очевидно, что это не всегда желательно. Используя minOccurs и maxOccurs, вы можете управлять тем, должен ли компонент появляться обязательно и может ли он повторяться. В данном примере схема требует, чтобы элемент subject присутствовал, и позволяет ему появляться до пяти раз в одном элементе:

...
<xsd:element name="subject" minOccurs="1" maxOccurs="5" type="xsd:string"/>
...

Иногда вам не нужен верхний предел. Например, элемент memory может быть определен как необязательный, но если он есть, он может появляться неограниченное число раз в элементе memories:

<xsd:element name="memories">
 <xsd:complexType>
  <xsd:sequence>
    <xsd:element name="memory"
      minOccurs="0" maxOccurs="unbounded"
      type="memoryType"/>
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>

Иногда элемент содержит смешанное содержимое, а не только элементы или только текст. Например, элемент subject может содержать разметку HTML:

<subject>
 A reading of Charles Dickens' <i>A Christmas Carol</i>.
 Absolutely <b>marvelous</b>!
</subject>

Это содержимое не может быть описано как xsd:string, поскольку оно содержит элементы. Также и простое перечисление элементов i и b в последовательности не будет работать, поскольку они содержат текст. Вместо этого элемент subject должен быть определен как mixed:

<xsd:element name="subject">
 <xsd:complexType mixed="true">
  <xsd:sequence>
   <xsd:element name="i" minOccurs="0" maxOccurs="unbounded"
      type="xsd:string" />
  <xsd:element name="b" minOccurs="0" maxOccurs="unbounded"
      type="xsd:string" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>

Иногда может ограничиваться содержимое элемента, но не порядок, в котором оно появляется. Это, в частности, так для смешанного содержимого в схемах. Чтобы создать элемент, который не ограничивает порядок его потомков, используйте элемент all вместо sequence.

<xsd:element name="subject">
 <xsd:complexType mixed="true">
  <xsd:all> 
   <xsd:element name="i" minOccurs="0" maxOccurs="1" type="xsd:string" />
   <xsd:element name="b" minOccurs="0" maxOccurs="1" type="xsd:string" />
  </xsd:all> 
 </xsd:complexType>
</xsd:element>

Заметьте, что maxOccurs установлен в 1, а не в unbounded. Это обязательно для применения элемента all. Атрибуты minOccurs и maxOccurs должны быть либо 0, либо 1. Комбинирование и вложение этих групп может создавать элементы, в которых ограничены типы элементов, но не их порядок или повторяемость.

Полностью неограниченным элементом является такой, в котором разрешается какое угодно содержимое. Вы можете достичь этого через встроенный тип anyType. Например, вы можете определить элемент location содержащим любое содержимое, в любом порядке и с любой повторяемостью. Это включает в себя не только текст, но и элементы:

<xsd:element name="description" type="xsd:anyType" />

Документ схемы XML:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="memories">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element name="memory" minOccurs = "0" maxOccurs="unbounded"
          type="memoryType"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:complexType name="memoryType">
  <xsd:sequence>
   <xsd:element name="media">
    <xsd:complexType>
     <xsd:attribute name="mediaid" type="xsd:integer" />
     <xsd:attribute name="status" type="mediaType" />
    </xsd:complexType>
   </xsd:element>
   <xsd:element name="subdate" type="xsd:date"/>
   <xsd:element name="donor" type="xsd:string"/>
   <xsd:element name="subject">
    <xsd:complexType mixed="true">
     <xsd:all>
      <xsd:element name="i" minOccurs="0" maxOccurs="1"
            type="xsd:string" />
      <xsd:element name="b" minOccurs="0" maxOccurs="1"
            type="xsd:string" />
     </xsd:all>
    </xsd:complexType>
   </xsd:element>
   <xsd:element name="location" type="locationType" />
  </xsd:sequence>
  <xsd:attribute name="tapeid" type="idNumber" />
  <xsd:attribute name="status" type="xsd:string" />
 </xsd:complexType>
 <xsd:complexType name="locationType">
  <xsd:choice>
   <xsd:element name="description" type="xsd:anyType" />
   <xsd:element name="place" type="xsd:string" />
  </xsd:choice>
 </xsd:complexType>
 <xsd:simpleType name="idNumber">
  <xsd:restriction base="xsd:integer">
   <xsd:minInclusive value="1" />
   <xsd:maxInclusive value="100000" />
  </xsd:restriction>
 </xsd:simpleType>
 <xsd:simpleType name="mediaType">
  <xsd:restriction base="xsd:string">
   <xsd:enumeration value="8mm" />
   <xsd:enumeration value="vhs" />
   <xsd:enumeration value="vhsc" />
   <xsd:enumeration value="digital" />
   <xsd:enumeration value="audio" />
  </xsd:restriction>
 </xsd:simpleType>
</xsd:schema>

Документ экземпляра:

<?xml version="1.0"?>
<memories xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
        xsi:noNamespaceSchemaLocation='memory.xsd'>
 <memory tapeid="1">
  <media mediaid="1" status="vhs" />
  <subdate>2001-05-23</subdate>
  <donor>John Baker</donor>
  <subject>Fishing off Pier 60</subject>
  <location>
   <description>Outside in the woods</description>
  </location>
 </memory>
 <memory tapeid="2">
  <media mediaid="2" status="vhs"/>
  <subdate>2001-05-18</subdate>
  <donor>Elizabeth Davison</donor>
  <subject>Beach volleyball</subject>
  <location>
   <place>Clearwater beach</place>
  </location>
 </memory>
</memories>

Раздел 6. Итоговая сводка проверки правильности

Резюме

Этот учебник показал вам, как создавать и DTD, и документы схемы XML для проверки по ним ваших XML-документов. Обсуждалось также преимущество схем над DTD.

В Web есть много хорошей информации о проверке правильности XML-документов:

Обратная связь

Пожалуйста, присылайте ваши отзывы об этом учебнике. Мы заинтересованы в том, чтобы услышать ваше мнение!