ОСНОВЫ XML-ТЕХНОЛОГИЙvenec.ulstu.ru/lib/disk/2017/177.pdfязык для...

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

федеральное государственное бюджетное образовательное учреждение

высшего образования

«УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Г. П. Токмаков

ОСНОВЫ

XML-ТЕХНОЛОГИЙ

Учебное пособие

Ульяновск

УлГТУ

2017

УДК 004.9(075) ББК 32.973-018.2я73

Т 51

Рецензенты: д-р техн. наук, профессор Егоров Ю. П.;

канд. техн. наук Кукин Е. С.

Утверждено редакционно-издательским советом университета

в качестве учебного пособия

Токмаков, Геннадий Петрович Т 51 Основы XML-технологий : учебное пособие / Г. П. Токмаков. –

Ульяновск : УлГТУ, 2017. – 229 с.

ISBN 978-5-9795-1701-8

Учебное пособие подготовлено по материалам лекционных курсов по дисциплине «Основы XML-технологий». Основное внимание в этих мате-риалах уделено вопросам описания механизмов разметки различных аспектов информационных ресурсов, которые в терминах XML-платформы называются XML-документами. В качестве средств разметки рассмотрены языки: XML, применяемый для представления содержания документов, XSD, используемый для описания структур документов в виде XML-схем, XSL, представляющий собой средство для визуализации документов. Кроме перечисленных языков рассмотрены технология разработки экранных форм и описаны подходы к представлению семантики XML-документов средст-вами из состава стандартов XML-платформы.

Пособие предназначено для изучения студентами направлений 09.03.01, 09.03.02, 09.03.03, 09.03.04, а также может использоваться студентами других направлений и специальностей.

УДК 004.9(075)

ББК 32.973-018.2я73

Токмаков Г. П., 2017

ISBN 978-5-9795-1701-8 Оформление. УлГТУ, 2017

3

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ ......................................................................................... 7

ГЛАВА 1. ОБЗОР XML-ТЕХНОЛОГИЙ .................................. 10

1.1 ПРЕДПОСЫЛКИ СОЗДАНИЯ НОВОЙ

ТЕХНОЛОГИЧЕСКОЙ ПЛАТФОРМЫ WEB .............................. 10

1.2 ПЕРЕСМОТР ОСНОВ WEB-ТЕХНОЛОГИЙ ...................... 13

1.3 ИСТОКИ XML ........................................................................... 13

1.4 ПЛАТФОРМА XML ................................................................. 17

1.5 РАСШИРЯЕМОСТЬ XML-ПЛАТФОРМЫ .......................... 20

1.6 СФЕРЫ ПРИМЕНЕНИЯ СТАНДАРТОВ XML ................... 21

1.7 XML И ТЕХНОЛОГИИ БАЗ ДАННЫХ ................................ 23

КОНТРОЛЬНЫЕ ВОПРОСЫ.......................................................... 27

ГЛАВА 2. XML – ЯЗЫК ОПИСАНИЯ ДАННЫХ ................. 28

2.1 ОСНОВНЫЕ СВЕДЕНИЯ ОБ XML ....................................... 28

2.2 ДОКУМЕНТ, КАК ЕДИНИЦА ИНФОРМАЦИИ XML ...... 32

2.3 АНАЛИЗ СТРУКТУРЫ XML-ДОКУМЕНТА ...................... 33

2.3.1 Пролог и включения ......................................................... 34

2.3.2 Элементы ............................................................................ 37

2.3.3 Атрибуты для элементов .................................................. 40

2.4 НЕКОТОРЫЕ БАЗОВЫЕ ПРАВИЛА XML .......................... 42

КОНТРОЛЬНЫЕ ВОПРОСЫ.......................................................... 45

4

ГЛАВА 3. XSD – ЯЗЫК ОПИСАНИЯ СТРУКТУРЫ

ДАННЫХ. ......................................................................................... 46

3.1 DTD И XML-СХЕМЫ .............................................................. 47

3.1.1 Определение DTD ............................................................. 47

3.1.2 XML Schema как замена DTD ......................................... 49

3.1.3 Определение XML Schema ............................................... 50

3.2 КОМПОНЕНТЫ XML SCHEMA ............................................ 53

3.2.1 Типы данных XML Schema .............................................. 53

3.2.2 Определение простых элементов .................................... 59

3.2.3 Определение атрибутов .................................................... 60

3.2.4 Ограничения или фасеты .................................................. 61

3.2.5 Определение простых пользовательских типов ............ 71

3.2.6 Определение составных типов ........................................ 77

3.2.7 Пространства имен ............................................................ 83

3.2.8 Связывание XML-документа с XML-схемой ................ 92

3.3 СОЗДАНИЕ XML-СХЕМЫ ..................................................... 93

3.3.1 Описание базы данных Firma .......................................... 93

3.3.2 Создание композиционной XML-схемы ........................ 95

3.3.3 Создание агрегированной схемы .................................. 100

КОНТРОЛЬНЫЕ ВОПРОСЫ........................................................ 114

ГЛАВА 4. XSL – ЯЗЫК ОПИСАНИЯ ФОРМЫ ДЛЯ

ВЫВОДА ДАННЫХ ..................................................................... 116

4.1 ТАБЛИЦА СТИЛЕЙ CSS И ЯЗЫК XSL ............................. 116

4.1.1 Таблица стилей CSS ........................................................ 118

4.1.2 Язык XSL .......................................................................... 121

4.2 ПРИМЕНЕНИЕ CSS ............................................................... 127

4.2.1 Пример простой таблицы каскадных стилей .............. 127

4.2.2 Пример более сложной таблицы каскадных стилей... 129

4.3 ПРИМЕНЕНИЕ XSL ............................................................... 131

4.3.1 Основы использования XSL-таблиц стилей ................ 131

4.3.2 Использование одного шаблона XSL ........................... 131

4.3.3 Отображение переменного числа элементов ............... 138

4.3.4 Использование нескольких шаблонов .......................... 141

5

4.4 ФИЛЬТРАЦИЯ И СОРТИРОВКА ДАННЫХ XML .......... 143

4.4.1 Фильтрация данных XML .............................................. 143

4.4.2 Сортировка данных XML ............................................... 144

4.4.3 XSL-таблицы с фильтрацией и сортировкой ............... 145

4.5 ДОСТУП К АТРИБУТАМ XML ........................................... 148


ГЛАВА 5. XFORMS – ЯЗЫК ОПИСАНИЯ ФОРМ ДЛЯ

ВВОДА ДАННЫХ ......................................................................... 153

5.1 XFORMS – ТЕХНОЛОГИЯ СОЗДАНИЯ WEB-ФОРМ .... 153

5.1.1 HTML-формы и их недостатки...................................... 154

5.1.2 XForms: следующее поколение Web-форм ................. 156

5.1.3 Декларативность XForms ............................................... 158

5.2 СОЗДАНИЕ ФОРМЫ НА ЯЗЫКЕ XFORMS ..................... 160

5.2.1 Описание формы документа .......................................... 160

5.2.2 XForms-модель документа ............................................. 163

5.2.3 Пользовательский интерфейс XForms .......................... 168


ГЛАВА 6. RDF – ЯЗЫК ПРЕДСТАВЛЕНИЯ

СЕМАНТИКИ ДАННЫХ ........................................................... 177

6.1 ПРОБЛЕМЫ ОПИСАНИЯ СЕМАНТИКИ ДАННЫХ ...... 177

6.2 SEMANTIC WEB – СОСТАВ И ЭТАПЫ РАЗВИТИЯ ...... 180

6.3 ОПИСАНИЕ ФАКТОВ........................................................... 181

6.3.1 Факты как единица представления смысла данных ... 182

6.3.2 Описание фактов в языках программирования ........... 183

6.3.3 Данные и факты ............................................................... 184

6.4 ДЕСКРИПЦИОННАЯ ЛОГИКА .......................................... 185

6.4.1 Элементы дескрипционной логики ............................... 187

6.4.2 Логическая система дескрипционной логики ............. 187

6.4.3 Компоненты дескрипционной логики .......................... 189

6.5 ОБЩИЕ СВЕДЕНИЯ О МОДЕЛИ RDF .............................. 192

6.5.1 Описание факта в формате RDF .................................... 192

6.5.2 Синтаксис файла RDF ..................................................... 194

6

6.5.3 Схема RDF ........................................................................ 199

6.5.4 RDF – язык описания семантики ресурсов .................. 205

6.5.5 Недостатки RDF .............................................................. 206


ЗАКЛЮЧЕНИЕ ............................................................................. 208

СПИСОК ИСТОЧНИКОВ ......................................................... 215

ГЛОССАРИЙ ................................................................................. 220

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ .................................................. 227

7

ВВЕДЕНИЕ

Необходимость языка XML (Extensible Markup Language – расширяе-

мый язык разметки), появившегося в конце 90-х годов, была не так

однозначна, так как в то время уже в течение ряда лет использовался

язык HTML, который привел к бурному развитию Интернета и сделал

его достоянием самого широкого круга пользователей по всему

земному шару. Но дело в том, что XML создан не для того, чтобы

заменить собой язык HTML. Разработка языка XML, а также плат-

формы, созданной на его основе, была направлена на создание

прочной информационной структуры XXI века, лишь намеком на

которую явился HTML.

Ситуация в современной индустрии программирования характе-

ризуется тем, что настала потребность в установлении порядка

в неконтролируемой разработке конкурирующих технологий

и патентованных языков. Во времена разработки информационных

систем, работающих автономно, эта проблема была не так заметна,

но когда эти системы стали работать в единой среде, обнаружилось,

что организация взаимодействия таких систем представляет собой

крайне сложную задачу.

Важной составляющей информационной революции, основан-

ной на XML-технологиях, является процесс стандартизации. Много-

численные родственные стандарты, разработанные на основе языка

XML, составили платформу XML. В число этих стандартов вошли:

средства проверки ошибок и принудительного структурирования,

8

таблицы стилей для вывода и преобразования данных, надежные

методы для связывания ресурсов, средства обработки и запроса

данных, а также множество средств программирования XML-данных.

Созданная платформа призвана обеспечить взаимодействие

структурированной информации с приложениями, максимально

увеличивая ее доступность. А наличие в платформе стандартных

средств обработки XML-данных должно обеспечить новой техноло-

гии долгую и плодотворную жизнь в качестве предпочтительного

инструментария для работы со структурированной информацией.

Сегодня XML может использоваться в любых приложениях,

которым нужна структурированная информация – от сложных

геоинформационных систем с гигантскими объемами передаваемой

информации до обычных локальных программ, использующих этот

язык для описания служебной информации. Можно выделить

множество задач, связанных с созданием и обработкой структуриро-

ванной информации, для решения которых может использоваться

XML:

– в первую очередь, эта технология может оказаться полезной

для разработчиков сложных информационных систем с большим

количеством приложений, связанных с потоками информации самой

различной структурой. В этом случае XML-документы выполняют

роль универсального формата для обмена информацией между

отдельными компонентами большой программы;

– XML может использоваться в обычных приложениях для хране-

ния и обработки структурированных данных в едином формате,

т. е. использоваться в качестве промежуточного формата данных

в различных системах. Обычно схема взаимодействия между серве-

рами приложений и баз данных зависит от конкретной СУБД

и диалекта SQL, используемого для доступа к данным. Если же

результаты запроса будут представлены в некотором универсальном

(текстовом) формате, то звено СУБД станет «прозрачным» для

приложения;

– использование стилевых таблиц (XSL) позволяет обеспечить

независимое от конкретного устройства вывода отображение XML-

документов;

9

– язык XML позволяет описывать данные произвольного типа

и используется для представления специализированной информа-

ции, например химических, математических, физических формул,

медицинских рецептов, нотных записей, и т. д. Это означает, что XML

может служить мощным дополнением к HTML для распространения

в Web «нестандартной» информации;

– информация, содержащаяся в XML-документах, может изме-

няться, передаваться на машину клиента и обновляться по частям.

Спецификации XLink и XPointer позволяют ссылаться на отдельные

элементы документа c учетом их вложенности и значений атрибу-

тов;

– XML является базовым стандартом для нового языка описания

ресурсов RDF, позволяющего упростить многие проблемы в Web,

связанные с поиском нужной информации, обеспечением контроля

за содержимым сетевых ресурсов, создания электронных библиотек

и т. д.

Все перечисленное говорит об исключительной важности XML-

технологий в современной индустрии разработки информационных

систем, особенно на современном этапе, характеризующемся инте-

грацией ранее созданных информационных систем различного

назначения. Поэтому будущим специалистам в области и разработки

информационных систем будет весьма полезно освоить эту новую

технологию, которая на этапе интеграции ранее и вновь разработан-

ных автоматизированных систем управления предприятиями и орга-

низациями будет играть одну из главных ролей.

Данное учебное пособие предназначено для изучения бакалав-

рами направлений 09.03.01, 09.03.02, 09.03.03, 09.03.04, а также студен-

тами других родственных специальностей, связанных с автоматизи-

рованной обработкой информации с помощью компьютерных

средств.

10

ГЛАВА 1. ОБЗОР XML-ТЕХНОЛОГИЙ

В данной обзорной главе описываются предпосылки создания

новой технологической платформы Web, базирующейся на языке

XML, которая стала основой второго поколения этой глобальной

информационной системы. Обсуждаются перемены, произошедшие

в связи с применением стандартов XML-платформы. Анализируются

источники появления новой технологии, подходы к представлению

метаданных и описанию семантики XML-документов, предусмотрен-

ные для этого средства.

Рассматриваются вопросы организации XML-платформы, прин-

ципы обеспечения расширяемости языка XML и функциональных

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

ее стандартов. Показаны основные сферы применения стандартов

платформы XML, в частности, в базовых стандартах других широко

распространенных информационных технологий, а также в разра-

ботках электронных библиотек. В рассматриваемой главе также

затронуты вопросы интеграции технологий XML и баз данных

и оцениваются перспективы XML-платформы.

1.1 ПРЕДПОСЫЛКИ СОЗДАНИЯ НОВОЙ

ТЕХНОЛОГИЧЕСКОЙ ПЛАТФОРМЫ WEB

Создание Всемирной паутины (World Wide Web – WWW, или просто

Web) стало одним из крупнейших научно-технических достижений

последнего десятилетия XX века, основой целого ряда новых инфор-

11

мационных технологий, имеющих весьма ощутимые социально-

экономические последствия.

Идеи проекта, возникшего в стенах CERN (Европейский центр

ядерных исследований, Женева) в конце 80-х годов, в короткие сроки

реализовались в беспрецедентно развивающуюся, глобальную

и бесконечно масштабируемую распределенную гипермедийную

систему с прозрачным для пользователя распределением и неодно-

родностью ресурсов. Количество пользователей и объем представ-

ленных в ней информационных ресурсов продолжают чрезвычайно

быстро наращиваться. При этом возможен свободный доступ

к большинству информационных ресурсов Web в любой момент

времени.

С другой стороны, за несколько лет бурного развития потенциал

дальнейшего совершенствования технологий существующей версии

Web (называемой далее Web-1) оказался в значительной мере исчер-

панным. Этому способствовали недостатки языка HTML (основного

выразительного и структурообразующего средства гипермедийных

информационных ресурсов, представленных в Web), а также ограни-

ченные функциональные возможности среды поддержки этого языка

в Web.

Эти недостатки и ограничения языка заключаются в следующем:

1. Для HTML-документов не поддерживаются метаданные, описы-

вающие структурные, семантические и другие их свойства.

На момент разработки языка HTML потребности в этих средствах не

было, так как он был ориентирован не на структурную разметку

документов, а на описание формата и их представления на экране.

Отсутствие поддержки метаданных для HTML-документов не

позволяет осуществлять проверку целостности их структуры

и содержания. По этой же причине затрудняется эффективный поиск

необходимой пользователю информации в огромном накопленном

объеме информационных ресурсов Web, а также выполнение других

операций по обработке информационных ресурсов.

В условиях отсутствия поддержки метаданных для выполнения

поисковых операций соответствующие сервисы Web реализуют

только технику контекстного поиска. Поиск документов в Web

12

с учетом свойств их структурных компонентов является невозмож-

ным. Все это приводит к довольно высокому уровню шума в резуль-

татах поиска.

Наконец, без поддержки метаданных в среде Web невозможна

эффективная интеграция информационных ресурсов, поддерживае-

мых в этой среде и в других взаимодействующих с Web средах. Тех-

нически средства языка HTML позволяют интегрировать в среду Web

ресурсы баз данных, большие архивы текстовых документов,

различные мультимедийные ресурсы. Но эти инородные для гипер-

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

остаются, с точки зрения их семантики, для среды Web «черным

ящиком». Такая интеграция сводится по существу лишь к обеспе-

чению представления или отображения «внешних» ресурсов

посредством Web.

2. В спецификации не предусмотрены средства расширения

функциональности HTML-документов. Другими словами, HTML явля-

ется закрытым языком, не позволяющим пользователю дополнять

язык новыми тегами при необходимости.

Следствием закрытости языка HTML являются ограниченные

возможности структурирования документов, адекватного потреб-

ностям пользователей и отражающего хотя бы простейшие аспекты

семантики содержащихся в них данных. Закрытый характер языка

приводит также к необходимости периодического пересмотра

версий стандарта HTML для расширения его функциональности путем

добавления новых тегов или атрибутов тегов.

Перечисленные недостатки языка потребовали дальнейшего

развития информационной среды Web путем добавления в нее техно-

логий, основанных на современных методах управления данными,

прошедших испытание временем в технологиях баз данных

и текстовых поисковых системах. Основу этих методов составляют

модели данных, основанные на явном представлении и поддержке

метаданных, обеспечивающих использование техники поиска

документов на основе их содержания.

13

1.2 ПЕРЕСМОТР ОСНОВ WEB-ТЕХНОЛОГИЙ

С целью решения этих проблем консорциум W3C ведет активную деятельность, направленную на радикальный пересмотр основ Web-технологий, которая затрагивает все три базовых элемента первона-чального проекта WWW, на которых построена действующая сегодня реализация Web. Этими базовыми элементами, как известно, явля-ются: язык гипертекстовой разметки HTML, универсальный локатор ресурсов URL, протокол передачи гипертекстовых ресурсов HTTP.

В рамках выполнения этой работы создано ядро и продолжается процесс формирования независимого от области приложений комплекса средств, базирующегося на языке разметки XML [1]. Этот комплекс, получивший название XML-платформы, служит для описа-ния и обработки информационных ресурсов Web, призванной стать основой нового поколения Web, называемого далее для краткости Web-2.

Новые технологии Web базируются на открытом для расширения комплексе стандартов, составляющим XML-платформу и определяю-щим функциональные возможности для доступа к информационным ресурсам Web и их представления.

Важное место в XML-платформе занимают стандарты представле-ния метаданных, описывающие структурные и семантические свой-ства XML-документов, что позволяет в перспективе вести речь о «семантическом Web». Благодаря введению метаданных и стандар-тизации средств их описания открылись возможности для более эффективной интеграции XML-документов, основанных на использо-вании семантической информации.

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

1.3 ИСТОКИ XML

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

14

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

Первые электронные форматы, созданные с этой целью, в основ-

ном были ориентированы на описание того, как должна выглядеть

информация (представление), а не ее структуры и смысла. В качестве

примеров таких средств можно привести два ранних языка формати-

рования troff и TEX, существенно ускоривших работы по форматиро-

ванию печатных документов.

Эти языки характеризуются тем, что в них не было заложено

никаких сведений о структуре данных, поэтому документы, пред-

ставленные с их помощью, можно было лишь просматривать на

экране или выводить на печать. Более сложная обработка данных,

связанная с поиском и извлечением информации, созданием элек-

тронных перекрестных ссылок или с использованием документов

в разных приложениях с помощью данных языков, была весьма

затруднительна.

Первой системой, использующей описательные теги вместо

кодов форматирования, стала общая система кодирования (generic cod-

ing), в которой появились возможности представления данных о

структуре документов и смысле содержащейся в них информации.

Организацией, выдвинувшей эту идею, стала ассоциация Graphic

Communications Association (GCA), которая в конце 1960-х годов в проекте

«GenCode» предложила способы кодирования различных типов доку-

ментов с помощью общих тегов и сборки документов из отдельных

частей.

Следующим крупным достижением в части машинной обра-

ботки документов стал обобщенный язык разметки Generalized Markup

Language (GML), разработанный в IBM Чарльзом Гольдфарбом (Charles

Goldfarb), Эдвардом Мошером (Edward Mosher) и Рэймондом Лори

(Raymond Lorie). Они рассматривали язык GML как решение проблемы

15

кодирования документов, используемых в различных информацион-

ных подсистемах.

Для дальнейшего изложения темы учебного пособия важно

иметь ясное представление о том, что собой представляет разметка.

Разметка (markup) – это информация, добавляемая в документ для

облегчения восприятия его смысла, т. к. определяет его части и их

соотношение друг с другом. Другими словами, разметка – это сред-

ство структурирования документа.

Например, при чтении любой печатной продукции части текста

различаются по промежуткам между ними и их положению на стра-

нице, а также путем использования различных шрифтов для заго-

ловков разных уровней. Это и есть разметка, но эта разметка ориен-

тирована на восприятие текста человеком, в то время как язык GML,

направленный на структурирование документа для машинной обра-

ботки вместо пробелов использует другие символы.

Текст без промежутков между разделами и c единственным сти-

лем был бы просто нагромождением символов, и извлечение из него

информации потребовало бы большой работы. Машинная програм-

ма не смогла бы сделать даже этого, поскольку обладает лишь

элементарными возможностями поиска по шаблону.

Разметка важна в электронных документах, потому что они

обрабатываются компьютерными программами. Если в документе

нет меток или границ, программа не будет знать, как отличить один

участок текста от другого. При отсутствии разметки программе

придется работать со всем документом как с бесструктурным образо-

ванием, что резко ограничивает возможность обработки его содер-

жимого.

Язык разметки (markup language) – это способ именования и выде-

ления частей документа при помощи тегов, размещаемых в тексте

документа. В документах, закодированных с применением языка

разметки, стало возможным осуществлять редактирование, форма-

тирование и поиск при помощи различных программ, поскольку его

теги позволяли извлекать содержание данных. С появлением GML

многие фирмы стали публиковать свою техническую документацию

16

на этом языке, доказав жизнеспособность обобщенного языка

разметки на основе общей системы кодирования.

Оценив достоинства GML, в Национальном институте стандарти-

зации США (ANSI) приступили к разработке стандартного языка

описания текста на основе GML, поставив Гольдфарба во главе

проекта. При этом были использованы также результаты работы над

проектом GenCode. В конце 1970-х и начале 1980-х были опубликованы

рабочие материалы и в конечном итоге создан стандартный обоб-

щенный язык разметки (Standard Generalized Markup Language, SGML),

явившийся кандидатом на промышленный стандарт. Он вскоре стал

им, после того как был принят Министерством обороны и Налого-

вой службой США.

Являясь общей схемой кодировки текста, SGML, по сути, пред-

ставляет собой инструментарий для разработки специализиро-

ванных языков разметки. Но при этом SGML имеет свободный

синтаксис и массу параметров, назначение которых довольно

сложно запомнить. Он настолько гибок, что программное обеспе-

чение для его обработки оказалось сложным и дорогим, и его полез-

ность ограничивалась крупными организациями, которые могли

позволить себе такие затраты на сопровождение сложных сред SGML.

В начале 1990-х сотрудники европейской лаборатории физики

элементарных частиц CERN Тим Бернерс-Ли (Tim Berners-Lee) и Андерс

Берглунд (Anders Berglund) совершили революцию в обобщенном

кодировании текста, когда разработали язык разметки гипертекста

Hypertext Markup Language (HTML).

Бернерс-Ли и Берглунд создали версию документа SGML для

гипертекстовых документов, который был компактным и эффектив-

ным, и назвали ее HTML. Этот язык разметки сделал простым написа-

ние программного обеспечения и еще проще – кодирование доку-

ментов. HTML быстро вышел за пределы лаборатории и отправился

завоевывать мир.

Но в теоретическом плане HTML был шагом в обратном направ-

лении. С целью достижения простоты, которая сделала его действи-

тельно полезным на практике, пришлось пожертвовать некоторыми

принципами обобщенного кодирования. Основной недостаток

17

HTML – это использование тегов, преимущественно ориентированных

на представление, что усложняет их использование в приложениях.

Но, несмотря на приведенные недостатки, HTML стал гигантским

скачком в эволюции языков разметки, поскольку именно он стал

основой для перехода к следующему этапу развития Web, основан-

ного на XML-платформе.

1.4 ПЛАТФОРМА XML

В отличие от Web-1, где все основные функции управления

информационными ресурсами системы базируются на едином языке

HTML, создатели XML-платформы избрали иной путь, суть которого

заключается в следующем.

1. В первую очередь выделяются «фундаментальные» стан-

дарты, составляющие концептуальную и синтаксическую основу

платформы.

2. Затем их средствами определяется комплекс других стандар-

тов, каждый из которых выполняет специфические функции.

3. В случае необходимости данный комплекс открыт для попол-

нения новыми стандартами.

Описанная «модульность» организации платформы обеспечива-

ет ее открытый характер, возможности введения новых стандартов,

не затрагивая уже существующие. Функциональность этой плат-

формы определяется комплексом взаимосвязанных стандартов,

часть из которых уже принята W3C, другие находятся в стадии разра-

ботки. Таким образом, по мере появления необходимости в рамках

данной платформы можно ввести любой стандарт, расширяющий ее

функциональность.

Отсюда следует вывод, что наряду с созданием стандарта языка

XML консорциум W3C, формирующий техническую политику разви-

тия Web и разрабатывающий стандартизованные спецификации для

этой среды, на самом деле одновременно формирует новую откры-

тую для расширения функциональности технологическую плат-

форму, главным звеном которой является XML.

О функциональных возможностях XML-платформы можно судить

по приведенному ниже перечислению основных ее стандартов:

18

– фундаментальные: Namespace, XML;

– представление метаданных: XML Schema, RDF, WSDL;

– вспомогательные: XInclude, XPath;

– форматирование и трансформация XML-документов: CSS, XSLT,

XForm;

– интерфейс прикладного программирования: DOM;

– язык запросов XML-данных: XQuery;

– протоколы передачи данных: HTTP, SOAP.

Рассмотрим назначение перечисленных компонентов XML-

платформы. Сначала опишем роль языка XML. В составе стандартов

рассматриваемой платформы он выполняет две важные функции.

1. Прежде всего, он обеспечивает содержательную (структур-

ную) разметку информационных ресурсов, которые называют

в рассматриваемой среде XML-документами, а также предоставляет

средства (некоторый подъязык XML) для описания общей структуры

документов интересующего пользователя типа. Такое описание

называется XML Schema Definition (XSD).

2. Но основное назначение языка XML – это служить одним из

фундаментальных стандартов платформы XML. Другие стандарты

платформы, дополняющие его функции, связанные с управлением

данными Web, определяются в терминах синтаксиса XML. В связи

с этим их называют иногда приложениями XML.

Возвращаясь к выполняемой XML функции разметки, следует еще

раз подчеркнуть, что он (в отличие от HTML) не является полнофунк-

циональным языком, который должен решать все задачи представ-

ления, поддержки и обработки информационных ресурсов Web. Если

проводить аналогию с технологиями баз данных, то XML можно

квалифицировать как язык определения данных.

Специфика XML как языка определения данных заключается

в том, что в нем сочетаются возможности:

– описания свойств экземпляров элементов XML-документов,

составляющих содержание данного конкретного документа,

– определения свойств типа XML-документов (XSD) в терминах

типов элементов этих документов.

19

Первая группа средств (теги разметки) используется по принци-

пу самоописываемости, определяя некоторые свойства элементов

конкретного документа с помощью встраиваемых в него тегов

разметки.

Что касается XSD, то он описывает типовые свойства элементов

документа и свойства типов документов в целом. XML Schema [2-4]

наряду с RDF [5, 6] занимают важное место в составе платформы

XML, позиционируются как стандарты представления метаданных.

Основное предназначение XML Schema заключается в описании

синтаксических свойств XML-документов, а RDF – в представлении их

семантики.

Роль XSD аналогична роли схемы базы данных. При этом XSD

отчуждается от описываемых документов и хранится в каталогах

Web. Конкретные XML-документы ссылаются на это определение,

хотя они могут и включать его непосредственно в явном виде.

Стандарт Namespaces in XML (Namespace) [7] наряду с XML также

используется для определения других стандартов платформы.

Стандарт Namespace определяет для заданного XML-документа или

множества документов допустимые теги разметки и их атрибуты,

ассоциируя с ними по умолчанию некоторую семантику. Зарезерви-

рованные W3C пространства имен используются в синтаксисе языка

XML и других стандартов платформы.

Средства для форматной разметки XML-документов определяют

стандарты каскадных таблиц стилей CSS [8] и расширяемого языка

таблиц стилей XSL [9]. Вторая часть стандарта XSL, называемая XSLT

[10], позволяет описывать форматные преобразования (трансфор-

мации) XML-документов.

К числу стандартов форматирования данных можно отнести

также XForms [11] усовершенствованный и адаптированный к среде

XML-аналог механизма форм в языке HTML, обеспечивающий ввод

и передачу данных, например запросов, от Web-клиента к Web-

серверу.

Стандарт DOM [12] объектной модели XML- и HTML-документов

определяет функции интерфейса прикладного программирования

для их обработки.

20

В состав XML-платформы входит также активно разрабаты-

ваемый со второй половины 2000 г. стандарт языка запросов XQuery,

представляющий собой декларативное средство обработки XML-

данных.

В составе XML-платформы разработаны документы, описываю-

щие требования к разрабатываемому языку запросов [13], модели

данных [14-15], на которой он базируется, примеры, иллюстрирую-

щие его функциональные возможности [16], а также спецификации

синтаксиса XQuery в XML [17].

Стандарт XPath [18] определяет понятие фрагмента XML-

документа, используемое в языках XSLT, XQuery и в разработке новой

версии DOM.

1.5 РАСШИРЯЕМОСТЬ XML-ПЛАТФОРМЫ

Принципиально важным свойством языка XML, обеспечивающим

новые функциональные возможности среды Web, является его

расширяемость. Достижение расширяемости языка XML обусловлено

двумя его особенностями.

1. Прежде всего, XML – это язык метауровня, входящий

в подмножество известного языка SGML, а не конкретный язык,

подобный HTML. Это позволяет XML выполнять функции языка опре-

деления данных. Используя его синтаксис, можно определять

различные типы элементов, экземпляры которых образуют содер-

жание конкретных XML-документов, и вводить тем самым адекват-

ный потребностям набор тегов разметки документов.

2. Вторая особенность языка XML связана с использованием

пространств имен – именованных множеств символов, используе-

мых в качестве имен типов элементов и атрибутов элементов XML-

документов. Введение пространств имен в XML-документы позволяет

неявным образом ассоциировать заданную семантику с введенными

именами элементов документов, их атрибутов и допустимыми для

них значениями.

Используя перечисленные особенности языка XML, отдельные

пользователи или сообщества пользователей могут создавать

нужные им языки разметки для различных категорий документов

21

с требуемой семантикой тегов разметки. При этом в одном XML-

документе допускается ссылка на разные пространства имен для

комбинации в нем различных порожденных XML языков.

Рассмотренные принципы обеспечивают также расширяемость

функциональных возможностей всей XML-платформы. Эта расши-

ряемость обеспечивается тем, что основа каждого дополняющего

XML стандарта, поддерживающего новые функциональные возмож-

ности, определяется средствами того же языка XML. При этом

вводится пространство имен с зарезервированным именем, вклю-

чающее имена новых типов элементов данного стандарта и их атри-

бутов. Семантика элементов этих типов, их атрибутов и значений,

которые они могут принимать, определяются в спецификациях

стандарта.

То обстоятельство, что для создания стандартов платформы XML

используется одно и то же средство, приводит к их синтаксической

однородности. Это позволяет рассматривать все стандарты XML-

платформы как приложения XML. Данное обстоятельство имеет

существенное значение, поскольку информационные ресурсы,

поддерживаемые различными стандартами (например, XML-, XSD-,

XSLT-, RDF-файлы), остаются XML-документами и могут обрабаты-

ваться в XML-среде как «чистые» XML-документы.

1.6 СФЕРЫ ПРИМЕНЕНИЯ СТАНДАРТОВ XML

Хотя язык XML и базирующаяся на нем платформа стандартов

W3C создавались как средство представления информационных

ресурсов Web, но они уже находят самое широкое применение прак-

тически во всех областях информационных технологий.

Этому способствуют, прежде всего, развитые возможности

платформы для представления информационных ресурсов широкого

спектра, а также ее адаптируемость (путем создания нового стан-

дарта с требуемой функциональностью) к условиям применения.

Определенное значение имеет также возможность метаописания

информационных ресурсов с нужной степенью формализованности

и открытый характер стандартов, позволяющие интегрировать

22

информационные ресурсы, представленные в XML-формате, в любую

среду.

Наконец, важную роль играют возможности XML, позволяющие

использовать его в качестве средства, обеспечивающего обмен XML-

сообщениями через Web. Эта возможность поддерживается

в глобальной коммуникационной среде Web и позволяет обеспечи-

вать взаимодействие систем различной природы.

Приведем несколько конкретных направлений использования

XML-платформы. В настоящее время создано и продолжает созда-

ваться большое количество версий языка XML для разметки доку-

ментов в различных предметных областях и создания XSD, исполь-

зуемых различными профессиональными сообществами. Известны,

в частности, версии XSD для применения в химии, географии, астро-

номии, истории, библиографии, издательском деле и др.

Очень важным направлением применения XML-платформы явля-

ются технологии баз данных, в которых XML используется в качестве

языка определения данных. Совмещение возможностей XML-

платформы и технологий баз данных позволяет создавать распреде-

ленные системы на основе существующих информационных баз.

В качестве примера использования XML-платформы в данном

направлении можно назвать планы применения XML для кодирования

сообщений, которыми обмениваются клиент и сервер в стандарте

ISO/IEC RDA/SQL (Remote Database Access for SQL) [19] удаленного доступа

к системам SQL баз данных.

В качестве примера конкретного применения XML-платформы

в области обмена данными через Web можно рассматривать разраба-

тываемый консорциумом Workflow Management Coalition (WfMC) стандарт

потоков работ [20], позволяющий осуществлять обмен сообщениями

на языке XML между программными средствами потоков работ для

поддержки их интероперабельности.

XML применяется также в системах документооборота, аналогич-

ных тем, которые основаны на стандарте SGML и уже много лет

используются на практике. Использование языка XML в этой сфере

позволяет интегрировать системы документооборота в среду Web.

23

Язык XML применяется также в стандартах других информацион-

ных технологий, где он используется как язык-посредник для

обмена информацией между различного рода системами с помощью

Web.

В качестве примеров можно назвать стандарты:

– XMI (XML Metadata Interchange) [21] обменного формата метаданных

для CASE, созданный консорциумом OMG;

– OIM (Open Information Model) [22, 23], разработанный консорциумом Meta Data Coalition;

– CWMI (Common Warehouse Metadata Interchange) [24], определяющий

формат представления метаданных и обмена метаданными для

хранилищ данных, созданный OMG.

Еще одно важное направление применения стандартов плат-

формы XML, актуальное для создания корпоративных информацион-

ных систем, интеграция неоднородных информационных ресурсов.

1.7 XML И ТЕХНОЛОГИИ БАЗ ДАННЫХ

Хотя о применения XML-платформы в технологиях баз данных

было уже упомянуто выше, но это настолько важная тема, что

требует отдельного рассмотрения. Целесообразность совместного

применения этих технологий обусловлена тем, что они представля-

ют альтернативные и взаимодополняющие технологии представле-

ния данных в разных областях: технологии баз данных, использую-

щие бинарное представление данных, применяются в сфере инфор-

мационно-расчетных задач, а XML-технологии – в коммуникаци-

онной сфере, так как текстовое представление данных является ин-

вариантным относительно информационных технологий, применяе-

мых в различных системах.

Тесная связь между Web-технологиями и технологиями баз

данных сложилась еще на ранних этапах развития Интернета. Она

сводилась к обеспечению удаленного доступа к системам баз

данных через среду Web. В настоящее время создано и функциони-

рует огромное количество приложений такого рода в самых различ-

ных областях деятельности. Но при этом не идет речь о настоящей

интеграции информационных ресурсов Web и баз данных. Доступ

24

к данным осуществляется с помощью так называемых расширений

Web-серверов, создаваемых программистами информационных

систем, а Web-сервер просто упаковывает эти данные в HTML-файлы

и передает по каналам связи. Система базы данных при этом не

внедрена в Web-среду и выступает по отношению к ней как «черный

ящик».

Стремление к обеспечению в Web полноценных возможностей

управления данными, поддерживаемыми в этой среде, объективно

привело к необходимости использования подходов и принципов,

аналогичных тем, которые на протяжении десятилетий прошли

испытание временем в технологиях баз данных. Действительно,

в стандартах Web-2 можно усмотреть целый ряд аналогий с идеями,

воплощенными в технологиях баз данных.

В лексиконе спецификаций стандартов платформы XML появи-

лись такие ключевые термины технологий баз данных, как модель

данных, схема, ограничение целостности. В части обеспечения огра-

ничения целостности в спецификации XSD появились конструкции

для определения элементов с уникальными значениями, первичных

и вторичных ключей.

Как и в технологиях баз данных в XML, с разработкой специфи-

кации XSD воплотилась концепция многоуровневого представления

данных, с помощью которой поддерживаются «логическое»

и «физическое» представление данных XML-документов.

Со временем взаимодействие этих направлений в информацион-

ных системах стало проявляться и на уровне развития практических

технологий в виде разработки систем баз данных XML. Некоторые

компании, выпустили для этих целей коммерческие программные

продукты, а другие адаптировали свои продукты для хранения XML-

данных. Такие системы следовало бы называть системами баз

данных XML-документов. Хранимые в таких базах данных документы

являются независимыми друг от друга, и никаких связей между

ними не поддерживается.

В качестве схемы базы данных при этом используется DTD доку-

ментов хранимых типов (для ранних версий) и описания XML-

документов средствами стандарта XML Schema (для поздних версий).

25

Некоторые исследователи видят аналогию между концептуаль-

ной схемой баз данных и спецификацией RDF.

Для доступа к XML-документам разрабатываются языки запросов,

как и в системах баз данных. Один из языков этого рода – XQL [25] –

используется в продукте Tamino компании Software AG. В имеющихся

проектах таких языков информационные ресурсы рассматриваются

как множества независимых XML-документов.

Совместными усилиями специалистов в области XML-технологий

и технологий баз данных ведутся работы по созданию стандарта

языка запросов XQuery [26-31] для XML-платформы. Этот проект имеет

такое же важное значение, как и разработка языка SQL в технологиях

баз данных. Его значение не только в обеспечении решения непо-

средственно в создании развитого языка запросов, но и будет иметь

весьма существенный эффект в виде средства декларативной обра-

ботки XML-данных.

Кроме этого анализ функциональных возможностей XQuery,

а также опубликованной W3C версии спецификаций создаваемого

языка запросов позволяет обнаружить, что данный язык обладает

функциональностью, которая выходит за узкие рамки потребностей

работы только с XML-ресурсами. Использование такого языка может

обеспечить возможности интеграции неоднородных информацион-

ных ресурсов, таких как XML-документы, данные иерархической

и реляционной структур.

Проблема интеграции неоднородных информационных ресурсов

решается и в рамках технологий реляционных баз данных, где также

предпринимаются попытки создания стандартных средств интегра-

ции SQL и XML-данных [32].

В рамках XML-платформы развиваются также процедурные сред-

ства обработки XML-данных. В качестве такого средства можно рас-

сматривать разработанный и развиваемый W3C стандарт Document

Object Model (DOM) объектной модели для XML-документов, на основе

которого можно создавать интерфейсы прикладного программиро-

вания для систем баз данных XML.

В части интеграции баз данных с XML-данными развивается еще

одно направление в технологиях баз данных. В рамках этого направ-

26

ления выполнен ряд исследований, связанных с отображением XML-

данных в реляционные [33, 34], объектно-реляционные [35]

и объектные базы данных [36]. Эти разработки имеют практическую

направленность, и их результаты вполне могут быть востребованы

практикой.

Таким образом, в перспективе можно ожидать, что под влиянием

дальнейшего развития XML-платформы будет осознана необходи-

мость в единой базовой полнофункциональной модели данных

платформы, основы которой и создаются в рамках проекта XQuery.

27

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Что представляет собой язык разметки?

2. Какими особенностями обладает язык разметки XML?

3. Перечислите причины широкого распространения языка XML.

4. Перечислите предпосылки создания новой технологической

платформы Web.

5. Опишите особенности ранних языков форматирования текста

– troff и TEX.

6. Какой организацией впервые были использованы описатель-

ные теги?

7. В какой фирме был создан обобщенный язык разметки GML?

8. Что собой представляет разметка?

9. Что собой представляет язык разметки и стандартный обоб-

щенный язык разметки SGML?

10. Когда и кем был разработан язык разметки гипертекста HTML?

11. Назовите недостатки языка HTML.

12. Перечислите основные стандарты, составляющие XML-

платформу.

13. В чем заключается общность стандартов XML-платформы?

28

ГЛАВА 2. XML – ЯЗЫК ОПИСАНИЯ ДАННЫХ

Язык XML был разработан рабочей группой XML Working Group кон-

сорциума World Wide Web Consortium (W3C) специально для размещения

информации в Web, аналогично языку гипертекстовой разметки

HTML (Hypertext Markup Language), который изначально стал стандартным

языком создания Web-страниц.

Ответ на вопрос «для чего понадобился еще один язык для Web»

был дан в предыдущей главе, а в данной и в последующих главах

более конкретно ответим на вопросы: «в чем состоят его преиму-

щества и достоинства», «как он взаимодействует с HTML». При этом

мы будем исходить из того обстоятельства, что основное его отли-

чие от HTML заключается в том, что XML – это текстовый формат,

предназначенный для обмена информацией между программами,

а также для создания на его основе более специализированных языков

разметки, иногда называемых словарями.

2.1 ОСНОВНЫЕ СВЕДЕНИЯ ОБ XML

Недостатки языка HTML, стандартного языка создания Web-

страниц, стимулировали исследования с целью разработки обоб-

щенной схемы кодирования, обеспечивающей более полный учет

структурных и содержательных особенностей документов. Решение

этой проблемы заключалось в объединении технологий Web и языка

разметки SGML, чтобы его можно было использовать в компактном

браузере.

29

В результате поисков и исследований в данном направлении

появился компактный расширяемый язык разметки XML, который

сохранил обобщенность SGML. Созданный язык разметки характери-

зуется следующими особенностями.

XML – это средство хранения и передачи данных, а также

создания других языков разметки. Являясь языком разметки XML:

– с одной стороны, предназначен для хранения и передачи

данных и является, прежде всего, транспортным средством для

передачи информации любого рода;

– с другой стороны, представляет собой набор правил для созда-

ния других языков разметки.

Примеры языков разметки, созданных на базе XML. Являясь

набором правил для создания других языков разметки, XML позво-

ляет хранить и упорядочивать информацию почти любого рода

в формате, приспособленном к потребностям пользователя.

Примером языка разметки, созданного с применением XML, является

язык математической разметки MathML, предназначенный для коди-

рования математических выражений. Уравнение Ньютона

� = ��/�2 для вычисления силы, действующей на тело массой �

на расстоянии � от Земли с массой � и с постоянной � на языке

MathML представляется следующим документом.

<?xml version="1.0" encoding="UTF-8"?>

<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.w3.org/1998/Math/MathML

http://www.altova.com/schemas/Math/mathml2.xsd">

<mml:mi>F</mml:mi>

<mml:mo>=</mml:mo>

<mml:mi>G</mml:mi>

<mml:mo>&InvisibleTimes</mml:mo>

<mml:mfrac>

<mml:mrow>

<mml:mi>M</mml:mi>

<mml:mo>&InvisibleTimes</mml:mo>

<mml:mi>m</mml:mi>

</mml:mrow>

30

<mml:apply>

<mml:power>

<mml:mi>r</mml:mi>

<mml:mn>2</mml:mn>

</mml:power>

</mml:apply>

</mml:mfrac>

</mml:math>

Приведенный XML-документ можно использовать по-разному:

– одно приложение может вывести эти данные для наглядного

вывода уравнения;

– другое – для того, чтобы решать его.

Другим примером языка разметки, созданного с помощью XML,

является язык масштабируемой векторной графики SVG – (Scalable

Vector Graphics). Ниже приведен пример документа на языке SVG,

в котором определен рисунок с тремя фигурами (прямоугольником,

окружностью и многоугольником):


<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"

"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-flat-20030114.dtd">

<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%">

<desc>Три фигуры</desc>

<rect fill="green" x="1cm" y="1cm" width="3cm" height="3cm"/>

<circle fill="red" cx="3cm" cy="2cm" r="4cm"/>

<polygon fill="blue" points="110, 160, 50, 300, 180, 290"/>

</svg>

В XML вы изобретаете свои собственные теги. А теперь рас-

смотрим небольшой пример XML-документа.


<Заметка>

<Кому>Петр</Кому>

<От>Федор</От>

<Заголовок>Напоминание</Заголовок>

<Сообщение>Не забудь позвонить мне в выходные!</Сообщение>

</Заметка>

31

В этом документе содержится:

– сообщение с заголовком внутри тегов <Заголовок> </Заголовок>

и текстом внутри тегов <Сообщение></Сообщение>;

– имя отправителя сообщения (Федор) внутри тегов <От></От>;

– имя адресата сообщения (Петр) внутри тегов <Кому></Кому>.

Из этих данных можно смело предположить, что в этом XML-

документе содержится заметка от Федора к Петру. И все вполне

понятно. Другими словами, XML-документ содержит данные с само-

описанием.

Чтобы закодировать информацию описанным образом, теги

в XML-документе (например, <Кому> и <От>) вводятся составителем

документа, которые при этом не ограничиваются никакими стандар-

тами XML. Эти теги были «изобретены» автором этого XML-

документа.

Если в HTML-документе можно использовать только те теги,

которые определяются в стандартах HTML (<p>, <li> и т. д.), то XML

позволяет автору определять свои теги и свою структуру документа,

т. е. в языке XML нет предопределенных тегов.

Пассивность XML-документа. Еще одна важная особенность

XML-документа заключается в том, что этот документ ничего не

делает. Он был создан для структурирования, хранения и передачи

информации. Это просто информация, обернутая в теги. Поэтому

требуется написать приложения, которые будут отсылать, получать

и отображать эти данные.

XML отделяет данные от HTML. В настоящее время XML также

важен для сети, как когда-то был важен HTML для рождения совре-

менного Интернета. XML – это общий инструмент передачи данных

между всеми видами приложений. Если вам в HTML-документе необ-

ходимо отображать динамические данные, то вести этот документ

будет слишком затратно, т. к. всякий раз, когда эти данные измени-

лись, приходится редактировать HTML-документ.

В стандарте языка XML-данные можно хранить в отдельных

файлах XML, а для отображения можно воспользоваться языками

HTML/ CSS или HTML/XSL. При этом вы можете быть уверены, что

32

поступающие в каждый раз новые данные не потребуют каких-либо

изменений в коде HTML-документа.

XML упрощает распределение данных. В глобальной сети

компьютерные системы и базы данных используют данные в несо-

вместимых бинарных форматах. Средствами XML данные создаются

и хранятся в простом текстовом формате. Это обеспечивает

программную и аппаратную независимость и позволяет легко созда-

вать данные, которые могут использоваться самыми разными

приложениями.

XML упрощает передачу данных. Одной из самых значимых

проблем разработчиков была и остается до сих пор проблема обмена

данными между несовместимыми гетерогенными системами.

Передача данных в виде XML значительно снижает сложность этой

проблемы, так как данные в этом формате могут быть прочитаны

в разных несовместимых системах.

XML упрощает модификацию платформы. Переход на новые

системы (аппаратные или программные платформы) всегда занимает

много времени. Множество данных необходимо конвертировать

в новые форматы. При этом часто несовместимые данные теряются.

Хранение данных в текстовом XML-формате значительно облег-

чает расширение или модернизацию систем, а также переход на

новые приложения или браузеры без опасности потерять данные.

2.2 ДОКУМЕНТ, КАК ЕДИНИЦА ИНФОРМАЦИИ XML

В XML информационную ценность представляют как содержание

документа, так и его разметка. Разметка позволяет программам

определять функции и границы частей документа. Содержание

(обычный текст) – это то, что важно для читателя, но оно должно

быть представлено осмысленным образом. XML помогает компьюте-

ру форматировать документ так, чтобы он был более понятен

не только человеку, но и обрабатывающим его программным

средствам.

Слово «документ» вызывает ассоциацию последовательности

слов, разбитых на параграфы, разделы и главы, образующие вместе

некоторую запись для чтения человеком, например, книгу, статью,

33

очерк. Но в XML документ представляет собой нечто большее: это

основная единица информации, составленная из элементов

и разметки в упорядоченном пакете.

Документ может содержать текст, например, рассказ или статью,

но этим его возможности не ограничиваются. Он может содержать

также базу данных с числами или некую абстрактную структуру,

представляющую молекулу или уравнение.

Одним из наиболее перспективных приложений XML является его

использование в качестве формата для обмена данными между при-

ложениями. Таким образом, определение документа XML может быть

значительно шире нашего традиционного понимания документа.

Документ состоит из частей, называемых элементами. Элементы

вкладываются друг в друга, определяя иерархическую структуру

и маркируя содержимое документа. На верхнем уровне находится

элемент, называемый элементом документа (document element) или

корневым элементом (root element), в котором содержатся все

остальные элементы.

Документ – не то же самое, что файл. Файл – это набор данных,

рассматриваемый операционной системой как единое целое, пред-

ставленное в памяти в виде физической структуры. Документ XML

определяет данные на логическом уровне и может располагаться

в одном или нескольких файлах, причем некоторые из них могут

находиться на разных машинах.

В XML используется специальная разметка для интеграции

содержимого разных файлов в один объект, который можно охарак-

теризовать как логическую структуру. Благодаря тому, что документ

не ограничен одним файлом, XML позволяет создавать документ из

частей, которые могут располагаться где угодно.

2.3 АНАЛИЗ СТРУКТУРЫ XML-ДОКУМЕНТА

Рассмотрим структуру XML-документа Inventory.xml, содержащего

сведения о каталоге книг и состоящего из двух основных частей:

пролога и элемента «Документ» (его также называют корневым

элементом).

34

Помимо этого, вслед за элементом «Документ» корректно сфор-

мированный XML-документ может содержать комментарии,

инструкции по обработке, а также пустые строки. В приведенном

примере XML-документа, после основного элемента «Документ»,

содержатся включения, которые вы можете добавлять в каждую из

частей.

2.3.1 ПРОЛОГ И ВКЛЮЧЕНИЯ

Первая строка в XML-документе, приведенном на Рис. 2.1, назы-

вается прологом. Пролог является необязательным и, как правило,

содержит номер версии XML. Кроме этого, он может содержать

информацию о кодировке XML-документа. В данном примере доку-

мента пролог состоит из следующих строк:


 <?xml-stylesheet type="text/css" “href=Inventory.css”?>

Первая строка представляет собой объявление XML, указывающее

на то, что это XML-документ, и содержащее номер версии.

(На момент создания курса последняя версия XML имела номер 1.0).

Объявление XML не является обязательным, хотя спецификация

требует его включения. Если вы включаете XML-объявление, оно

должно находиться в начале документа.

Номер версии в XML-объявлении в начале пролога документа

может быть заключен как в одинарные, так и в двойные кавычки.

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

включаемые непосредственно в текст документа, т.е. литералы.

XML-документы могут содержать символы в различных междуна-

родных кодировках. Символьная кодировка определяет уникальный

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

Юникод – это промышленный стандарт для символьной кодиров-

ки текстового документа и имеет две разновидности: UTF-8 и UTF-16:

– UTF-8 использует один байт (8 бит) для представления обще-

принятых символов и два (или три) байта для всех остальных симво-

лов. Является кодировкой по умолчанию в HTML-5, CSS, JavaScript, PHP,

SQL и XML и стандартной кодировкой символов в сети Интернет.

35

– UTF-16 использует два байта (16 бит) для большинства символов

и три байта для всего остального.

Чтобы не возникало ошибок, необходимо указывать, какая коди-

ровка используется в XML-документе, либо сохранять файл в универ-

сальной кодировке UTF-8. UTF-8 является кодировкой по умолчанию

для XML-документов без информации о кодировке.

Кроме этого, большинство систем приложений XML работает

с такими кодировками, как ISO-8859-1, Windows-1252 и ASCII.

Пролог может также содержать одну или несколько инструкций

по обработке. В нашем примере имеются две инструкции по

Рис. 2.1 Структура XML-файла Inventory.xml

36

обработке в прологе, а также инструкция по обработке в разделе,

следующем после элемента «Документ».

В данном примере XML-объявление включает в себя объявление

документа автономным (standalone=’yes’). Это объявление может

использоваться в некоторых XML-документах с целью упростить

обработку документа.

Вторая строка пролога представляет собой комментарий.

Добавление комментариев в XML-документ не обязательно, но

позволяет сделать его более понятным. Комментарий начинается

с символов . Между этими двумя

группами символов вы можете поместить любой текст (за исклю-

чением двойного тире --); XML-процессор проигнорирует его.

В рассматриваемом примере имеется комментарий в прологе,

а также другой комментарий, следующий за элементом «Документ».

В четвертой строке примера содержится инструкция, обеспечи-

вающая связывания XML-документа с каскадной таблицей стиля

Inventory01.css, содержащей информацию о порядке прохождения по

тексту документа при обработке приложения XSL-процессором.

Ниже, в Главе 4, мы более подробно ознакомимся с таблицами

стилей.

Примечание. XML-процессор – это программный модуль, считывающий

XML-документ и обеспечивающий доступ к его содержимому. Он также

предоставляет этот доступ другим программным модулям, или приложени-

ям, которые манипулируют и отображают содержимое документа.

Документ содержит две пустые строки в прологе и одну пустую

строку в разделе, следующем за элементом «Документ». Пустая

строка состоит из одного или нескольких пробелов, символа табуля-

ции, возврата каретки или перевода строки. Чтобы улучшить внеш-

ний вид и восприятие XML-документа, вы можете свободно добавлять

пробелы и переводы строк между элементами XML-разметки, а также

во многих случаях внутри элементов разметки (например, пробел

между "yes" и ? в конце XML-объявления в рассматриваемом примере).

Процессор просто игнорирует пропуски, если только они не

37

находятся внутри элемента, непосредственно содержащего символь-

ные данные.

2.3.2 ЭЛЕМЕНТЫ

Основное содержание документ определено во второй обяза-

тельной части, включающем в себя элемент «Документ», или корне-

вой элемент, который в свою очередь содержит дополнительные

элементы. Элемент «Документ» и вложенные в него элементы явля-

ются основным предметом рассмотрения в этом разделе учебного

пособия и содержат фактическую информацию, имеющуюся

в документе (для документа, приведенного на Рис. 2.1, это заглавия

книг, фамилии авторов и т. д.). Кроме этого система вложений

элементов документа отражает логическую структуру информации,

содержащейся в нем.

Элементы организованы в иерархическую древовидную струк-

туру, в которой одни элементы вложены в другие. Документ должен

иметь один и только один элемент верхнего уровня – элемент

«Документ», или корневой элемент – а все другие элементы

вложены в него. Представленный ниже XML-документ является

корректно сформированным.

В XML-документе элементы определяют его логическую струк-

туру и несут в себе информацию, содержащуюся в документе

(в нашем примере это информация о книгах, такая как заглавие,

автор, цена). Типовой элемент состоит из начального тега, содержи-

мого элемента и конечного тега. Содержимым элемента могут быть

символьные данные, другие (вложенные) элементы, либо сочетание

данных и вложенных элементов.

В данном примере элемент «Документ» – Inventory. Его начальный

тег – <Inventory>, а конечный – </Inventory>, а содержимым элемента

считается текст, расположенный между ними. В качестве содержи-

мого элемента можно использовать следующие типы сообщений:

– вложенные элементы – на Рис. 2.1 элемент Book вложен

в элемент Inventory, а элементы Book, в свою очередь, имеют в своем

содержимом вложенные элементы, как показано в нижеследующем

листинге:

38

<Book>

<Title> Приключения Гекльберри Финна </Title>

<Author>Марк Твен</Author>

<Binding>Бумажный переплет</Binding>

<Pages>298</Pages>

<Price>355р</Price>

</Book>

– символьные данные – это текст, выражающий информацион-

ное содержание элемента, например, заглавие определенной книги

в элементе title, как показано ниже:

<Title>Приключения Гекльберри Финна</Title>;

– разделы CDATA – это текстовый блок, в котором вы можете сво-

бодно размещать любые символы, за исключением строки ]]>. Раздел

CDATA используется для включения в текст элемента символов, ис-

пользуемых для разметки текста, т. е. недопустимых для использо-

вания в элементах внутри тегов. Пример раздела CDATA внутри эле-

мента, используемого для включения в текст элемента таких симво-

лов, показан в следующем примере:

<Text>Как ввести символы <![CDATA[<, >, ‘, “ и &]]></Text>

– инструкции по обработке содержат информацию, необходи-

мую для XML-приложений (см. нижеследующий пример);

– комментарии – это примечания к XML-документу, которые про-

читываются людьми, но игнорируются XML-процессором (см. ниже-

следующий пример).

<Book>

<?MyApp Parm1=”value1" Parm2=”value2"?>

<Title> Приключения Гекльберри Финна </Title>

<Author>Марк Твен</Author>



<Binding>Бумажный переплет</Binding>

<Pages>298</Pages>

<Price>355р</Price>

</Book>

Вы также можете помещать в ваш документ пустой элемент, т. е.

элемент, не имеющий содержимого. Пустой элемент создается

39

путем размещения конечного тега сразу же после начального тега:

<hr></hr>, либо вы можете использовать специальный тег пустого

элемента: <hr/>. Обе эти нотации являются эквивалентными.

Поскольку пустой элемент не имеет содержимого, у вас может

возникнуть вопрос о его предназначении. Здесь есть два варианта:

а) вы можете использовать пустой элемент, чтобы указать XML-

приложению выполнить действие или отобразить объект. Аналогом

в HTML является пустой элемент BR, который является указанием

браузеру вставить разрыв строки, а также пустой элемент HR, указы-

вающий на вставку горизонтальной разделительной линии. Другими

словами, само присутствие элемента с определенным именем – без

какого-либо содержимого – может послужить важной информацией

для приложения;

б) пустой элемент может нести информацию посредством атри-

бутов, о которых вы узнаете далее в этом пособии. (С элементами,

которые имеют атрибуты, вы еще не встречались). Аналогом в HTML

является пустой элемент IMG (изображение), содержащий атрибуты,

которые сообщают процессору, где искать графический файл и как

его отобразить.

Текст в XML-документе представляет собой перемежающиеся

символьные данные и данные, относящиеся к разметке. Разметка –

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

документа. А именно, начальный и конечный теги элемента, теги

пустого элемента, объявления типа документа, инструкции по обра-

ботке, ограничители раздела CDATA, символьные ссылки, ссылки на

примитивы (entity). Остальной текст представляет собой символьные

данные – реальное информационное содержимое документа

(в нашем примере это заглавия, фамилии авторов, цена и другая

информация о книге).

Примечание. Синтаксический анализатор XML сканирует символьные

данные элемента для XML-разметки. Вы не можете использовать левую угло-

вую скобку (<), амперсенд (&) или строку ]]> в составе символьных данных,

поскольку анализатор может интерпретировать (<) как начало вложенного

элемента, & как начало ссылки на примитив или символ, а ]]> как окончание

раздела CDATA. Если вы хотите использовать символы < или & как часть

40

символьных данных, вам необходимо воспользоваться разделом CDATA.

Вы также можете использовать любые символы (в том числе те, которых

нет на клавиатуре), воспользовавшись ссылкой на символ. Некоторые

символы (например, < или &) вы можете вставлять с использованием предо-

пределенных ссылок на общие примитивы.

2.3.3 АТРИБУТЫ ДЛЯ ЭЛЕМЕНТОВ

В начальный тег элемента либо в тег пустого элемента

вы можете включить одно или несколько описаний атрибутов.

Описание атрибута представляет собой пару имя – значение, связан-

ную с данным элементом. Например, следующий элемент price вклю-

чает атрибут с именем type, которому присвоено значение retail:

<price type="retail">$5.49</price>

Следующий пустой элемент включает атрибут с именем Source,

который указывает на имя файла, содержащего картинку, которую

следует отобразить:

<cover_image Source="Faun.gif" />

Задание атрибутов обеспечивает альтернативный способ вклю-

чения информации в элемент. Обычно вы помещаете все относя-

щиеся к элементу данные, которые хотите отобразить, внутри

содержимого элемента. Атрибуты же используются для хранения

различных характеристик элемента, которые не обязательно будут

отображены (например, категория, или указания по отображению).

В спецификации XML не установлено строгих разграничений относи-

тельно типа информации, которую можно описывать с помощью

атрибутов или внутри содержимого элемента.

Описание атрибута состоит из имени атрибута, вслед за которым

идет знак равенства и значение атрибута. Вы можете выбрать любое

имя атрибута, придерживаясь при этом следующих правил:

– имя должно начинаться с буквы или символа подчеркивания

‘_’, после чего могут следовать или не следовать другие буквы,

цифры, символы точки ‘.’, тире ‘–‘ или подчеркивания;

– спецификация XML оговаривает, что имена атрибутов, начи-

нающиеся с префикса «xml», «зарезервированы для стандартного

использования». Хотя для браузера это ограничение значения не

41

имеет, во избежание проблем в будущем лучше не использовать этот

префикс;

– каждое имя атрибута может только один раз присутствовать

в одном и том же начальном теге или в теге пустого элемента.

Примечание. В соответствии с XML-спецификацией двоеточие (:)

в имени атрибута зарезервировано для задания пространства имен.

Пространства имен дают возможность дифференцировать элементы

с одними и теми же именами. Internet Explorer разрешает вам использовать

двоеточие в имени атрибута только в том случае, если оно следует за про-

странством имен, объявленным вами в документе. Например, запись

A:Category будет корректной, только если вы объявили А как пространство

имен.

Значение, которое вы присваиваете атрибуту, представляет

собой группу символов, ограниченных кавычками, называемую

также литералом.

Вы можете присвоить атрибуту в качестве значения любой лите-

рал, придерживаясь при этом следующих правил:

– строка может находиться как в одинарных ('), так и в двойных

кавычках (");

– строка не может содержать внутри себя тот же символ кавы-

чек, которыми она ограничена;

– строка может содержать ссылку на символ или ссылку

на внутренние примитивы общего назначения;

– строка не может содержать символ (<). Синтаксический анали-

затор может воспринять этот символ как начало описания XML-

разметки;

– строка не может содержать символ (&), если это не ссылка на

символ или примитив.

Если вы создаете корректно сформированный документ, не

имеющий объявления типа документа, вы можете присвоить атри-

буту любое значение, соответствующее приведенным выше прави-

лам. Однако, если вы создаете описание типа документа и опреде-

ляете внутри него атрибуты, то можете ограничить типы значений,

которые могут быть присвоены конкретному атрибуту. Например,

вы можете определить атрибут, которому могут быть присвоены

42

только значения "yes" или "no". Таким образом, одно из преимуществ

задания определенного типа информации через атрибуты элементов

в отличие от задания через содержимое элемента заключается в том,

что при этом вы можете обеспечить контроль надо всеми типами

данных, которые могут быть присвоены атрибуту, и указываете

синтаксическому анализатору учитывать эти ограничения типов.

2.4 НЕКОТОРЫЕ БАЗОВЫЕ ПРАВИЛА XML

Форматированный XML-документ соответствует минимальному

набору правил, обеспечивающему возможность обработки доку-

мента браузером или другой программой. Эти правила специфика-

ции XML жестко трактуют все, что касается структуры. Они крайне

просты и логичны, их легко запомнить и легко использовать.

Документ должен иметь такую разметку, чтобы не существовало

двух способов интерпретации имен, порядка и иерархии элементов.

Это значительно уменьшает число ошибок и сложность кода.

Программы не должны ни о чем «догадываться» или пытаться

исправлять синтаксические ошибки, как это часто делают броузеры

HTML, так как различные процессоры XML должны давать одинаковые

результаты.

Документ, приведенный в разделе 2.3, является примером

форматированного XML-документа, удовлетворяющего этим прави-

лам. Ниже перечислены основные правила спецификации XML-

документа.

1. Документ должен иметь только один элемент верхнего уров-

ня. Все другие элементы должны быть вложены в этот элемент

верхнего уровня.

2. Каждый элемент ограничивается начальным и конечным

тегами. В отличие от HTML, в XML не разрешается опускать конечный

тег – даже в том случае, когда браузер в состоянии определить, где

заканчивается элемент. Например, в HTML некоторые элементы могут

не иметь закрывающего тега:

<p>Это параграф.<br>

В XML нельзя опускать закрывающий тег. Абсолютно все

элементы должны закрываться:

43

<p>Это параграф.</p> <br/>

В документе, приведенном в разделе 2.3, XML декларация не

имеет закрывающего тега. Это не ошибка. Дело в том, что деклара-

ция не относится к XML-документу, поэтому у нее и нет закрываю-

щего тега.

3. Имя типа элемента в начальном теге должно в точности соот-

ветствовать имени в соответствующем конечном теге.

4. Имена типов элементов чувствительны к регистру, в котором

они набраны. В действительности весь текст внутри XML-разметки

является чувствительным к регистру. Например, следующее описа-

ние элемента является неправильным, поскольку имя типа элемента

в начальном теге не соответствует имени типа в конечном теге:

<TITLE>Это заголовок</title>

5. Элементы должны быть вложены упорядоченно, т. е. в XML все

элементы обязаны соблюдать корректную вложенность:

<b><i>Это жирный и курсивный текст</i></b>

Понятие «корректная вложенность» по отношению к приведен-

ному примеру просто означает, что если элемент <i> открывается

внутри элемента <b>, то и закрываться он должен внутри этого же

элемента <b>.

6. В XML значения атрибутов должны заключаться в кавычки, как

показано в следующем примере


<Заметка date="12/11/2007">

<Кому>Петр</Кому>

<От>Федор</От>

</Заметка>

7. Синтаксис комментариев в XML такой же, как и в HTML.



8. В HTML несколько последовательных пробельных символов

усекаются до одного. В XML-документе все пробельные символы

сохраняются.

44

9. Если XML-документ составлен в соответствии с приведенными

синтаксическими правилами, то говорят, что это «синтаксически

верный» XML-документ.

45


1. Что представляет собой XML-документ?

2. Из каких разделов состоит XML-документ?

3. Какую информацию содержит декларация XML-документа?

4. Какая информация содержится в прологе XML-документа?

5. Как строятся элементы XML-документа?

6. Каковы синтаксические правила создания атрибутов XML-доку-

мента?

7. Для чего в XML-документах используются комментарии?

8. Что представляет собой Юникод, UTF-8 и UTF-16?

9. Опишите объявление документа standalone=’yes’ и объясните,

для чего оно используется в некоторых XML-документах.

10. Что означает понятие «корректная вложенность»?

11. Что означает чувствительность наименований тегов к реги-

стру?

12. Что собой представляют сущности XML-документа?

13. Чем анализируемые (парсируемые) данные отличаются от не

анализируемых данных?

14. Объясните, в чем заключается самоописуемость XML-доку-

ментов?

15. Что означает пассивность XML-документа?

16. Каким образом XML упрощает передачу данных?

17. Каким образом XML отделяет данные от HTML?

18. Каким образом XML упрощает распределение данных?

46

ГЛАВА 3. XSD – ЯЗЫК ОПИСАНИЯ СТРУКТУРЫ ДАННЫХ

Язык определения XML-схем, или XSD (XML Schema Definition), явля-

ется расширением XML и на сегодняшний день представляется

основным инструментом описания структуры XML-документов.

С использованием XML-схемы формализуется набор правил, с соблю-

дением которых составляется XML-документ конкретного назначения.

Базовый синтаксис XML определяет то, каким образом в тексте

должны выделяться элементы и их атрибуты, а также правила

описания структурных отношений между элементами.

XML Schema выполняет следующие функции:

1. Описывает названия элементов и атрибутов (словарь).

2. Описывает взаимосвязь между элементами и атрибутами,

а также их структуру (модель содержания).

3. Описывает типы данных.

XML-схема – это универсальный способ описания грамматики

данных, который может применяться не только для верификации

XML-документов, но и описания баз данных, структур данных,

используемых в языках программирования и т. д. На сегодняшний

день область применения XML Schema весьма обширна и со временем

она может стать основным стандартом моделирования данных, при

помощи которой можно описывать практически все.

47

3.1 DTD И XML-СХЕМЫ

На начальном этапе развития XML-технологий для целей модели-

рования документов использовалась спецификация Определений

Типа Документа (Document Type Definitions, DTD). Но в настоящее время

данная спецификация практически полностью вытеснена более

совершенным Языком описания XML Schema (XSD), поэтому в данном

учебном пособии мы приведем лишь краткое описание DTD.

3.1.1 ОПРЕДЕЛЕНИЕ DTD

DTD главным образом состоит из выражений языка разметки,

включающих элементы

<!ELEMENT …> и <!ATTRIBUTE …>.

В качестве тестового документа для описания с помощью

спецификации DTD выберем XML-документ, рассмотренный нами в

Главе 2 и приведенный на рис. 2.1.

Корневым элементом документа является элемент Inventory,

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

– указания включения поместите Book в круглые скобки;

– определения количества вложенных элементов поставьте знак

«ноль и более» (*) после Book. Если же требуется обязательное нали-

чие элемента Book, вы должны поставить знак «один или более» (+).

Для разрешения одного элемента вы ничего не должны ставить

после элемента Book. Перечисленные обозначения задания ограни-

чений на количество элементов представляют часть системы

обозначений в регулярных выражениях.

Итак, первая строка DTD выглядит следующим образом:

<!ELEMENT Inventory (Book*)>

Каждая книга содержит только по одному элементу Title, Author,

Binding, Pages и Price, причем именно в этом порядке (для целей дан-

ного руководства несколько авторов вводятся в один элемент Author).

Следовательно, следующим выражением языка разметки является:

<!ELEMENT Book (Title, Author, Binding, Pages, Price)>.

48

Оставшиеся элементы являются узлами-листьями, содержащими

символьные данные. Как обычно используются круглые скобки для

обозначения включения. Вы должны объявить тип символьных

данных. Символьные строки являются анализируемыми данными,

указываемыми литералом #PCDATA:

<!ELEMENT Title(#PCDATA)>

Вы можете предоставить каждой книге уникальный идентифи-

кационный ключ через специальный тип атрибута ID. Кроме того, вы

можете разрешить необязательный атрибут image, содержащий URL

изображения обложки книги. Метка ATTLIST принимает в качестве

аргумента элемент, за которым идет последовательность для

каждого атрибута, связанного с этим элементом. Каждая последова-

тельность состоит из имени атрибута, его типа и индикатора того,

является он обязательным или нет.

Спецификация DTD позволяет указывать 10 типов атрибутов,

перечисленных ниже:

PCDATA – любая символьная строка, приемлемая в XML;

NMTOKEN – близок к XML-имени;

NMTOKENS – маркеры NMTOKEN, разделенные пробелами;

Enumeration – список только допустимых значений для атрибута;

ENTITY – связывает имя с подстановкой, подобно макросу;

ENTITIES – разделенный пробелами список имен ENTITY;

ID – XML-имя, уникальное во всем документе;

IDREF – ссылка на атрибут ID внутри документа;

IDREFS – разделенный пробелами список маркеров IDREF;

NOTATION – связывает имя с информацией клиента.

Необходимый атрибут указывается путем добавления #REQUIRED

после типа. Вы можете указать необязательный аргумент путем

добавления #IMPLIED.

DTD описание содержит один атрибут каждого типа для элемента

Book. Единственное выражение ATTLIST выглядит так:

<!ATTLIST book id ID #REQUIRED image CDATA #IMPLIED>

Полностью описанный DTD рассматриваемого XML-документа

приведен ниже.

49


<!ELEMENT Inventory (Book*)>

<!ELEMENT Book (Title, Author, Binding, Pages, Price)>

<!ELEMENT Title(#PCDATA)>

<!ELEMENT Author(#PCDATA)>

<!ELEMENT Binding(#PCDATA)>

<!ELEMENT Pages(#PCDATA)>

<!ELEMENT Price (#PCDATA)>

<!ATTLIST Book id ID #REQUIRED image CDATA #IMPLIED>

3.1.2 XML SCHEMA КАК ЗАМЕНА DTD

В рассмотренной спецификации DTD отсутствует поддержка

типов данных XML-документа. Типы данных являются важным сред-

ством моделирования данных, так как они налагают необходимые

ограничения на структурные элементы описываемых данных.

Отсутствие поддержки типов данных в спецификации DTD сущест-

венно ограничивало использование XML-данных в языках програм-

мирования и СУБД.

Кроме ограничений на диапазон возможных значений система

типов определяет набор операций над данными, которыми разработ-

чики могут оперировать в своих программах. Сказанное можно

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

выражение «71+52 = ?». Если принять, что тип приведенных операн-

дов – числовой, то ответом является «123», но если их тип – строка,

то результатом может быть «7152», если под оператором «+» подразу-

мевается операция «конкатенации».

До разработки спецификации XSD язык XML представлял пример

языка, в котором отсутствовала система типов. В результате инфор-

мация, находящаяся в документе XML, могла интерпретироваться

только как текст. Но когда XML-данные начали использоваться в язы-

ках программирования и записываться в базах данных, то для их

взаимно обратного преобразования появилась необходимость знать

о «действительном типе» данных, чтобы осуществлять необходимые

приведения в коде программы или в базах данных.

Язык XML Schema (так часто называют спецификацию XSD) под-

держивает систему типов данных для информационных объектов,

50

моделируемых с помощью языка XML. Поэтому с появлением в арсе-

нале средств XML-платформы спецификации XSD язык XML стал таким

же средством моделирования данных, как и языки программирова-

ния высокого уровня и базы данных. Это позволяет описывать типы

данных XML-документа так же, как это делается в языках программи-

рования и языке SQL.

Это концептуально отличается от принципов работы DTD, так как

XML Schema предлагает мощные средства для взаимно обратного пре-

образования данных документа XML и переменных традиционных

языков программирования или систем типов баз данных. Этот

фактор превращает XML в мощное средство для обмена данными

между гетерогенными системами, в которых данные, как правило,

определяются в разных форматах и системах кодирования.

XML-документ и XML-схема соотносятся друг к другу так же, как

объекты и классы в объектно-ориентированных языках или записи

в базах данных и схемы баз данных. Поэтому с помощью языка XML

Schema можно выполнить проверку достоверности экземпляра доку-

мента, которую осуществляют XML-процессоры путем сопоставления

имен элементов, объявленных в схеме, с именами в данном экземп-

ляре документа. В случае совпадения имен для проверки достовер-

ности элемента используется информация о его типе и структуре,

объявленная в схеме.

3.1.3 ОПРЕДЕЛЕНИЕ XML SCHEMA

XML-схемы данных являются альтернативным способом созда-

ния правил построения XML-документов. По сравнению с DTD,

схемы обладают более мощными средствами для определения

сложных структур данных, обеспечивают более понятный способ

описания грамматики языка, способны легко модернизироваться

и расширяться.

На сегодняшний день язык определения XML-схем, или XSD, явля-

ется основным инструментом описания структуры XML-документов.

XML-схемы позволяют формализовать набор правил, с соблюдением

которых составляются XML-документы конкретного назначения.

51

Базовый синтаксис XML определяет то, каким образом в тексте

должны выделяться элементы и их атрибуты, а также правила

описания структурных отношений между элементами. Синтаксис

XSD декларирует то, какие именно элементы должны содержаться

в XML-документе, какой набор атрибутов должен или может иметь

каждый из них, и где их место в общей иерархии.

Поскольку основными объектами любого XML-документа явля-

ются элементы, их атрибуты и образованная ими иерархическая

структура, то вполне логично, что основные конструктивные

элементы синтаксиса XSD – это:

– определение элементов (element);

– их атрибутов (attribute);

– простой тип (simpleType), определяющий элементарные типы

данных;

– сложный тип (complexType), который описывает составные

элементы.

Элемент имеет простой тип (simpleType), если он не имеет атрибу-

тов, а его содержимое (данные между открывающим и закрываю-

щим тэгом) соответствует элементарному типу данных или просто

отсутствует. Для описания элемента простого типа достаточно опре-

делить его имя (атрибут name), а в качестве типа (атрибут type)

указать любой простой тип данных, например строковый (string).

Значения всех атрибутов соответствуют простым типам.

Все остальные элементы имеют сложный тип (complexType).

Сложный тип определяет сложное содержимое или простое содер-

жимое элемента. Сложное содержимое – это список атрибутов

и набор дочерних элементов. Простое содержимое – это также

список атрибутов и простой тип содержимого элемента.

Помимо всего прочего, XSD поддерживает наследование типов.

Например, можно описать новый сложный тип, набор атрибутов

и дочерних элементов которого расширяет (extension) сложное содер-

жимое базового типа. Можно, наоборот, ввести ограничения (restric-

tion) на значения атрибутов и элементов базового типа. Аналогично

можно накладывать ограничение на значения простых типов или

расширять их область допустимых значений.

52

В приведенном ниже примере демонстрируется, как можно

описать структуру данных XML-документа, описанного в разделе 2.1

и содержащего сведения о книгах некоторой библиотеки.


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="Inventory">

<xs:complexType>

<xs:sequence>

<xs:element ref="Book" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Book">

<xs:complexType>

<xs:sequence>

<xs:element ref="Title"/>

<xs:element ref="Author"/>

<xs:element ref="Binding"/>

<xs:element ref="Pages"/>

<xs:element ref="Price"/>

</xs:sequence>

<xs:attribute name="Exists" type="xs:integer"/>

</xs:complexType>

</xs:element>

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

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

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

<xs:element name="Pages" type="xs:short"/>

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

</xs:schema>

В соответствии с этим описанием элемент верхнего уровня Inven-

tory содержит неограниченное количество (maxOccurs="unbounded")

элементов Book.

В свою очередь элементы Book, являясь сложными элементами

(complexType), состоят из последовательностей (sequence) элементов

Title, Author, Binding, Pages и Price. Причем составитель типа sequence

53

определяет, что порядок следования элементов в XML-документе

должен соответствовать объявленному в XML-схеме.

Перечисленные элементы определены как простые (element),

относящиеся к встроенным типам (type) данных. В данном примере

для описания простых элементов использованы встроенные типы

string и short. Кроме простых элементов для элемента Book опреде-

лен атрибут Exists типа string, обозначающий наличие или отсутствие

книги.

3.2 КОМПОНЕНТЫ XML SCHEMA

Приведенный в предыдущем подразделе пример служит только

для демонстрации основной концепции XSD, согласно которой в XML-

схеме определяется структура данных XML-документа, представлен-

ная в виде системы иерархически вложенных элементов, а для

простых типов, составляющих нижние уровни вложенности, опре-

делены типы данных.

Но эта схема предназначена только для первоначального озна-

комления с принципами описания данных XML-документов, в ней не

представлены описания многих других инструментов XML-схем,

рассмотренных в данном разделе.

3.2.1 ТИПЫ ДАННЫХ XML SCHEMA

XML Schema предоставляет набор встроенных типов данных, кото-

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

Все эти типы помещены в пространство имен http://www.w3.org/2001/ XML

Schema. Каждый тип имеет определенную область значений. Область

значений типа – это просто ряд значений, которые могут использо-

ваться в экземпляре данного типа.

Встроенные типы языка описания схем XSD позволяют записы-

вать двоичные и десятичные целые числа, вещественные числа, дату

и время, строки символов, логические значения, адреса URI.

Их особенность заключается в том, что преобразование типов дан-

ных языка программирования или базы данных в типы данных XML,

а затем их преобразование в типы данных любого другого языка

программирования или базы данных, должно осуществляться без

54

потери информации. Именно это свойство определяет XML в качестве

средства обмена данными между гетерогенными системами.

3.2.1.1 В е щ е с т в е н н ы е ч и с л а

Вещественные числа в языке XSD разделены на три типа: decimal,

float и double.

Тип decimal составляют вещественные числа, записанные

с фиксированной точкой: 123.45, -0.1234567689345 и т. д. Фактически

хранятся два целых числа. Одно число представляет мантиссу,

другое – порядок вещественного числа. Спецификация языка XSD не

ограничивает количество цифр в мантиссе, но требует, чтобы можно

было записать не менее 18 цифр. При обработке документа средст-

вами технологии Java этот тип легко реализуется классом

java.math.BigDecimal, входящим в стандарт Java API.

Типы float и double соответствуют стандарту IEEE754-85 и одно-

именным типам Java. Они записываются с фиксированной или

с плавающей десятичной точкой. Например, 34.567, -45.67, 1е-5,

34.58е14.

3.2.1.2 Ц е л ы е ч и с л а

Основной целый тип integer понимается как подтип типа decimal,

содержащий числа с нулевым порядком. Это целые числа с любым

количеством десятичных цифр: -34567, 123456789012345 и т. д.

При использовании средств Java для обработки документа этот тип

легко реализуется классом Java.math.BigInteger.

Типы long, int, short и byte полностью соответствуют одноименным

типам Java. Они понимаются как подтипы типа integer, типы более

коротких чисел считаются подтипами более длинных чисел, напри-

мер тип byte – это подтип типа short, оба они подтипы типа int и т. д.

Значения типа byte, как следует из его названия, занимают один

байт и изменяются от -128 до 127. Тип short занимает два байта, его

значения лежат в диапазоне от -32768 до +32767. Числа типа int

хранятся в четырех байтах и меняются от -2147483648 до +2147483647.

Наконец, тип long располагается в восьми байтах, а его значения:

от -9223372036854775808 до +9223372036854775807.

55

Типы nonPositivelnteger и negativelnteger – подтипы типа integer –

составлены из неположительных и отрицательных чисел соответст-

венно с любым количеством цифр.

Типы nonNegativelnteger и positivelnteger – подтипы типа integer –

составлены из неотрицательных и положительных чисел соответст-

венно с любым количеством цифр. У типа nonNegativelnteger есть подмножество целых чисел без знака

unsignedLong, unsignedlnt, unsignedShort и unsignedByte.

3.2.1.3 С т р о к и си м во л о в

Основной символьный тип string описывает произвольную строку

символов Unicode. Его можно реализовать средствами Java, используя

класс Java.lang.String.

Тип normalizedString – подтип типа string – это строки, не содержа-

щие символов перевода строки '\n', возврата каретки '\г' и горизон-

тальной табуляции '\t'.

В строках типа token – подтипа типа normalizedString – нет еще

и начальных, и завершающих, пробелов и нескольких подряд

идущих пробелов.

В типе token выделены три подтипа. Подтип language определен

для записи названия языка согласно рекомендации RFC 1766,

например, ru, en, de, fr. Подтип nmtoken используется только в атрибу-

тах для записи их перечисляемых значений. Подтип name составляют

имена XML – последовательности букв, цифр, дефисов, точек, двое-

точий, знаков подчеркивания, начинающиеся с буквы (кроме

зарезервированной последовательности букв X, х, M, m, L, 1 в любом

сочетании регистров) или знака подчеркивания. Мы видели

в предыдущих главах, что имена, начинающиеся со строки xml,

используются самой спецификацией XML, например, имя атрибута

xmlns. Двоеточие в значениях типа name применяется для выделения

префикса в уточненных именах при использовании пространства

имен.

Из типа name выделен подтип NCName (Non-Colonized Name) имен, не

содержащих двоеточия, в котором, в свою очередь, определены три

56

подтипа: id, entity, idref – описывающие идентификаторы XML, сущно-

сти и перекрестные ссылки на идентификаторы.

3.2.1.4 Д а т а и в р ем я

Тип duration описывает промежуток времени. Запись P1Y2M3DT10-

H30M45S означает один год (1Y), два месяца (2м), три дня (3d), десять

часов (10H), тридцать минут (30M) и сорок пять секунд (45S). Запись

может быть сокращенной, например, Р120М означает 120 месяцев,

а Т120М – 120 минут.

Тип dateTime содержит дату и время в формате CCYY-MM-DDThh:

mm:ss, например, 2003-04-25Т09:30:05. Остальные типы выделяют ка-

кую-либо часть даты или времени:

time – содержит время в обычном формате hh:mm:ss;

data – содержит дату в формате ccyy-mm-dd;

gYearMonth – выделяет год и месяц в формате ccyy-mm;

gMonthDay – содержит месяц и день месяца в формате -mm-dd;

gYear – означает год в формате ccyy;

gMonth – месяц в формате -мм;

gDay – день месяца в формате -dd.

3.2.1.5 Д в о и ч ны е т и пы

Двоичные целые числа записываются либо в шестнадцатеричной

форме без всяких дополнительных символов: 0B2F, 356С0А и т. д., это

тип hexBinary, либо в кодировке Base64, это тип base64Binary.

3.2.1.6 П р о ч и е в с тр о е н н ы е пр о с т ы е т и п ы

Еще три встроенных простых типа описывают значения, часто

используемые в документах XML.

Адреса URI относятся к типу anyURI.

Расширенное имя тега или атрибута (qualified name), т. е. имя

вместе с префиксом, отделенным от имени двоеточием, – это тип

QName.

Обозначение notation описания DTD выделено как отдельный

простой тип схемы XML. Его используют для записи математических,

57

химических и других символов, нот, азбуки Бройля и прочих

обозначений.

Наиболее широко используемые типы данных ХМL-схемы пере-

числены в таблице 3.1.

Таблица 3.1. Основные типы данных в XML-схеме

Тип данных Описание

Числовые данные

Integer Целое число

PositiveInteger Положительное целое число

NegativeInteger Отрицательное целое число

NonPositiveInteger Нуль или отрицательное целое число

NonNegativeInteger Нуль или положительное целое число

Int 32-битовое целое число со знаком

UnsignedInt 32-битовое целое число без знака

Long 64-битовое целое число со знаком

UnsignedLong 64-битовое целое число без знака

Short 16-битовое целое число со знаком

UnsignedShort 16-битовое целое число без знака

Decimal Число, содержащее дробную часть

Float Число с плавающей запятой стандартной точности

Double Число с плавающей запятой двойной точности

Символьные данные

String Символьная строка переменной длины

NormalizedString Строка, в которой символы новой строки, возврата каретки

и табуляции заменены пробелами

Token Строка, в которой удалены начальные и конечные пробелы

и подряд идущие пробелы заменены одним пробелом

Окончание таблицы 3.1

58

Тип данных Описание

Дата и время

Time Время дня (часы/минуты/секунды/миллисекунды)

DateTime День и время (эквивалент SQL-типа TIMESTAMP)

Duration Длительность временного интервала

Date Год/месяц/день

Другие данные

Boolean Значение TRUE/FALSE

Byte Один байт данных со знаковым битом

UnsignedByte Один байт данных без знакового бита

base64Binary Двоичные данные по основанию 64

HexBinary Двоичные данные по основанию 16

AnyURI URI-адрес в Интернете, например, http://www.w3.org

Language Допустимый язык XML (английский, французский ...)

Типы данных XML-схемы спроектированы таким образом, что

они могут быть взаимно обратно преобразованы без искажений или

потери информации в соответствующие типы данных всех ныне

существующих языков программирования и баз данных.

Именно это обстоятельство является важнейшим качеством XML-

формата, позволяющим использовать его в качестве промежуточ-

ного формата при обмене данными между гетерогенными

системами.

До разработки системы типов данных XSD сложилась такая

ситуация, что разработчики каждого языка программирования

и системы управления базами данных создавали свои уникальные

механизмы для формирования, передачи и хранения данных, как

будто каждая очередная программная система решала многолетнюю

проблему абстрагирования данных раз и навсегда.

В результате для обеспечения взаимодействия приложений,

написанных на разных языках программирования, приходится фор-

матировать данные в соответствии с требованиями каждой из них

59

и дополнительно писать программы конвертации данных из одного

формата в другой.

При использовании XML-данных программисты могут прибегнуть

к богатому набору средств платформы XML, для унификации пред-

ставления данных путем выполнения их преобразований из различ-

ных форматов в XML и обратно. Разработчикам нужно определить

лишь отображение из приложения в XML, а после передачи по кана-

лам связи – из XML в другое приложение.

Например, тип данных int языков C++ и Java может отобразиться

в тип данных Integer языка XML для передачи по каналам связи.

На приемной стороне данные этого типа могут быть преобразованы

в тип данных Integer языка Pascal. Причем никакого искажения ин-

формации при этом каскаде преобразований не происходит.

С этой точки зрения язык XML представляет собой значительный

сдвиг в вопросе восприятия данных приложениями, особенно это

касается общих данных, совместно используемых программами

и приложениями различных типов. XML хранит все данные в виде

текста, как и положено языку разметки. Программы, обращающиеся

к XML, отображают эти данные в свое представление и обратно

в текстовое, используя сведения о связи типов, заданные в XML-

схеме.

В общем, XML Schema подготовлена для того, чтобы в будущем

играть центральную роль в обработке XML, особенно в Web сервисах,

в которых она служит одним из фундаментальных принципов,

на которых строятся высшие уровни абстракции.

3.2.2 ОПРЕДЕЛЕНИЕ ПРОСТЫХ ЭЛЕМЕНТОВ

XML-схемы определяют простые элементы XML-документа.

Простой элемент – это элемент XML, который содержит только текст.

Простой элемент не может содержать другие элементы или атрибуты.

Слова «только текст» требуют пояснения. Все данные в XML

записываются в виде текста, но текст может быть самых разных

типов. Это может быть одним из типов, включенных в определение

XML-схем (boolean, string, date и т. д.), либо это может быть пользова-

тельский тип, определенный вами.

60

Также, вы сами можете добавить ограничения (аспекты) по типу

данных, чтобы лимитировать контент, либо вы можете указать

требование, чтобы данные соответствовали определенной модели.

Для определения простого элемента используется синтаксис:

<xs:element name="xxx" type="yyy"/>,

где xxx – имя элемента, а yyy – тип данных элемента.

XML-схемы имеют множество встроенных типов данных.

Наиболее часто используемыми являются следующие типы: xs:string,

xs:decimal, xs:integer, xs:boolean, xs:date, xs:time.

Например, возьмем некоторые XML-элементы:

<lastname>Refsnes</lastname>

<age>36</age>

<dateborn>1970-03-27</dateborn>

А вот как будут выглядеть определения этих элементов в XML-

схеме:

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

<xs:element name="age" type="xs:integer"/>

<xs:element name="dateborn" type="xs:date"/>

Простые элементы могут иметь значения по умолчанию или

фиксированные значения. Значение по умолчанию присваивается

элементу автоматически, если не определено никакого другого

значения.

В следующем примере "red" – значение по умолчанию:

<xs:element name="color" type="xs:string" default="red"/>

Фиксированное значение также присваивается элементу автома-

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

В следующем примере "red" – фиксированное значение:

<xs:element name="color" type="xs:string" fixed="red"/>

3.2.3 ОПРЕДЕЛЕНИЕ АТРИБУТОВ

Все атрибуты декларируются как простые типы. Простые элементы не могут иметь атрибуты. Если у элемента есть атрибуты, то он относится к комплексным или составным типам. Но сам по себе атрибут всегда декларируется как простой тип.

61

Атрибут декларируется следующим образом:

<xs:attribute name="xxx" type="yyy"/>

где xxx – имя атрибута, а yyy – тип данных атрибута. Для описания атрибутов используются те же типы данных,

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

<lastname lang="EN">Smith</lastname>

Декларация этого атрибута в XML-схеме имеет вид

<xs:attribute name="lang" type="xs:string"/>

Атрибуты, как и элементы, могут иметь значения по умолчанию или фиксированные значения. Значение по умолчанию присваи-вается атрибуту автоматически, если не определено никакого друго-го значения. В следующем примере "EN" – значение по умолчанию:

<xs:attribute name="lang" type="xs:string" default="EN"/>

Фиксированное значение также присваивается атрибуту автома-тически, но при этом вы не можете определить никакого другого значения. В следующем примере "EN" – фиксированное значение:

<xs:attribute name="lang" type="xs:string" fixed="EN"/>

По умолчанию атрибуты являются необязательными для исполь-зования. Чтобы декларировать обязательный атрибут, следует воспользоваться атрибутом "use":

<xs:attribute name="lang" type="xs:string" use="required"/>

Если XML-элемент или атрибут имеет определение типа данных,

то это накладывает на них ограничение по контенту, и если XML-

элемент имеет тип "xs:date" и содержит строку, например, "Hello",

то этот элемент не пройдет проверку на корректность данных.

3.2.4 ОГРАНИЧЕНИЯ ИЛИ ФАСЕТЫ

При помощи XML-схем вы также можете добавлять свои собст-

венные ограничения для своих XML-элементов и атрибутов. Эти

ограничения еще называют аспектами, или фасетами.

Ограничения используются для того, чтобы определить прием-

лемые значения для XML-элементов или атрибутов. Ограничения по

XML-элементам еще называют «фасетами».

62

3.2.4.1 О г р а ни ч е н и я п о з н ач е н и ю

В следующем примере определяется элемент "age" для указания

возраста человека, а возраст человека, как известно, не может быть

меньше 0 и больше 150. Для указания этих ограничений следует

указать диапазон значений возрастов с помощью следующей

конструкции:




<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="age">

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="150"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

3.2.4.2 О г р а ни ч е н и е п о н аб о р у зн ач е н и й

Для ограничения содержимого XML-элемента набором прием-

лемых значений, следует использовать ограничитель enumeration.

В файле Ogranich_nabor_znach.xsd определяется элемент "car" с огра-

ничением. Его единственные приемлемые значения – Audi, Golf, BMW:






<xs:element name="car">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Audi"/>

<xs:enumeration value="Golf"/>

<xs:enumeration value="BMW"/>

</xs:restriction>

63

</xs:simpleType>

</element>

</schema>

На основе ограничений можно определить пользовательский тип

данных для более точного описания элементов (подробнее об опре-

делении пользовательских типов см. в подразделе 3.2.5):






<xs:simpleType name="carType"/>


<xs:enumeration value="Audi"/>

<xs:enumeration value="Golf"/>

<xs:enumeration value="BMW"/>

</xs:restriction>

</xs:simpleType>

<xs:element name="car" type="carType">

</ xs:schema>

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

3.2.4.3 О г р а ни ч е н и я п о с ер и и зн а че н и й

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

В файле Ogranich_serii_znach.xsd определяется элемент "letter" с огра-ничением. Его единственным допустимым значением может быть одна буква в нижнем регистре в диапазоне от "a" до "z":

 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="letter"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[a-z]"/>

64

</xs:restriction> </xs:simpleType> </element> </schema>

В файле Ogranich_initialsV.xsd определяется элемент "initials" с ограни-чением. Его единственным допустимым значением может быть три буквы в верхнем регистре в диапазоне от "A" до "Z":

 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="initials"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[A-Z][A-Z][A-Z]"/> </xs:restriction> </xs:simpleType> </element> </schema>

В файле Ogranich_initialsVN.xsd также определяется элемент "initials"

с ограничением. Его допустимым значением могут быть три буквы

в нижнем или верхнем регистре в диапазоне от "a" до "z":






<xs:element name="initials">

<xs:simpleType>


<xs:pattern value="[a-zA-Z][a-zA-Z][a-zA-Z]"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

65

В файле Ogranich_choise.xsd описан элемент "choice" с ограничением.

Допустимым значением этого элемента может быть одна буква из

трех: n, p или q:






<xs:element name="choice">

<xs:simpleType>


<xs:pattern value="[npq]"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

В файле Ogranich_prodid.xsd определяется элемент "prodid" с ограни-

чением. Его допустимым значением может быть пять последова-

тельных цифр, и каждая цифра должна быть в диапазоне от 0 до 9:






<xs:element name="prodid">

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

3.2.4.4 Д р у г и е о гр а нич е н и я по с е р ии з н а ч е ни й

В файле Ogranich_letter.xsd определяется элемент "letter" с ограниче-

нием. Его допустимым значением является ноль или больше букв

в нижнем регистре в диапазоне от a до z:

66






<xs:element name="letter">

<xs:simpleType>


<xs:pattern value="([a-z])*"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

В файле Ogranich_letterNV.xsd также определяется элемент "letter"

с ограничением. Его приемлемым значением будет одна или больше

пара букв, при этом каждая пара должна содержать букву в нижнем

регистре, за которой следует буква в верхнем регистре. Например,

"sToP" будет соответствовать данному шаблону, а "Stop" или "stop" нет:






<xs:element name="letter">

<xs:simpleType>


<xs:pattern value="([a-z][A-Z])+"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

В файле Ogranich_gender.xsd определяется элемент "gender". Его

приемлемым значением будет только строка "male" или "female":






<xs:element name="gender">

67

<xs:simpleType>


<xs:pattern value="male|female"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

В файле Ogranich_password.xsd определяется элемент "password"

с ограничением. Его значением должна быть строка из 8 символов,

и этими символами могут быть буквы в нижнем или верхнем реги-

стре от a до z, либо цифры от 0 до 9:






<xs:element name="password">

<xs:simpleType>


<xs:pattern value="[a-zA-Z0-9]{8}"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

3.2.4.5 О г р а ни ч е н и я п о пр о б е ль н ы м с и м в о л ам

Чтобы определить, как будут восприниматься пробельные

символы, используется ограничитель whiteSpace.

В файле Ogranich_preserve.xsd определяется элемент "address" с огра-

ничением. Ограничитель whiteSpace установлен в значение "preserve",

что указывает XML-парсеру не удалять никакие пробельные символы:






<xs:element name="address">

<xs:simpleType>

68


<xs:whiteSpace value="preserve"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

В файле Ogranich_replace.xsd также определяется элемент "address"

с ограничением. Если ограничитель whiteSpace установлен в значение

"replace", то XML-парсер заменяет все пробельные символы (символы

табуляции, пробела, конца строки и перевода каретки) символами

пробела:







<xs:simpleType>


<xs:whiteSpace value="replace"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

В файле Ogranich_collapse.xsd также определяется элемент "address"

с ограничением. Ограничитель whiteSpace имеет значение "collapse", что

указывает XML-парсеру удалить все пробельные символы (символы

табуляции, пробела, конца строки и перевода каретки и конечного

пробела удаляются, а множественные пробелы заменяются одинар-

ными символами пробела):







<xs:simpleType>


69

<xs:whiteSpace value="collapse"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

3.2.4.6 О г р а ни ч е н и я п о д л и н е

Чтобы ограничить длину значения элемента, следует использо-

вать ограничители length, maxLength и minLength.

В файле Ogranich_password_length.xsd определяется элемент "password"

с ограничением. Длина его значения должна быть точно 8 символов:







<xs:simpleType>


<xs:length value="8"/>

</xs:restriction>

</xs:simpleType>

</element>

</schema>

В файле Ogranich_password_minMax.xsd определяется другой элемент

"password" с ограничением. Длина его значения должна быть минимум

5 и максимум 8 символов:







<xs:simpleType>


<xs:minLength value="5"/>

<xs:maxLength value="8"/>

</xs:restriction>

</xs:simpleType>

70

</element>

</schema>

Большинство из этих ограничители неприменимы ко всем

типам, а некоторые имеют смысл только для определенных типов.

Всего в спецификации XML Schema предусмотрено 15 фасетов,

которые используются при определении данных:

xs:fractionDigits – определяет максимальное количество десятичных

знаков справа от десятичной точки;

xs:length – определяет количество символов в строковом типе,

количество байтов в двоичном типе или количество элементов в

списочном типе;

xs:maxExclusive – определяет исключающую верхнюю границу

области значений типа;

xs:minExclusive – определяет исключающую нижнюю границу


xs:maxInclusive – определяет включающую верхнюю границу


xs:minInclusive – определяет включающую нижнюю границу


xs:maxLength – определяет максимальное количество символов

в строковом типе, максимальное количество байтов в двоичном типе

или максимальное количество элементов в списочном типе;

xs:minLength – определяет минимальное количество символов

в строковом типе, минимальное количество байтов в двоичном типе

или минимальное количество элементов в списочном типе;

xs:totalDigits – определяет максимальное количество десятичных

знаков для типов, унаследованных от number;

xs:pattern – определяет шаблон, основанный на регулярном выра-

жении, с которым должен совпадать тип;

xs:enumeration – определяет фиксированное значение, с которым

должен совпадать тип;

xs:whiteSpace – определяет правила нормирования пробелов.

Фасеты pattern и enumeration очень удобны с точки зрения пред-

ставления лексических значений. Элемент pattern определяет

71

регулярное выражение, с которым должно сопоставляться прове-

ряемое значение.

Например, на элемент Группа может быть наложено ограничение,

чтобы его значение состояло из четырех прописных символов,

за которыми следуют один строчный символ знак «-» и две цифры

в диапазоне от 1 до 6 (например, БЭВМд-41, МЭВМд-52). Это требование

на языке XSD можно представить с помощью следующего шаблона:

<xs:pattern value="[А-Я]{4}[а-я]{1}-[1-6]{2}"/>

Элемент enumeration позволяет ограничить простой тип набором

различимых значений. Например, на элемент Статус, содержащий

данные о статусе студента, можно наложить ограничение, согласно

которому он может иметь только значения Бакалавр, Специалист или

Магистр. Такое требование можно представить в схеме с помощью

следующего перечисления enumeration:

<xs:enumeration value="Бакалавр"/>

<xs:enumeration value="Специалист"/>

<xs:enumeration value="Магистр"/>

3.2.5 ОПРЕДЕЛЕНИЕ ПРОСТЫХ ПОЛЬЗОВАТЕЛЬСКИХ ТИПОВ

Большинство языков программирования позволяет разработчи-

кам только компоновать различные встроенные типы в структуриро-

ванные типы и не дает возможность определять новые простые

типы, имеющие определенные пользователем области значений.

Возможности определения данных через встроенные типы есть

и в XML. Например, элементы Фамилия, Имя, Отчество и датаРождения

можно представить следующим образом:

<xs:element name="Фамилия" type="xs:string"/>

<xs:element name="Имя" type="xs:string"/>

<xs:element name="Отчество" type="xs:string"/>

<xs:element name="датаРождения" type="xs:date"/>

Но XML Schema, кроме встроенных типов данных, позволяет поль-

зователям определять собственные простые типы, области значений

которых являются подмножествами встроенных типов.

Другими словами, пользовательский тип данных определяется

как ограничение, накладываемое на другой тип данных XML.

72

Аналогичные возможности дают современные СУБД, позволяющие

вводить пользовательские типы данных путем определения доменов.

Механизм ввода пользовательского типа в XML Schema включает

в себя следующие действия.

1. Для определения нового простого типа используется элемент

xs:simpleType.

2. В элементе xs:simpleType определяется базовый тип (xs:string), чья

область значений ограничивается с помощью элемента xs:restriction.

3. В элементе xs:restriction вы определяете, как именно вы хотите

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

(facets). Варианты ограничений базового типа данных приведены

в нижеследующих пунктах.

3.2.5.1 П о л ь зо в а т е льс к и е т и пы с о г р а н ич е н и ем

д и а п а зо но в

Например, следующие простые типы ограничивают области зна-

чений xs:double и xs:date до более узких диапазонов, используя аспекты

xs: minInclusive и xs:maxInclusive:





xmlns:x="http://example.org/publishing"

targetNamespace="http://example.org/publishing" elementFormDefault="qualified"

attributeFormDefault="unqualified">



<xs:simpleType name="RoyalityRate">

<xs:restriction base="xs:float">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="100"/>

</xs:restriction>

</xs:simpleType>



<xs:simpleType name="Pubs2003">

<xs:restriction base="xs:date">

73

<xs:minInclusive value="2003-01-01"/>

<xs:maxInclusive value="2003-12-31"/>

</xs:restriction>

</xs:simpleType>



<xs:element name="rate" type="x:RoyalityRate"/>

<xs:element name="publicationDate" type="x:Pubs2003"/>

</xs:schema>

После определения простых типов RoyaltyRate и Pubs2003 в послед-

них строках XML-схемы определены переменные rate и publicationDate

для типов x:RoyalityRate, x:Pubs2003.

Следующие документы содержат корректные экземпляры опре-

деленных выше документов:



<x:rate xmlns:x="http://example.org/publishing">17.34567890</x:rate>



<x:publicationDate xmlns:x="http://example.org/publishing">

2003-06-01

</x:publicationDate>

3.2.5.2 П о л ь зо в а т е льс к и е т и пы с ле к с и ч е ск и м и

о гр а н ич е н и ям и

Большинство аспектов ограничивают область значений типа,

в то время как шаблонный аспект ограничивает лексическую

область типа. Предыдущие примеры ограничивали область значений

базового типа, а приведенные далее - ограничивают лексическую

область строки с помощью регулярных выражений:






targetNamespace="http://example.org/publishing"


<xs:simpleType name="SSN">


<xs:pattern value="\d{3}-\d{2}-\d{4}"/>

74

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="PublisherAssigned">


<xs:pattern value="\d{2}-\d{8}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Phone">



</xs:restriction>

</xs:simpleType>

<xs:element name="authorId" type="tns:SSN"/>

<xs:element name="pubsAuId" type="tns:PublisherAssigned"/>

<xs:element name="phone" type="tns:Phone"/>

</xs:schema>

Следующие документы содержат корректные экземпляры опре-

деленных выше пользовательских типов данных:




<x:authorId xmlns:x="http://example.org/publishing">

123-45-6789

</x:authorId>




<x:pubsAuId xmlns:x="http://example.org/publishing">

01-23456789

</x:pubsAuId>




<x:phone xmlns:x="http://example.org/publishing">

(801)390-45-52

</x:phone>

75

3.2.5.3 П о л ь зо в а т е льс к и е т и пы н а о с но в е с п и ск о в и о б ъ ед и н е ний д р у г их т и по в

Кроме ограничения области значений типа, можно создать новые простые типы, являющиеся списками или объединениями других простых типов. Для этого вы используете не xs:restriction, а элементы xs:list или xs:union. Таким образом, для создания простых типов вы можете использовать следующие конструкции XML-схемы:

xs:restriction – новый тип является ограничением существующего типа, т. е. он имеет более узкий ряд допустимых значений;

xs:list – новый тип является разделенным пробелами списком другого простого типа;

xs:union – новый тип является объединением двух или более других простых типов.

Используя xs:list, вы, по существу, определяете разделенный пробелами список значений из определенной области значений. При использовании xs:list или xs:union нет иерархии наследования, как при использовании xs:restriction, поэтому в этих случаях не выполняется совместимость типов. В следующем примере новый тип AuthorList определяется как список SSN значений.

 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:x="http://example.org/publishing" targetNamespace="http://example.org/publishing" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:simpleType name="SSN"> <xs:restriction base="xs:string"> <xs:pattern value="\d{3}-\d{2}-\d{4}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="AuthorList"> <xs:list itemType="tns:SSN"> </xs:simpleType> <xs:element name="authors" type="tns:AuthorList"/>

Следующий документ содержит экземпляр элемента authors:

76

 <?xml version="1.0" encoding="UTF-8"?> <x:authors xmlns:x="http://example.org/publishing"> 111-11-1111 222-22-2222 333-33-3333 444-44-4444 </x:authors>

В случае использования xs:union вы создаете новый тип, комби-нирующий множество областей значений, в которой значением может быть из любой из указанных областей значений. Например, следующий тип AuthorId сочетает область значений SSN с областью значений PublisherAssignedId:

 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:x="http://example.org/publishing" targetNamespace="http://example.org/publishing" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:simpleType name="SSN"> <xs:restriction base="xs:string"> <xs:pattern value="\d{3}-\d{2}-\d{4}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="PublisherAssigned"> <xs:restriction base="xs:string"> <xs:pattern value="\d{2}-\d{8}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="AuthorId"> <xs:union memberTypes="tns:SSN tns:PublisherAssigned"/> </xs:simpleType> <xs:element name="author" type="tns:AuthorId"/> </xs:schema>

Каждый из следующих документов демонстрирует корректный экземпляр элемента authorId:

 <?xml version="1.0" encoding="UTF-8"?>

<x:author xmlns:x="http://example.org/publishing"> 111-11-1111 </x:authorId>

77




<x:author xmlns:x="http://example.org/publishing">

11-11111111

</x:authorId>

Поддержка XML Schema для определенных пользователем типов

и, в частности, «специальных значений»/«лексических областей»

является одним из наиболее мощных аспектов языка. Тот факт, что

большинство языков программирования не обеспечивает этого,

вынуждает разработчиков решать эти вопросы в коде своих прило-

жений самостоятельно (обычно через механизмы уста-

новки свойств). Способность определять «специальные значе-

ния»/«лексические области», удовлетворяющие вашим точным

потребностям, делает возможным осуществлять проверку правиль-

ности и обработку ошибок данных не в программном коде,

а на уровне XML-процессора.

3.2.6 ОПРЕДЕЛЕНИЕ СОСТАВНЫХ ТИПОВ

XML Schema делает возможным компоновать различные простые

типы в структуру, известную как составной тип (complexType).

3.2.6.1 П р о с т о й п р и м е р со с т а в но го э л е м е н т а

Чтобы определить новый составной тип в целевом пространстве

имен схемы, вы используете элемент xs:complexType, как показано

в листинге:

<xs:complexType name="AuthorType">



</xs:complexType>

Элемент xs:complexType содержит то, что известно как составитель,

который описывает формирование содержимого типа, также извест-

ного как модель содержимого. XML Schema определяет трех составите-

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

xs:sequence – упорядоченная последовательность частей;

xs:all – все части в любом порядке;

xs:choice – выбор содержащихся частей.

78

Составители содержат части, которые включают такие объекты,

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

Описания атрибутов не считаются частями, потому что они не

повторяются. Следовательно, описания атрибутов помещаются не

в составителе, а после него в конце определения составного типа.

Описание элемента (xs:element), возможно, наиболее часто

используемая часть. Следующий complexType, названный AuthorType,

определяет упорядоченную последовательность двух дочерних

элементов и атрибута, имеющих простые типы:






targetNamespace="http://example.org/publishing">




<xs:sequence>

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

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

</xs:sequence>



<xs:attribute name="id" type="xs:integer"/>

</xs:complexType>



<xs:element name="author" type="x:AuthorType"/>

</xs:schema>

3.2.6.2 Б о л е е с л о жн ы й п р им ер с о с та в н о г о э л ем е нт а

А теперь приведем немного более сложный пример составного

типа, который использует вложенные составные типы, другие соста-

вители и повторяющиеся части:




<xs:schema

xmlns:xs="http://www.w3.org/2001/XMLSchema"


79





<xs:simpleType name="SSN">



</xs:restriction>

</xs:simpleType>



<xs:complexType name="Address">

<xs:all>

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

<xs:element name="city" type="xs:string" minOccurs="0"/>

<xs:element name="state" type="xs:string" minOccurs="0"/>

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

</xs:all>

</xs:complexType>



<xs:complexType name="PublicationListType">

<xs:choice maxOccurs="unbounded">

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

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

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

</xs:choice>

</xs:complexType>



<xs:simpleType name="Phone">



</xs:restriction>

</xs:simpleType>




<xs:sequence>

<xs:choice>


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

80

</xs:choice>

<xs:element name="address" type="x:Address"/>

<xs:element name="phone" type="x:Phone" minOccurs="0" maxOccurs="5"/>

<xs:element name="recentPublications" type="x:PublicationListType"/>

</xs:sequence>

<xs:attribute name="id" type="x:SSN"/>

</xs:complexType>


/xs:schema>

В этом примере составитель all в определении Address означает,

что порядок следования элементов в экземпляре XML-документа

может быть произвольным.

В описании элемента AuthorType содержится составитель типа

sequence, включающий в себя другой составитель типа choice, за кото-

рым следуют описания трех элементов.

Составитель choice в этом определении означает, что в элементе

типа AuthorType допускается появление элементов name или fullName. В качестве типов элементов, следующих за составителем choice,

выбраны пользовательские составные типы: AddressType, Phone

и PublicationsListType.

3.2.6.3 О г р а ни ч е н и я к о л ич е с т в а э ле м е н т о в

Обратите также внимание, что с помощью атрибутов minOccurs

и maxOccurs описание элемента phone определяет ограничения появле-

ний (occurrence constraints). В составном типе ограничения появлений

могут применяться к любой части.

Стандартное значение для каждой части – 1, это означает, что

данная часть должна появиться в указанном месте именно один раз.

Определение minOccurs="0" делает данную часть необязательной,

а определение maxOccurs="unbounded" позволяет бесконечные повторе-

ния части. Если пожелаете, вы можете задать также произвольные

границы, например, minOccurs="3" maxOccurs="77".

Использование ограничений появлений по отношению к соста-

вителю применяется ко всей группе как к целому (обратите внима-

ние на PublicationsListType, который применяет ограничения появлений

81

к выбору). Здесь приведен пример корректного экземпляра нашего

нового AuthorType:




<x:author xmlns:x="http://example.org/publishing"

xsi:schemaLocation="http://example.org/publishing ComplexElm_userType.xsd"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

id="000-00-0000" >

<x:name>Петров Петр</x:name>

<x:address>

<x:street>ул. Мира, д. 1, кв. 5</x:street>

<x:city>Инза</x:city>

<x:state>Ульяновская</x:state>

<x:zip>432031</x:zip>

</x:address>

<x:phone>617-123-4567</x:phone>

<x:phone>801-321-7654</x:phone>

<x:phone>987-095-7643</x:phone>

<x:recentPublications>

<x:book>Основы XML-технологий</x:book>

<x:book>Программирование XML-данных</x:book>

<x:book>Автоматизированное проектирование БД</x:book>

<x:book>Основы Web-сервисов</x:book>

</x:recentPublications>

</x:author>

3.2.6.4 О г р а ни ч е н и я , и с п о л ьз у е м ы е д л я

п р и в ед е н и я XM L - сх ем ы к р е л я ц и о н но й м о д е л и

В предыдущих разделах рассматривались примеры применения

фасетов для проверки допустимости данных, применяемых в доку-

менте XML. В спецификации XML Schema предусмотрены также сред-

ства определения ограничений, копирующих конструкции реляци-

онной модели. К таким ограничениям относятся ограничения уни-

кальности и соответствующих ссылочных ограничений, которые

должны соблюдаться в определенном диапазоне значений данных,

основанных на использовании средств XPath. Рассмотрим ограниче-

ния двух типов: ограничения уникальности и ограничения по ключу.

82

Ограничения уникальности. Для определения ограничения

уникальности должен быть задан элемент unique, определяющий

элементы или атрибуты, которые должны быть уникальными.

Например, можно определить ограничение уникальности по иден-

тификатору отдела (элемент id_otd, вложенный в комплексный тип

Otdel) и табельному номеру сотрудника (элемент tab_nom, вложенный

в комплексный тип Sotrudnik) с помощью следующей конструкции:

<unique name="uniqueIdOtd">

<selector xpath="Otdel"/>

<field xpath="id_otd"/>

</unique>

<unique name="uniqueTabNom">

<selector xpath="otd:Sotrudnik"/>

<field xpath="tab_nom"/>

</unique>

Местонахождение уникального элемента в схеме позволяет

определить контекстный узел, на который распространяется такое

ограничение. В данном случае дескриптор, задающий ограничение,

следует за элементами Otdel и Sotrudnik; тем самым указано, что соот-

ветствующие ограничения должны быть уникальными только в кон-

тексте элементов Otdel и Sotrudnik, т. е. в пределах данной XML-схемы.

Это аналогично определению ограничения на отношении в реляци-

онной СУБД.

Выражения XPath, заданные в двух элементах данного определе-

ния, являются относительными к контекстному узлу. Первое выра-

жение XPath с элементом selector задает элемент, на который распро-

страняется ограничение уникальности (в данном случае это элемен-

ты Otdel и Sotrudnik), а следующие за ними элементы field указывают

узлы id_otd и tab_nom, которые должны проверяться на уникальность.

Ограничения по ключу. Ограничение по ключу определяет, что

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

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

показаны ограничения OtdelPK и SotrudnikPK по ключу, заданные на тех

же узлах, а именно, id_otd и tab_nom:

83

<key name="OtdelPK">

<selector xpath="."/>

<field xpath="id_otd"/>

</key>

<key name="SotrudnikPK">

<selector xpath="."/>

<field xpath="tab_nom"/>

</key>

Еще один тип ограничения позволяет задавать ссылки значе-

ниями указанных ключей. Например, если объект Sotrudnik требуется

связать с объектом Otdel, то для этого необходимо определить

элемент, скажем, SotrudnikFK, значения которого должны быть огра-

ничены значениями ключа OtdelPK. Этот тип ограничения задается

следующим образом:

<xs:keyref name="SotrudnikFK" refer="OtdelPK">

<xs:selector xpath="Sotrudnik"/>

<xs:field xpath="id_otd"/>

</xs:keyref>

3.2.7 ПРОСТРАНСТВА ИМЕН

Достоинство использования XML заключается в возможности

придумывания собственных тегов, названия которых наиболее

полно соответствуют их предназначению. С одной стороны, это

обеспечивает создание легко читаемых XML-документов, с другой

стороны, нет никакой гарантии того, что данные вами имена

элементов и атрибутов не будут использованы кем-то еще.

До тех пор пока в вашем приложении обрабатываются только

собственные XML-документы, никаких проблем не возникнет. Но при

использовании сторонних XML-документов названия некоторых

элементов и атрибутов могут совпасть с вашими, имеющими другой

смысл, а это может вызвать ошибку в XML-анализаторе.

Чтобы исправить эту ситуацию, мы должны иметь возможность

гарантировать уникальность названий элементов и их атрибутов,

«дописывая» к их именам некоторый уникальный префикс, опреде-

ляемый в рамках пространств имен.

84

3.2.7.1 М е х а ни зм N ame s p a c e s

Для введения пространств имен применяется механизм Name-

spaces. В соответствии с этим механизмом для определения «области

действия» тега необходимо описать уникальный атрибут xmlns,

задающий префикс, дописываемый к названию элемента, по кото-

рому анализатор может определить, к какой группе имен он отно-

сится.

В соответствии с этим соглашением:

– имя элемента без префикса пространства имен называется

неквалифицированным, и это имя может быть использовано только

в локальной схеме;

– имя элемента, включающее префикс пространства имен, назы-

вается квалифицированным.

В качестве наименования пространства имен рекомендовано

использовать URL. Но это вовсе не значит, что описание пространст-

ва имен находится по данному адресу. Данный сайт может вообще

не существовать и никаких обращений по данному адресу не будет.

Использование URL рекомендовано лишь для того, чтобы обеспечить

уникальность именования пространства имен. Поэтому в отношении

пространства имен необходимо иметь в виду, что:

– строка в определении пространства имен является только

строкой. Эти строки выглядят как URL, но ими не являются. Вы мо-

жете определить xmlns:addr=”mike”, и это также будет работать;

– только одно важно относительно строки пространства имен:

она должна быть уникальной. Вот почему большинство пространств

имен выглядят как URL;

– XML-анализатор не обращается по URL-адресу, чтобы найти

схему, он просто использует этот текст как строку.

Операция определения пространства имен выполняется с помо-

щью следующей конструкции:

xmlns:[префикс]="[URI (название) пространства имен]",

где xmlns: – зарезервированный атрибут.

85

Префикс может состоять из любых символов, разрешенных

в тегах XML, если только они не начинаются с комбинации символов

«xml» (такие строки запрещены).

3.2.7.2 О б ъ я в л ен и е пр о с тр а н с тв а им е н

Любая схема использует стандартное пространство имен, объяв-

ляемое с помощью следующей конструкции


elementFormDefault="qualified" attributeFormDefault="unqualified">.

По соглашению это пространство имен использует префикс "xs"

или "xsd". Целевое пространство имен пока не введено.

В этой декларации фрагмент:

xmlns:xs="http://www.w3.org/2001/XMLSchema" – указывает на то, что

используемые в схеме элементы и типы данных относятся к про-

странству имен "http://www.w3.org/2001/XMLSchema". Также здесь указыва-

ется, что элементы и типы данных, относящиеся к этому простран-

ству имен, должны иметь префикс xs;

elementFormDefault="qualified" – указывает на то, что любой элемент,

используемый в XML-документе, который был декларирован в этой

схеме, должен быть уточнен по пространству имен;

attributeFormDefault="unqualified" – указывает на то, что любой атри-

бут, используемый в XML-документе, который был декларирован

в этой схеме, является неквалифицированным и отображается без

префикса.

В описанной конструкции объявлено только стандартное про-

странство имен, но не содержится объявление пространства имен

структуры данных, определяемой в данной схеме. При создании

схем для их использования в распределенной системе такой способ

объявления пространства имен может привести к конфликтам имен,

когда одни и те же имена могут быть присвоены разным объектам.

Элементы в XML-документах, созданных на основе схем без

целевых пространств имен, определяются без префиксов. Если

данный документ будет использоваться совместно с другими доку-

ментами, также определенными без целевого пространства имен, то

это может привести к совпадению имен. Например, имя name может

86

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

совершенно разные объекты (имена людей, отделов, устройств

и т. д.).

Для исключения подобных ситуаций сделаем еще один шаг

в эволюции схемы, добавив в элемент <schema> целевое пространство

имен (например, http://npomars.com/xml с префиксом otd). Синтаксис

определения целевого пространства имеет вид

xmlns:otd=”http://npomars.com/xml” targetNamespace=”http://npomars.com/xml”.

В данном определении указываются два атрибута xmlns для:

– целевого пространства имен (xmlns:otd);

– пространства имен по умолчанию (в качестве такового примем

стандартное пространство имен http://www.w3.org/2001/XMLSchema, убрав

из его атрибута xmlns префикс xs).

После этого декларация корневого элемента схемы имеет вид

<?xml version="1.0"?>

<schema xmlns="http://www.w3.org/2001/XMLSchema"

xmlns:otd="http://npomars.com/xml" targetNamespace=http://npomars.com/xml


В этом объявлении дополненные элементы пространства имен

имеют следующее назначение:

– targetNamespace="http://npomars.com/xml" – указывает на то, что опре-

деляемые этой схемой элементы (Otdely, Otdel, Sotrudnik и т. д.) относят-

ся к целевому пространству имен http://npomars.com/xml;

– xmlns:otd="http://npomars.com/xml" – задает префикс для тех элемен-

тов, которые определяются в целевом пространстве имен http://npo-

mars.com/xml.

3.2.7.3 П р о с т р а н с тв а и м е н : с т ан д ар т н о е , ц е л е во е , п о у м о л ч а ни ю и д л я X M L S ch e ma i n s t a n c e

В предыдущем пункте были рассмотрены несколько видов про-

странств имен:

– стандартное пространство имен, определяемое со стандартным

префиксом xs (xsd). Этот префикс используется в качестве псевдонима

пространства имен для XML Schema, так как он также является XML-

документом. Зарезервированным наименованием этого пространства

87

имен является URL-адрес xmlns="http://www.w3.org/2001/XMLSchema". Это

стандартное пространство имен и в него нельзя добавлять собст-

венные имена;

– каждый анализатор «знает» это пространство имен и «понима-

ет» имена из этого пространства. Его можно сделать пространством

по умолчанию и тогда префикс xs (xsd) не нужен. Для этого нужно

объявить атрибут xmlns без префикса. Этим определяется простран-

ство имен по умолчанию для текущего элемента и всех элементов-

потомков, которые не имеют префикса;

– в таких случаях надо установить пространство имен для опре-

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

ния введено понятие целевого пространства имен (target namespace).

Идентификатор целевого пространства имен определяется атрибу-

том targetNamespace, например:

targetNamespace="http://some.com".

Имена, определяемые в этой схеме, будут относиться к новому

пространству имен с идентификатором http://some.com.

В схемах и документах XML часто применяется еще одно стан-

дартное пространство имен. Использование этого пространства имен

связано с тем, что в соответствии со спецификацией языка XSD опре-

деляется несколько атрибутов (type, nil, schemaLocation, noNamespaceSche-

maLocation), которые применяются не только в схемах, но и в XML-

документах, построенных на базе этих схем и называемых их экзем-

плярами (XML schema instance). Эти имена относятся к пространству

имен экземпляров XML-схемы http://www.w3.org/2001/XMLSchema-instance,

которому приписывают префикс xsi, например:

<xs:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

В нижеприведенном листинге приведен пример использования пространства имен по умолчанию и целевого пространства имен в одной схеме. Пространство имен по умолчанию вводится для упрощения записи ключевых слов XMLSchema (при этом ключевые слова пишутся без префиксов, например, element, а не xs:element, complexType, а не xs:complexType). Для определяемых в схеме типов и элементов введено целевое пространство имен

88

targetNamespace=”http://some.com

xmlns:ntb= ”http://some.com. При этом имена, относящиеся к данному целевому простран-

ству, снабжаются префиксом ntb, чтобы они не попали в простран-ство имен по умолчанию.

 <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace=”http://some.com" xmlns:ntb=”http://some.com"> <element name="notebook"> <complexType> <sequence> <element name="name" type="string"/> <element name="address" type="string"/> </sequence> <attribute name="send" default="yes"/> </complexType> </element> </schema>

Составим по этой XML-схеме XML-документ

 <?xml version="1.0" encoding="UTF-8"?> <ntb:notebook send="yes" xsi:schemaLocation="http://some.com Prim_NS.xsd" xmlns:ntb="http://some.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <name>Петров</name> <address>г. Москва, ул. Мира, д. 2, кв. 15</address> </ntb:notebook>

3.2.7.4 Я в н о е о пр ед ел е н и е к в а л иф и к а ц и й

э л е м е н т о в и ат р и б у то в со с та в н о г о э л ем е нт а

В приведенном в предыдущем пункте XML-документе можно

увидеть, что в целевое пространство имен попадают только глобаль-

ные имена, чьи описания непосредственно вложены в элемент

89

<schema>. Это естественно, потому что только глобальными именами

можно воспользоваться далее в этой или другой схеме.

Тут возникает интересный вопрос: а должно ли указываться про-

странство имен для локальных элементов/атрибутов в экземплярах

документа? Поскольку локальные элементы и атрибуты определены

внутри родительского элемента (обычно глобального), для которого

указано целевое пространство имен, то для локальных элементов

в экземплярах документа оно необязательно.

Аналогичная ситуация имеет место в большинстве языков про-

граммирования – если вы определяете класс в пространстве имен,

пространством имен определяется только имя класса, а не его

локальные члены. Поэтому и в XML Schema для локальных элементов

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

сделано в предыдущем примере.

Но в XML Schema префиксы можно определять и для локальных

имен, если в соответствии с принятым соглашением указать, что

локальные элементы и атрибуты должны быть квалифицированны-

ми. Квалификация локальных элементов и атрибутов определяется

с помощью атрибутов elementFormDefault и attributeFormDefault элемента

schema. Значение каждого из этих атрибутов может быть установлено

в unqualified или в qualified, что указывает на признак квалифицируемо-

сти локально объявленных элементов и атрибутов.

В соответствии с общепринятым соглашением локальные эле-

менты объявляются квалифицированными, а локальные атрибуты –

не квалифицированными. Пример XML-схемы с описанными призна-

ками квалификации приведен в листинге



<?xml version=’1.0’?>


targetNamespace=”http://some.com”

xmlns:ntb=http://some.com


<element name="notebook">

<complexType>

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

</complexType>

</element>

</schema>

Если по этой XML-схеме составить XML-документ, то он может

иметь следующий вид:




<ntb:notebook send="yes"

xsi:schemaLocation="http://some.com Prim_NS.xsd"

xmlns:ntb="http://some.com"


<ntb:name>Петров</ntb:name>

<ntb:address>г. Москва, ул. Мира, д. 2, кв. 15</ntb:address>

</ntb:notebook>

В данном XML-документе в целевое пространство имен попадают

как глобальные, так и локальные имена, чьи описания непосредст-

венно вложены как в корневой элемент <schema>, так и в составные

элементы.

Далее определим XML-схему, в которой и атрибуты определены

с префиксами. Для этого в соответствии с уже упомянутым согла-

шением атрибут attributeFormDefault необходимо установить в qualified.

Пример XML-схемы, согласно которой как локальные элементы, так

и локальные атрибуты объявляются квалифицированными, приведен

в следующем листинге



<?xml version=’1.0’?>


targetNamespace=”http://some.com”

xmlns:ntb=http://some.com

elementFormDefault="qualified" attributeFormDefault="qualified">

<element name="notebook">

. . . .. . . . . . . . . . . . .

</element>

</schema>

91

Если по этой XML-схеме составить XML-документ, то он может

иметь следующий вид:




<ntb:notebook ntb:send="yes"

xsi:schemaLocation="http://some.com Prim_NS.xsd"

xmlns:ntb="http://some.com"


<ntb:name>Петров</ntb:name>

<ntb:address>г. Москва, ул. Мира, д. 2, кв. 15</ntb:address>

</ntb:notebook>

3.2.7.5 О п р ед е л е н и е э л е м е н т о в и ат р и б у то в

с о с т а в но го э ле м е н т а к ак г ло б а ль н ы х

Вы также можете определить элементы/атрибуты составного

типа в качестве глобальных, объявив их непосредственно в корне-

вом элементе schema, и обращаться к их описаниям из составного

типа, используя атрибут ref.

Создадим XML-схему с неквалифицированнми элементами:







elementFormDefault="unqualified" attributeFormDefault="qualified">



<xs:attribute name="id" type="xs:integer"/>





<xs:sequence>



<xs:element ref="x:name"/>



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

</xs:sequence>

92



<xs:attribute ref="x:id"/>

</xs:complexType>


</xs:schema>

Поскольку id и name – глобальные элементы, они всегда должны

содержать пространство имен в экземплярах документа. Использо-

вание "ref" устанавливает, что глобальный элемент также может

использоваться в контексте AuthorType, но это не меняет того факта,

что он должен содержать пространство имен.

В рассмотренной схеме элемент name был определен как

глобальный, но элемент phone все еще определен локально. Это озна-

чает, что префикс элемента phone можно указывать, а можно и не

указывать в экземпляре, в зависимости от используемой формы.

Поэтому если мы хотим отличить локальный элемент от

глобального, т. е. отображать его без префикса, мы должны устано-

вить для атрибута elementFormDefault значение "unqualified" (атрибут

attributeFormDefault имеет значение "qualified"), как показано в предыду-

щем листинге.

В этом случае корректный экземпляр этой схемы может выгля-

деть следующим образом:



<x:author xmlns:x="http://example.org/publishing" x:id="123456">

<x:name>Петров</x:name>

<phone>(495)390-45-78</phone>

</x:author>

3.2.8 СВЯЗЫВАНИЕ XML-ДОКУМЕНТА С XML-СХЕМОЙ

Мы неоднократно говорили, что XML-схема используется для

контроля достоверности XML-документа. Возникает вопрос, каким

образом при обработке XML-документа определяется описание его

схемы? С этой целью XML Schema определяет способ предоставления

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

с помощью атрибута xsi:schemaLocation, как показано ниже:

<x:author xmlns:x="http://example.org/publishing"

93

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://example.org/publishing pubs.xsd"/>

Атрибут xsi:schemaLocation определяет пары названия пространства

имен и URI схемы, разделенных пробелами. По этим данным опреде-

ляется местонахождение файла схемы для данного XML-документа.

3.3 СОЗДАНИЕ XML-СХЕМЫ

В данном разделе рассмотрим процесс создания XML-схемы.

При этом будем иметь в виду, что XML-формат как средство интегри-

рования систем предназначен для временного хранения структури-

рованных данных в качестве универсального формата для обмена

информацией как между компонентами одной системы, так и между

компонентами систем, реализованных на произвольных платформах.

В связи с этим при определении структуры XML-документа мы

должны исходить из того, что она должна соответствовать структуре

базы данных, служащей источником и/или приемником данных,

передаваемых по каналам связи.

Поэтому прежде чем приступить к разработке структуры XML-

документа, предварительно определим схему базы данных Firma,

составленной из двух таблиц Otdel и Sotrudnik, которую будем исполь-

зовать для хранения данных. Для передачи по каналам связи инфор-

мация базы данных Firma должна быть преобразована в XML-формат,

а затем обратно в формат базы данных на приемной стороне.

Для выполнения описанных манипуляций с данными базы Firma

необходимо определить XML-схему, в точности совпадающую по

своей структуре со схемой базы данных Firma.

3.3.1 ОПИСАНИЕ БАЗЫ ДАННЫХ FIRMA

В таблице Otdel базы данных Firma хранятся сведения о подразде-

лениях организации, включая его идентификатор id_otd, наименова-

ние name и подчиненность vlozh. В таблице Sotrudnik хранятся сведения

сотрудниках, работающих в этих подразделениях, включая табель-

ный номер tab_nom, фамилию family, имя name и код отдела id_otd,

в котором работает данный сотрудник.

94

Далее определим пер-вичные ключи: id_otd для таблицы Otdel и tab_ nom для таблицы Sotrudnik. Связи типа «предок-потомок» между записями таблиц Otdel и Sotrudnik определим с помо-щью вторичного ключа id_otd

(FK), созданного на основе поля id_otd таблицы Sotrudnik.

Описанная схема базы данных Firma приведена на Рис. 3.1. Далее определим первичные ключи: id_otd для таблицы Otdel

и tab_ nom для таблицы Sotrudnik. Связи типа «предок-потомок» между записями таблиц Otdel и Sotrudnik определим с помощью вторичного ключа id_otd (FK), созданного на основе поля id_otd таблицы Sotrudnik. Описанная схема базы данных Firma приведена на Рис. 3.1.

В следующем листинге приведены скрипты для создания таблиц схемы базы данных Firma.

Скрипты для создания таблиц схемы базы данных Firma

CREATE TABLE "Firma"."Otdel" ( id_otd integer NOT NULL, "name" character varying(10), vlozh integer, CONSTRAINT "Otdel_pkey" PRIMARY KEY (id_otd) )

CREATE TABLE "Firma"."Sotrudnik" ( tab_nom integer NOT NULL, "family" character varying(15), name character varying(10), id_otd integer, CONSTRAINT "Sotrudnik_pkey" PRIMARY KEY (tab_nom) )

ALTER TABLE "Firma"."Sotrudnik" ADD CONSTRAINT "$1" FOREIGN KEY (id_otd) REFERENCES "Firma"."Otdel" (id_otd) MATCH SIMPLE

Наша задача заключается в реализации структуры данных пред-метной области Firma средствами XML-схемы, содержащей перечис-ленные атрибуты и ключи сущностей Otdel и Sotrudnik, а также опи-санную связь между ними.

Это позволяет:

Рис. 3.1 Схема базы данных Firma

95

– записать информацию из базы данных Firma в виде XML-

документа, удовлетворяющего созданной схеме на передающей

стороне;

– записать данные XML-документа, соответствующего этой XML-

схеме, в базу данных Firma на приемной стороне.

Средствами XML-схемы можно создавать композиционные

и агрегированные схемы. Рассмотрим механизмы создания этих ва-

риантов схем данных и оценим их достоинства и недостатки с точки

зрения решения поставленной задачи.

3.3.2 СОЗДАНИЕ КОМПОЗИЦИОННОЙ XML-СХЕМЫ

Изначально композиционные схемы были единственным вари-

антом определения структур данных по спецификации XML Schema.

Поэтому рассмотрение возможностей построения схем данных как

средства определения правил построения XML-документов с помо-

щью XML-схемы начнем именно с этого варианта.

3.3.2.1 О б ъ я в л ен и е XM L - сх ем ы и пр о с тр а н с тв а

и м е н

Первое, что нужно сделать при определении XML-схемы, – это

объявить схему. Для этого определяется пролог и корневой элемент

XML Schema:




. . . . . . . . . . . . .

</xs:schema>.

Обратите внимание на то, что в открывающем теге корневого

элемента определяются атрибуты механизма namespace: xmlns,

elementFormDefault, attributeFormDefault, описанные нами в подразделе 3.2.7.

С учетом изложенного объявление корневого элемента объекта

Firma определяется следующим образом:




96

<xs:element name="Firma">

<xs:annotation>

<xs:documentation>

Отделы и сотрудники КНИО-2

</xs:documentation>

</xs:annotation> <xs:complexType> . . . </xs:complexType> </xs:element> </xs:schema>.

3.3.2.2 О п р ед е л е н и е с о с т а в а с ло ж но го э л е м е н т а

Далее в корневом элементе сложного типа определим последо-

вательность вложенных элементов, которые могут быть как

простыми, так и сложными. В нашем случае в элемент Firma должно

быть вложено два сложных типа Otdel и Sotrudnik, как показано ниже.



elementFormDefault="unqualified" attributeFormDefault="unqualified">


<xs:annotation>

<xs:documentation>

Отделы и сотрудники КНИО-2

</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="Otdel"/>

<xs:element name="Sotrudnik"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

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

97

ний элементов. Для элемента Otdel – это id_otd, name_otd и vlozh, а для элемента Sotrudnik – tab_nom, family, name и id_otd. Перечисленные элементы на нижеследующем листинге определены как простые элементы с указанием имен и базовых типов.

Описываемая схема имеет следующие особенности. 1. Для элемента vlozh, указывающего на подчиненность отдела,

необходимо определить фасет minOccurs="0", т. е. как необязательный, т. к. элемент верхнего уровня не имеет вложений и в нем элемент vlozh может отсутствовать.

2. Для элемента Sotrudnik введем еще и атрибут na_rabote, отра-жающий факт присутствия сотрудника подразделения на работе. Определим перечень допустимых значений этого атрибута "yes", "no", означающих присутствие или отсутствие сотрудника на работе, соответственно.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="Firma"> <xs:annotation> <xs:documentation>Отделы и сотрудники КНИО-2</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Otdel" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="id_otd" type="xs:integer"/> <xs:element name="name_otd" type="xs:string"/> <xs:element name="vlozh" type="xs:integer" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Sotrudnik" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="tab_nom" type="xs:integer"/> <xs:element name="family" type="xs:string"/> <xs:element name="name" type="xs:string"/>

98

<xs:element name="id_otd" type="xs:integer"/> </xs:sequence>

<xs:attribute name="na_rabote"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> </xs:attribute>

</xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

Обратите внимание на то, что атрибут maxOccurs для обоих элементов имеет значение unbounded. Это означает, что каждый из этих элементов в экземплярах XML-документа может иметь неог-раниченное число вхождений. Атрибуты minOccurs для обоих элемен-тов не указаны, а это означает, что в данной схеме используются их значения по умолчанию (minOccurs=1).

3.3.2.3 X M L -д о к ум е нт с х е м ы и е го п р о в ер к а н а с с ы л о ч н у ю ц е л о с т но с т ь

По созданной XML-схеме может быть построен XML-файл с дан-ными, фрагмент которого приведен в следующем листинге:

<otd:Firma xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=http://npomars.com/xml Firma_NS.xsd elementFormDefault="qualified" attributeFormDefault="unqualified"> <otd:Otdel> <otd:id_otd>1</otd:id_otd> <otd:name_otd>КНИО-2</otd:name_otd> <otd:vlozh>0</otd:vlozh> </otd:Otdel> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<otd:Sotrudnik na_rabote="no">

<otd:tab_nom>8</otd:tab_nom>

99

<otd:Family>Нилов</otd:Family>

<otd:name>Алексей</otd:name>

<otd:god_rozhd>1985</otd:god_rozhd>

<otd:id_otd>5</otd:id_otd>

</otd:Sotrudnik>

</otd:Firma>

В приведенном XML-документе содержатся конструкции, опреде-

ляющие пространство имен и связи с XML-схемой. В корневом

элементе XML-документа определен префикс otd пространства имен

путем ввода строки xmlns:otd="http://npomars.com/xml". После этого,

например, вместо имени <Otdel> пишется <otd:Otdel>, что явно

указывает на принадлежность этого имени пространству имен

http://npomars.com/xml.

Способ связи XML-документа с его схемой был описан в подраз-

деле 3.2.8 настоящего учебного пособия. В соответствии с этим опи-

санием в XML-документе ссылка на схему содержится в корневом

элементе XML-документа. При этом в корневом элементе Firma XML-

документа текст xsi:noNamespaceSchemaLocation="Firma_NS.xsd"

заменяем текстом xsi:schemaLocation="http://npomars.com/xml Firma_NS.xsd".

Здесь обратите внимание на пару значений в кавычках. Первый

компонент – это URI пространства имен, а второй – месторасположе-

ние файла схемы, который в общем случае представляется URL.

В нашем случае документ и его схема размещены в одном каталоге,

поэтому URL схемы в рамках относительной адресации представлен

просто именем ее файла.

Если данные, содержащиеся в этом XML-документе, предполага-

ется записать в базу данных Firma, то они должны соответствовать

ограничениям ссылочной целостности. Эти ограничения связаны

с определениями первичных и вторичных ключей базы данных

и описываются следующим образом.

1. Значения поля id_otd таблицы Otdel и поля tab_nom таблицы

Sotrudnik должны быть уникальными.

100

2. Значения поля id_otd таблицы Sotrudnik должны быть выбраны из

множества значений поля id_otd таблицы Otdel.

Если мы в соответствующие элементы XML-документа введем

значения, не удовлетворяющие этим требованиям, то проверка на

корректность этого документа пройдет успешно. Это говорит о том,

что XML-документы, созданные на базе композиционных схем,

не соответствуют требованиям ограничений ссылочной целостности

и не могут быть использованы для обмена данными, содержащимися

в реляционных базах.

3.3.3 СОЗДАНИЕ АГРЕГИРОВАННОЙ СХЕМЫ

XML-схема, описанная выше, называемая композиционной,

характеризуется тем, что составные части и целевая схема создаются

одним разработчиком и предназначены исключительно для исполь-

зования в данной схеме. Поэтому на способы соединения частей

схемы при этом никакие ограничения не накладываются.

На значения элементов связанных частей также не накладывается

ограничений. Например, данная схема допускает ввод в поле

Sotrudnik/id_otd документа XML значения, не соответствующего ни одно-

му значению Otdel/id_otd. Это приводит к тому, что сотрудник оказыва-

ется работающим в несуществующем отделе, а в данные XML-

документа введена смысловая ошибка.

Отсутствие ограничений на значения не позволяет строить

с помощью композиционных схем структур, адекватных реляцион-

ным структурам, используемым в подавляющем большинстве

современных СУБД. Поэтому быстро выяснилось, что используе-

мый (в первоначальной версии спецификации XSD) подход

к построению XML-схем нуждается в совершенствовании путем

добавления в нее возможностей формирования агрегированных

схем. Агрегированная схема позволяет составлять структуры из

частей, которые могут быть описаны и/или использованы в других

схемах, а также налагает ограничения на значения элементов свя-

занных частей.

На сегодняшний день такие схемы создаются с помощью СУБД

в виде таблиц, каждая строка которой должна иметь уникальный

101

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

ляются с помощью вторичных ключей, имеющих значения первич-

ных ключей другой таблицы. Этот способ моделирования данных

существует уже более 40 лет и доминирует в современной техноло-

гии баз данных.

Потребности обмена данными информационных систем разных

производителей требуют обеспечения преобразования данных

из бинарного представления (в виде баз данных) в текстовый (в XML-

формат), и наоборот. При этих преобразованиях важно

гарантировать отсутствие искажения передаваемой информации,

а для этого структуры XML-документов должны быть адекватны

структурам баз данных информационных систем. Это вынудило раз-

работчиков спецификации XSD создать такие средства для XML-схем,

с помощью которых составные части схем создаются как самостоя-

тельные структурные единицы, а их соединения между собой осу-

ществляются в соответствии с ограничениями по ключу. Созданные

с помощью этих средств XML-схемы называются агрегированными.

Идентичность схем баз данных и XML-схем обеспечивает

возможность взаимного преобразования XML-данных и данных, пред-

ставленных в базах, и является важным качеством при создании

интегрированных автоматизированных систем, составленных из

гетерогенных составляющих. При этом текстовое представление

данных, «переведенное» из бинарного, является инвариантным для

разнородных систем и может служить в качестве средства межсис-

темного представления при обмене данными.

С учетом изложенного для обмена информацией между инфор-

мационными системами требуется использовать XML-документы,

созданные на базе агрегированных XML-схем.

Составим следующий план составления агрегированной XML-

схемы для передачи данных базы Firma.

1. Прежде чем приступить к разработке намеченной XML-схемы,

создадим папку, например, с именем Firma_Agreg, в которой будут

размещаться файлы агрегированной XML-схемы.

2. Агрегированную XML-схему, как и композиционную, опреде-

лим на трех уровнях:

102

– пользовательских типов данных и простых элементов;

– составных частей (Otdel и Sotrudnik);

– схемы верхнего уровня Firma.

3. В первую очередь определим уровень пользовательских типов

данных и простых элементов и сохраним его описание в отдельном

файле, скажем, UserType.xsd, в папке Firma_Agreg.

4. На уровне составных частей определим XML-схемы для

элементов Otdel и Sotrudnik и сохраним их в файлах с именами Otdel.xsd

и Sotrudnik.xsd в папке Firma_Agreg.

5. На верхнем уровне определим целевую XML-схему Firma,

а также опишем ключи для элементов Otdel и Sotrudnik, задавая, таким

образом, связи между ними, а также ограничения, вытекающие из

этих связей или зависимостей.

3.3.3.1 О п р ед е л е н и е п о л ьз о в а т е л ь ск их т и по в

д а н ны х

Так как элементы создаваемой схемы нам уже известны, то

в качестве пользовательских типов определяем уже известные нам

ограничения на наименования отделов и форму представления года

рождения. Добавим к этому перечню тип данных, принимающий два

альтернативных значения «да», «нет» для определения типа данных

атрибута «na_rabote», принимающего одно из двух альтернативных

значений.

1. Для создания XML-схемы определений пользовательских типов

данных открываем XML-редактор и переходим в режим создания XML-

схемы.

2. Для XML-схемы введем префикс и наименование целевого про-

странства и определяем параметры квалификации элементов и атри-

бутов. Например, это может быть сделано с помощью следующей


xmlns:typ="http://www.type.ru" targetNamespace=http://www.type.ru

elementFormDefault="qualified" attributeFormDefault="unqualified".

Стандартное пространство xmlns:xs="http://www.w3.org/2001/XMLSchema"

вводится по умолчанию.

103

3. Определяемые пользовательские типы элементов и атрибутов

будем хранить в отдельном файле, поэтому в создаваемой XML-схеме

введем необходимое количество конструкций xs:simpleType с атрибу-

тами name, с помощью которых указываются имена создаваемых

пользовательских типов (см. нижеследующий листинг).




<xs:simpleType name="otdNameType"> . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .

</xs:simpleType>

<xs:simpleType name="godRozhdType"> . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .

</xs:simpleType>

<xs:simpleType name="yesNoType"> . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .

</xs:simpleType>

4. Пользовательские типы элементов и атрибутов определяются

путем ограничения выбранного базового типа. Для объявления базо-

вого типа данных и дальнейшего его ограничения введем внутри

тега xs:simpleType конструкцию

<xs:restriction base="xs:string"> . . . . . . . . . . . . . . . . . . . .

</xs:restriction>.

В этой конструкции с помощью атрибута base указывается огра-

ничиваемый базовый тип.

5. Внутри конструкции xs:restriction определяются ограничения

базового типа, описанные в подразделе 3.2.4. Порядок определения

простых пользовательских типов данных с помощью ограничений

базовых типов описан в подразделе 3.2.5.

В соответствии с описанным порядком для агрегированной XML-

схемы Firma введем три пользовательских типа:

– otdNameType – базовый тип string, а ограничения определяются

путем представления перечня наименований;

104

– godRozhdType – базовый тип string, а ограничения определяются

путем представления шаблона \d\d\d\d;

– yesNoType – базовый тип string, а ограничения определяются

путем представления перечня значений «yes», «no».

В результате выполнения описанных действий получаем XML-

схему, текст которой приведен в следующем листинге:

 <?xml version="1.0" encoding="UTF-8"?>


xmlns:typ="http://www.type.ru" targetNamespace=http://www.type.ru


<xs:simpleType name="otdNameType">


<xs:enumeration value="КНИО-2"/>

<xs:enumeration value="НИО-21"/>

<xs:enumeration value="НИО-22"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="godRozhdType">


<xs:pattern value="\d\d\d\d"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="yesNoType">


<xs:enumeration value="yes"/>

<xs:enumeration value="no"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Сохраняем полученный XML-документ под именем UserType.xsd

в отдельной папке, например, Firma_Agreg.

3.3.3.2 О п р ед е л е н и е с о с т а в ны х ч а ст е й X M L - сх ем ы

Композиционная схема определяется как монолитная структура,

части которой определяются в составе общей схемы и не имеют

105

отдельного описания. Поэтому описания составных частей компози-

ционной схемы не могут быть использованы в других схемах.

Объект Firma содержит составные части Otdel и Sotrudnik, которые

в соответствии с порядком разработки агрегированных схем будем

определять как самостоятельные структурные единицы, а их опи-

сания хранить в файлах, с именами Otdel.xsd и Sotrudnik.xsd.

Разработка схем составных частей агрегированной схемы опи-

шем на примере создания XML-схемы Otdel.xsd в следующем порядке:

1. Для создания структурной единицы агрегированной XML-схемы

открываем XML-редактор и переходим в режим создания XML-схемы.

2. В создаваемой схеме применяется пользовательский тип

otdNameType, описание которого содержится в файле UserType.xsd. Для

обеспечения «видимости» этого описания со схемы Otdel.xsd необхо-

димо включить после объявления корневого элемента схемы конст-

рукцию xs:import, как показано в нижеследующем листинге:




<xs:import namespace="http://www.type.ru" schemaLocation="UserType.xsd"/> . . . . . . . . . . . . . . . . . . . .

</xs:schema>.

3. Для XML-схемы Otdel.xsd определяем префикс и целевое про-

странство и определяем параметры квалификации элементов и атри-

бутов. Например, это может быть сделано с помощью следующей


xmlns:otd="http://www.otdel.ru" targetNamespace="http://www.otdel.ru" elementFormDefault="qualified" attributeFormDefault="unqualified".

Пространство имен xmlns:xs="http://www.w3.org/2001/XMLSchema" для эле-

ментов XML-схемы определяется по умолчанию.

Кроме перечисленных пространств имен в описание схемы

добавляется пространство имен xmlns:typ="http://www.type.ru" импортиро-

ванного файла UserType.xsd.

4. Далее необходимо объявить элемент Otdel как сложный тип

с помощью конструкции

106

<xs:element name="Otdel">

<xs:complexType> . . . . . . . . . . . . . . . . . . . .

</xs:complexType>

</xs:element>,

в которой его наименование вводится с помощью атрибута name.

5. Для определения структуры элемента Otdel введем конструк-

цию xs:sequence и определим состав его элементов с указание типов

данных, которые могут быть как базовыми, так и пользовательскими

(см. нижеследующий листинг).




<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:otd="http://www.otdel.ru" targetNamespace="http://www.otdel.ru" elementFormDefault="qualified" attributeFormDefault="unqualified"

xmlns:typ="http://www.type.ru">

<xs:import namespace="http://www.type.ru" schemaLocation="UserType.xsd"/> <xs:element name="Otdel">

<xs:complexType>

<xs:sequence>

<xs:element name="id_otd" type="xs:integer"/>

<xs:element name="name_otd" type="otdNameType"/>

<xs:element name="vlozh" type="xs:integer"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Обратите внимание на то, что в данном определении мы ввели

целевое пространство имен, согласно которому элементы структуры

в XML-документе будут определяться с префиксом otd. В данном

случае определение целевого пространства имен необходимо, так

как данная XML-схема предназначена для использования в других

схемах с целью устранения коллизий имен тегов, определенных

в разных XML-схемах.

6. В соответствии с описанным порядком создадим еще один

файл Sotrudnik.xsd с XML-схемой для составной части Sotrudnik. Следует

107

отметить, что небольшие отличия при создании файла Sotrudnik.xsd все

же имеются.

Первое отличие связано с тем, что для элемента определяется

свое пространство имен и определяется оно по аналогичной конст-

рукции, но с другими префиксом и именем, например:

xmlns:otd="http://www.otdel.ru" targetNamespace="http://www.otdel.ru" elementFormDefault="qualified" attributeFormDefault="unqualified".

Следующее отличие касается определения атрибута «na_ rabote»

для элемента Sotrudnik. С целью определения атрибута добавьте в его

определение конструкцию

<xs:attribute name="na_rabote"> <xs:simpleType> <xs:restriction base="yesNoType"/> </xs:simpleType> </xs:attribute>

непосредственно после определения состава элемента

(т. е. после закрывающего тега </xs:sequence>). В результате выполне-

ния описанных действий получим XML-схему, текст которой приве-

ден ниже:




<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:otd="http://www.sotrudnik.ru" targetNamespace="http://www.sotrudnik.ru" elementFormDefault="qualified" attributeFormDefault="unqualified"

xmlns:typ="http://www.type.ru">

<xs:import namespace="http://www.type.ru" schemaLocation="UserType.xsd"/> <xs:element name="Sotrudnik">

<xs:complexType>

<xs:sequence>

<xs:element name="tab_nom" type="xs:integer"/>

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


<xs:element name="god_rozhd" type="godRozhdType"/>

<xs:element name="id_otd" type="xs:integer"/>

</xs:sequence> <xs:attribute name="na_rabote"> <xs:simpleType>

108

<xs:restriction base="yesNoType"/> </xs:simpleType> </xs:attribute> </xs:complexType>

</xs:element>

</xs:schema>

Оба созданных файла сохраняем в папке Firma_Agreg.

3.3.3.3 О п р ед е л е н и е а г р е ги р о в ан но й X M L - сх ем ы

и з с о с т а вн ы х ч а с т е й

Характерной особенностью агрегированной XML-схемы является

то, что она составляется из частей, определенных как самостоятель-

ные структурные единицы без указания ограничений, налагаемых на

них при включении в определенные структуры. Поэтому основное

содержание описания схемы на верхнем уровне касается определе-

ний состава целевой структуры и ограничений, налагаемых на них

при создании структур более высокого порядка.

Разработка агрегированной XML-схемы Firma.xsd выполняется

в следующем порядке:

1. Открываем XML-редактор для создания XML-схемы.

2. Создаваемая агрегированная XML-схема содержит структурные

элементы Otdel и Sotrudnik, описания XML-схем которых содержатся

в файлах Otdel.xsd и Sotrudnik.xsd. Для обеспечения «видимости» этих

описаний со схемы Firma.xsd необходимо включить в объявление

схемы эти файлы с помощью конструкции xs:import.

Для XML-схемы Firma.xsd определяем префикс и целевое прост-

ранство и определяем параметры квалификации элементов и атрибу-

тов. Например, это может быть сделано с помощью следующей


xmlns:fir="http://www.firma.ru" targetNamespace="http://www.firma.ru" elementFormDefault="qualified" attributeFormDefault="unqualified".

В результате выполнения описанных определений получаем

следующее объявление корневого элемента схемы:

 <?xml version="1.0" encoding="UTF-8"?>

109

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:otd="http://www.otdel.ru" xmlns:sot="http://www.sotrudnik.ru" xmlns:fir="http://www.firma.ru" targetNamespace="http://www.firma.ru" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="http://www.otdel.ru" schemaLocation="Otdel.xsd"/> <xs:import namespace="http://www.sotrudnik.ru" schemaLocation="Sotrudnik.xsd"/> . . . . . . . . . . . . . . . . . . . .

</xs:schema>

3. Аналогично определению составных частей Otdel и Sotrudnik,

объявим элемент Firma как сложный тип с помощью конструкции


<xs:complexType>

. . . . . . . . . . . . . . . . . . . .

</xs:complexType>

</xs:element>,

Здесь, как и при определении составных частей, с помощью

атрибута name вводим наименование создаваемой агрегированной

XML-схемы Firma.

4. Для определения структуры элемента Firma введем конструк-

цию xs:sequence и определим состав его элементов в виде совокуп-

ности элементов Otdel и Sotrudnik. В описании состава этих элементов

в данном случае нет необходимости, а достаточно указать на их

описания с помощью ключевого слова ref, как показано в нижесле-

дующем листинге:


<xs:complexType>

<xs:sequence>

<xs:element ref="Otdel"/>

<xs:element ref="Sotrudnik"/>

</xs:sequence>

</xs:complexType>.

На этом определение состава элемента Firma завершается и оста-

ется описать связи между элементами Otdel и Sotrudnik, определяющие

его структуру.

110

5. Первым структурным ограничением, определяемым для эле-

мента Firma, является указание количества его составных элементов

с помощью атрибутов minOccurs и maxOccurs (описание см. в пункте

3.2.6.3):

– если значение minOccurs ="0", это говорит о том, что описывае-

мый элемент является необязательным в XML-документе;

– при maxOccurs ="1" или при отсутствии определения этой пары

атрибутов в XML-документе по умолчанию определяется единствен-

ный экземпляр описываемого элемента;

– если значение maxOccurs="unbounded", то в XML-документе опреде-

ляется неограниченное количество экземпляров описываемого

элемента.

В нашем примере для обоих элементов определяем неограни-

ченное количество их экземпляров, т. е. maxOccurs="unbounded", после

чего определения элементов Otdel и Sotrudnik приобретают вид

<xs:element ref="Otdel" maxOccurs="unbounded"/>

<xs:element ref="Sotrudnik" maxOccurs="unbounded"/>.

6. Следующим шагом в части определения структуры элемента

Firma является ввод первичных ключей, необходимых для однознач-

ной идентификации элементов данных в XML-документах. Синтаксис

первичных ключей в XML-схемах описан в пункте 3.2.6.4, поэтому

подробности их определения здесь опустим и ограничимся приведе-

нием текста их определения в создаваемой XML-схеме:

<xs:key name="PK_otd"> <xs:selector xpath="Otdel"/> <xs:field xpath="id_otd"/> </xs:key>

<xs:key name="PK_sotr"> <xs:selector xpath="Sotrudnik"/> <xs:field xpath="tab_nom"/> </xs:key>.

Данные ограничения определяют, что в XML-документах, создан-

ных на основе XML-схемы Firma.xsd, значения элементов id_otd

и tab_ nom должны быть уникальными.

111

7. Порядок определения вторичного ключа дочернего элемента

связи также описан в пункте 3.2.6.4, согласно которому вторичный

ключ FK_Sotr определяется в соответствии с синтаксисом

<xs:keyref name="FK_Sotr" refer="PK_otd"> <xs:selector xpath="Sotrudnik"/> <xs:field xpath="id_otd"/> </xs:keyref>

В результате выполнения описанных действий получим агреги-

рованную XML-схему, текст которой приведен в нижеследующем

листинге.




<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:otd="http://www.otdel.ru" xmlns:sot="http://www.sotrudnik.ru" xmlns:fir="http://www.firma.ru" targetNamespace="http://www.firma.ru" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="http://www.otdel.ru" schemaLocation="Otdel.xsd"/> <xs:import namespace="http://www.sotrudnik.ru" schemaLocation="Sotrudnik.xsd"/> <xs:element name=" Firma">

<xs:complexType>

<xs:sequence>

<xs:element ref="Otdel" maxOccurs="unbounded"/>

<xs:element ref="Sotrudnik" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:keyref name="FK_Sotr" refer="PK_otd">



</xs:keyref>

<xs:key name="PK_otd">

<xs:selector xpath="Otdel"/>


</xs:key>

<xs:key name="PK_sotr">


<xs:field xpath="tab_nom"/>

</xs:key>

112

</xs:element>

</xs:schema>

Сохраняем созданный файл в папке Firma_Agreg.

3.3.3.4 С о зд а н и е XM L - д о к у м е н т а по а гр е г ир о в а н-

н о й сх ем е

По созданной агрегированной XML-схеме может быть построен

XML-файл с данными (см. приведенный листинг).



<?xml version="1.0" encoding="UTF-8"?> <fir:Firma xsi:schemaLocation="http://www.firma.ru Firma.xsd" xmlns:fir="http://www.firma.ru" xmlns:otd="http://www.otdel.ru" xmlns:sot="http://www.sotrudnik.ru" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<otd:Otdel>


<otd:name_otd>КНИО-2</otd:name_otd>

<otd:vlozh>0</otd:vlozh>

</otd:Otdel>

<otd:Otdel>


<otd:name_otd>НИО-21</otd:name_otd>


</otd:Otdel>

<otd:Otdel>


<otd:name_otd>НИО-22</otd:name_otd>


</otd:Otdel>

<otd:Sotrudnik na_rabote="yes">


<otd:Family>Петров</otd:Family>

<otd:name>Иван</otd:name>



</otd:Sotrudnik>

113



<otd:Family>Нилов</otd:Family>

<otd:name>Илья</otd:name>



</otd:Sotrudnik>



<otd:Family>Фонвизин</otd:Family>

<otd:name>Петр</otd:name>



</otd:Sotrudnik>

</otd:Firma>

В данном XML-документе поддерживаются правила ссылочной

целостности, определенные в XML-схеме с помощью первичных

и вторичных ключей. Если мы в соответствующие элементы XML-

документа введем значения, не удовлетворяющие этим требованиям,

то проверка на корректность этого документа покажет наличие

ошибки. Это говорит о том, что XML-документы, созданные на базе

агрегированных схем, соответствуют требованиям ограничений

ссылочной целостности и могут быть использованы для обмена

данными, содержащимися в реляционных базах.

114


1. Для чего необходима проверка на корректность (валидация)

документа?

2. Что определяет DTD-схема документа?

3. Какие инструкции используются в DTD-схеме для описания

грамматики XML-документа?

4. Каковы достоинства и недостатки DTD-схем?

5. Что представляет собой XML-схема (XSD) и чем она отличается

от DTD-схемы?

6. Для чего в XML-документе необходимо пространство имен?

7. Опишите синтаксис определения пространства имен.

8. Что собой представляют встроенные типы в XML-схемах?

9. Опишите синтаксис определения встроенных типов в XML-

схемах.

10. Что собой представляют пользовательские типы в XML-

схемах?

11. Опишите синтаксис определения пользовательских типов

в XML-схемах.

12. Что собой представляют комплексные типы в XML-схемах?

13. Опишите синтаксис определения комплексных типов в XML-

схемах.

14. В чем разница между простыми и комплексными типами

элементами в XML-схемах?

15. Опишите процесс связывания XML-схемы с XML-документом.

16. Опишите процесс наложения пространства имен.

17. Опишите процедуру нормализации XML-схемы.

18. Опишите синтаксис объявления корневого элемента объекта

в XML-схемах.

19. Опишите синтаксис объявления первичных ключей сложных

элементов в XML-схемах.

20. Опишите синтаксис объявления вторичных ключей сложных

элементов в XML-схемах.

21. Опишите синтаксис объявления ограничения уникальности

элемента в XML-схемах.

115

22. Опишите процедуру объявления типов в отдельном файле

схемы.

23. Опишите композиционные и агрегированные XML-схемы

и расскажите об их особенностях.

24. Опишите процедуру преобразования композиционной XML-

схемы в агрегированную.

116

ГЛАВА 4. XSL – ЯЗЫК ОПИСАНИЯ ФОРМЫ ДЛЯ ВЫВОДА ДАННЫХ

Создателям языка XML удалось отделить содержимое документа

не только от его структуры, но и от форматирования, т. е. от данных,

определяющих его внешний вид. Поскольку информация XML-

документа не указывает на то, как она будет отображена на экране,

то дополнительно определяется таблица стилей, с помощью которой

документу придается желаемый внешний вид.

Цифры или данные XML-документа должны отображаться так,

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

хранятся данные о погоде, тогда назначение таблицы стилей −

определять внешний вид карты. При этом на экране появляется кар-

та, на которую нанесены сведения о температуре, ветре, осадках

и т. д. Эти сведения содержатся в XML-документе, характеризующем

состояние погоды в различных географических точках. Специальная

программа обрабатывает эти цифры и создает изображение. Если,

к примеру, документ XML просматривается с помощью Web-браузера,

то таблица стилей должна создать подходящий HTML-документ.

4.1 ТАБЛИЦА СТИЛЕЙ CSS И ЯЗЫК XSL

Таблицей стилей называется специальный документ, содержа-

щий список стилей, которые применяются к информации XML-

документа, а процесс описания того, как будет визуально представ-

лено его содержимое, называется стилизацией XML-документа.

117

В качестве одного из первых способов сообщить браузеру, как

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

таблицы каскадных стилей (Cascade Stylesheet – CSS) и их связывание

с XML-документом. XML-документ со связанной таблицей каскадных

стилей может быть открыт в браузере. При этом нет необходимости

использовать HTML-страницу для доступа и отображения данных, так

как она генерируется автоматически по данным из XML-документа

и таблицы каскадных стилей.

Хранение инструкций по отображению в таблице стилей,

отдельно от самого XML-документа, повышает гибкость XML-

документа и облегчает работу с ним. Вы можете, например, быстро

адаптировать один XML-документ к различным условиям отображе-

ния, определяемым браузерами, приложениями, периферийными

устройствами и т. д., простым присоединением соответствующей

таблицы стилей, без необходимости реструктурировать сам доку-

мент. Вы также можете быстро обновить формат для группы сход-

ных XML-документов с помощью внесения изменений в присоеди-

ненной к этим документам таблице стилей, не открывая и не редак-

тируя каждый из документов.

Использование таблицы стилей является самым простым мето-

дом отображения XML-документа. CSS уже знаком многим Web-

дизайнерам, поскольку именно он в настоящее время используется

для форматирования HTML-страниц. Кроме того, современные Web-

браузеры обеспечивают высокий уровень поддержки таблиц каскад-

ных стилей, в то время как другие методы отображения XML все еще

находятся в стадии развития, и браузеры только начинают их

поддерживать.

Тем не менее, таблицы каскадных стилей имеют ряд ограниче-

ний. Хотя таблица каскадных стилей предоставляет достаточно

высокий уровень управляемости способами, которыми браузер

форматирует содержимое элементов в XML-документах, она не дает

возможности модифицировать или реорганизовывать его содержи-

мое. Она также не позволяет вам осуществлять доступ к атрибутам,

примитивам, инструкциям по обработке и другим компонентам XML,

118

не дает возможности обрабатывать информацию, которую эти ком-

поненты содержат.

Поэтому был разработан более сложный, но и более гибкий,

способ отображения XML-документов: расширяемый язык таблиц

стилей (Extensible Stylesheet Language – XSL), который позволяет вам не

только форматировать содержимое XML-элемента, но и преобразовы-

вать содержимое документа с достаточно высокой степенью

гибкости.

4.1.1 ТАБЛИЦА СТИЛЕЙ CSS

Этот язык напоминает команды стиля, основанные на языке

HTML, и его спецификацию реализовать очень просто. Главной

особенностью документов XML является отделение данных от их

представления.

4.1.1.1 А т о м CS S : я че й к а

Все элементы CSS содержатся в ячейках. Ячейка представляет

собой прямоугольную область с определенными базовыми характе-

ристиками, такими как margin (запас) или border (граница). Все ячейки

вкладываются друг в друга, как матрешки. Некоторые ячейки

содержат другие ячейки, а другие – только сами содержатся

в первых. Конструкцию такого типа можно трансформировать

в дерево ячеек, или прямоугольных областей. Само дерево содер-

жится в ячейке контейнера, предназначенного либо для сплошной

среды (такой, как браузеры с возможностью прокрутки экрана), либо

для печатного материала (где размеры области являются фиксиро-

ванными).

4.1.1.2 С в я з ь э л ем е н то в д о к у м ен т а X M L с п р а ви л а м и CS S

Поняв, что язык CSS описывает мир в виде ячеек, рассмотрим,

каким образом можно связать с этими ячейками элементы XML.

Ответ: с помощью правил, которые состоят из группы свойств,

связанных с одним или несколькими типами элементов.

119

Таблица каскадных стилей представляет собой текстовый файл,

обычно с расширением .css, который содержит набор правил, сооб-

щающих браузеру, каким образом форматировать и отображать

элементы в определенном XML-документе. Как и XML-документ,

вы можете создавать таблицу стилей с помощью вашего любимого

текстового редактора.

Правило содержит информацию по отображению определенного

типа элемента в XML-документе. Для записи правил используется

синтаксис:

Selector {properties}

Селектор представляет собой имя типа элемента, к которому

относится информация по отображению.

За селектором следует блок объявлений, который ограничива-

ется фигурными скобками { } и содержит одно или несколько объяв-

лений, разделяемых точкой с запятой, использующих следующий

синтаксис: Property = attribute: value;

Объявление состоит из свойства, вслед за которым идет двоето-

чие, после которого следует значение для данного свойства.

Каждое объявление задает установку определенного свойства,

такого как размер шрифта, который будет использован для отобра-

жения элемента. Например, объявление font-size: 10pt устанавливает

для свойства Размер шрифта значение 10 пунктов.

На Рис. 4.1 представлено правило для элементов Имя с указани-

ем его составных частей.

120

Таблица стилей может содержать комментарии. Комментарии

в таблице стилей начинаются с символов косой черты и звездочки

(/*) и заканчиваются символами звездочки и косой черты (*/). Между

этими парами символов-ограничителей вы можете поместить любой

текст по вашему желанию. Когда браузер прочитывает таблицу сти-

лей для форматирования документа, он игнорирует этот текст.

Комментарии можно использовать для пояснений, указания назна-

чения и действия таблицы стилей.

При визуализации CSS чрезвычайно зависит от структуры доку-

мента. Часто дерево объектов форматирования идентично дереву

документа. В принципе таблицы стилей CSS ассоциируют имеющие

специфические свойства объектов форматирования CSS с каждым

элементом XML.

4.1.1.3 Т и п ы ср ед ы и м о д у л ь ны е т аб л и ц ы с ти л е й

Таблица стилей CSS – это средство, позволяющее подготовить

документ XML для показа. CSS разрешает осуществлять представле-

ние в средах нескольких типов:

screen – экранное устройство, например браузер; print – устройство печати, например для печатания книг; aural – слуховое устройство, например синтезатор речи; Braille – устройство Брайля для тактильной обратной связи; Embossed – устройство для выдавливания, создаваемое странич-

ным принтером Брайля; projection – устройство-проектор; tty – устройство tty больше известное под названием телетайпа; tv – телевизор. Таким образом, таблица стилей CSS может содержать специфи-

кацию стилей для нескольких типов сред, например для браузеров, принтеров и речевых устройств. При этом каждое целевое устройство определяется конструкцией @media. Например, следую-щее выражение ассоциирует правила CSS с экранным устройством (обычно браузером):

@media screen { BOOKLIST {display : block;} }

Рис. 4.1 Элемент CSS-кода

121

Как видите, все правила, предназначенные для конкретного типа

среды, содержатся в конструкции @media. Селекторы могут опреде-

лять применение одних и тех же правил к нескольким элементам, но

их точно так же можно использовать для нескольких типов среды: @media screen, print { BOOKLIST { display : block;} }

Иногда для обеспечения модульности спецификации визуализа-

ции требуется разделить таблицу стилей на несколько файлов,

например, чтобы сохранить таблицу стилей для печати в одном

файле, а звуковую таблицу стилей – в другом.

Конструкция @import позволяет импортировать правила из других

таблиц стилей. В документе таблицы стилей она должна предшест-

вовать всем остальным конструкциям CSS. Сослаться на импорти-

руемую таблицу стилей можно с помощью ее адреса URL.

Конструкции @media и @import можно комбинировать в одном

выражении.

4.1.1.4 З а к л ю ч и т е ль ны е с о о б р а ж ени я п о по во д у

C S S

CSS представляет собой простой язык стилей, который легко

запомнить и использовать. Его главное преимущество – простота.

Если нужно только визуализировать документ XML, не выполняя

никаких трансформаций, язык CSS подойдет для этого лучше всего.

Основными недостатками CSS являются отсутствие более сложных

моделей визуализации и зависимость от структуры обрабатываемых

документов XML. Значит, осуществляющее обработку приложение

должно понимать язык XML. Для получения большей независимости

между структурой документа и форматом визуализации лучше

воспользоваться языком XSL.

4.1.2 ЯЗЫК XSL

По сравнению с CSS расширяемый язык таблиц стилей реализует

совершенно другой способ преобразования документа XML в отобра-

жаемые объекты. Он значительно более гибок и может быть исполь-

зован для трансформации документа XML в языки для других сред.

122

Моделирование не является просто подготовкой документа для

визуального представления в сети Web. Если необходимо использо-

вать содержание XML для различных целей, нужно иметь возмож-

ность на основании одних исходных файлов создавать различные

форматы их представления.

Язык XSL состоит из трех спецификаций:

– XPath – http://www.w3.org/TR/xpath;

– XSLT – http://www.w3.org/TR/xslt;

– XSLF – http://www.w3.org/TR/xsl.

В спецификации XSLT внимание обращено на трансформации

документа XML, в спецификации XSLF – на форматирование объектов,

а в XPath – на доступ к узлам иерархической структуры XML.

Обработчик XSL должен, как минимум, поддерживать часть транс-

формаций (XSLT) и XPath.

Язык XSL, как и все другие языки семейства XML, является

расширяемым. Это означает, что к имеющимся в языке объектам

форматирования можно добавить новые объекты, что позволит

избавиться от ограничения таблиц стилей CSS - фиксированного

набора объектов форматирования.

4.1.2.1 Р а с ш и р я ем ы е т а б л и ц ы с т и л ей XSLT

Общая структура таблицы стилей довольно проста: в ее состав

входят последовательности и шаблоны. Здесь мы увидим, каким

образом эти компоненты используются для визуализации XML-

документов.

Таблица стилей XSL содержит обязательный корневой элемент

с названием Stylesheet. Этот элемент наряду с набором других элемен-

тов и свойств XSL является частью словаря XSLT. Чтобы использовать

содержимое XSLT, необходимо сначала объявить пространство имен,

в которое оно будет помещено. Ниже показано, как с помощью

элемента stylesheet объявляется пространство имен XSL:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">

Данный код делает доступными все элементы и атрибуты

пространства имен XSL и назначает им префикс xsl. Это действие

123

стандартно для всех таблиц стилей; его смысл поясняется в следую-

щих подразделах, где мы рассмотрим кодирование последователь-

ностей и шаблонов.

Последовательности. При обработке таблицы стилей XSL поиск

данных для трансформации осуществляется с помощью последова-

тельностей. Говоря точнее, последовательность идентифицирует

элемент или атрибут XML-документа, являющийся ветвью его древо-

видной структуры.

Последовательности задаются весьма просто. Их можно срав-

нить путями файловой системы: если пути указывают на папки

и файлы вашего жесткого диска, то последовательности определяют

элементы и атрибуты документа. Так, к примеру, элемент head, вло-

женный в элемент html любого HTML-документа, идентифицируется

как html/head.

Назначение последовательностей − выделять фрагменты XML-

документов, подлежащие трансформации. Когда XSL-процессор

обнаруживает некоторые данные, соответствующие последователь-

ности, он передает их для выполнения трансформации шаблону.

Шаблоны. Шаблоны − часть таблицы стилей, предназначенная

для трансформации данных. Когда XSL-процессор обнаруживает

последовательность в документе, он пропускает ее через шаблон

и трансформирует. Количество шаблонов таблицы стилей не огра-

ничено. Если в таблице стилей имеется несколько шаблонов, то

каждый выполняет трансформацию определенного фрагмента XML-

документа.

Поскольку XSL представляет собой XSL-словарь, таблицы стилей

закодированы с помощью XML. Шаблон XSL представляет собой

последовательность инструкций форматирования, которые приме-

няются к узлам, выбранным выражением XPath. В самой простой

таблице стилей шаблон XSL выглядел бы примерно так:

<xsl:template match="/">

Этот шаблон будет осуществлять трансформацию всего доку-

мента целиком, начиная с корневого элемента. Как правило, вам

124

необходимо будет создавать шаблоны для элементов, находящихся

ниже корневого.

Таким образом, шаблон задается элементом xsl:template, а после-

довательность, связанная с ним, − атрибутом match элемента

xsl:template.

Шаблон XSL более сложной таблицы стилей мог бы иметь

следующий вид:

<xsl:template match="Inventory/Book/title">

. . . . . . . . . . . . . . . . . . . . . . . . .

</xsl:template>

Как видим, элемент title задан с перечислением всех его роди-

тельских элементов. Обратите внимание на закрывающий тег

</xsl:template>, обязательный для всех шаблонов.

Чтобы задать преобразование для данных, находящихся внутри

элемента title, следует поместить тег <xsl:value-of/> внутри шаблона, как

показывает следующий код:

<xsl:template match="Inventory/Book/title">

<b>Глава </b>

<xsl:value-of/>

</xsl:template>.

Здесь преобразование заключается в том, что перед данными

элемента title будет помещен текст Глава, выделенный полужирным

шрифтом. Элемент <xsl:value-of/> представляет содержимое элемента

title. Кроме <xsl:value-of/>, существует еще несколько элементов,

которые часто используются при создании шаблонов и входят

в стандартное пространство имен XSL:

xsl:value-of – вставляет содержимое элемента (атрибута) XML;

xsl:if – задает условное соответствие для шаблонов;

xsl:for-each – создает цикл для элементов документа XML;

xsl:apply-templates – применяет шаблон к XML-документу.

4.1.2.2 К а к р а б о т а е т я з ы к XS L

Как и другие языки, основанные на правилах, документ XSL

представляет собой коллекцию правил, состоящую из раздела

125

сравнения образцов и раздела действий. На языке XSL эти правила

называются шаблонами, так что атомарным элементом таблицы

стилей XSL является шаблон.

Как только выражение XPath выбрало узел документа, оно связы-

вается с содержанием шаблона. Так как документ XML трансформи-

руется в дерево результата, состоящее из объектов форматирования

XSL, возникает необходимость сравнить каждый элемент оригиналь-

ного документа XML с конкретным шаблоном. Кроме того, при необ-

ходимости трансформировать оригинальный документ совместно

используется несколько конструкций XSLT и выражений XPath, что

позволяет достичь любого узла документа XML, преобразуемого

в иерархическую структуру.

Выражение XPath дает возможность достичь любого узла доку-

мента. Конструкция XSLT позволяет установить соответствие между

узлами и шаблонами, содержащими объекты форматирования XSL.

Чтобы лучше понять процесс, обратимся к внутреннему устрой-

ству обработчика XSL. Процессор XSL создает три дерева:

– дерево, содержащее входной XML-документ, для визуализации;

– дерево с таблицей стилей XSL;

– дерево выходного документа, как правило, HTML-кода, исполь-

зуемого браузером для визуального отображения документа.

Для каждого шаблона в дереве, содержащем таблицу стилей, при

обнаружении явной или неявной конструкции apply-template процессор

находит соответствующий узел в дереве исходного документа.

Обнаружив соответствие, процессор использует содержание

шаблона в качестве основы для результата, записываемого в дерево

на выходе.

Когда все узлы в исходном дереве найдены и к ним применены

соответствующие шаблоны, вы получаете полностью трансформи-

рованный XML-документ. При открытии документа XML в браузере

его таблица стилей автоматически обрабатывается, в результате чего

в окне браузера появляется сгенерированный HTML-документ. Весь

описанный процесс происходит совершенно незаметно для пользо-

вателя. Схема выполнения такого преобразования показана на

Рис. 4.2.

126

Следует иметь в виду, что XSL не ограничивается преобразовани-

ем XML-документов в формат HTML, а может перевести документ из

XML в любой другой язык разметки, поскольку обладает высокой

степенью обобщенности. Например, если задачей является печать

Рис. 4.2 Визуализация XML-документа

127

документа, на выходе будут сгенерированы объекты форматирова-

ния, которые можно трансформировать в графические объекты для

печати.

4.2 ПРИМЕНЕНИЕ CSS

В этом разделе мы познакомимся с первым из описанных выше

методов отображения XML-документов в браузере – таблицами

каскадных стилей (CSS). Таблица каскадных стилей представляет

собой файл, который содержит инструкции для форматирования

элементов в XML-документе.

4.2.1 ПРИМЕР ПРОСТОЙ ТАБЛИЦЫ КАСКАДНЫХ СТИЛЕЙ

Таблицы каскадных стилей для отображения XML-документа

создаются в два этапа:

1. Создание файла таблицы стилей.

2. Связывание таблицы стилей с XML-документом.

Далее рассмотрим примеры отображения XML-документов

с помощью каскадных таблиц стилей.

Сначала рассмотрим пример простой таблицы каскадных стилей.

/* Имя файла: CatalogCSS2.css */

book

{display:block;

margin-top:12pt;

font-size:10pt}

title {font-style:italic}

author {font-weight:bold}

В данном примере в начале таблицы стилей содержится коммен-

тарий. Далее таблица стилей содержит следующие объявления:

display:block: помещает перевод строки перед и после текста;

margin-top:12pt: добавляет верхнее поле высотой в 12 пт;

font-size:10pt: устанавливает размер шрифта, используемого для

отображения текста элемента, в 10 пт;

font-style:italic: отображает текст элемента курсивом;

font-weight:bold: отображает текст элемента полужирным.

128

Сформированная выше таблица стилей предназначена для при-

соединения к XML-документу CatalogXSL2.xml.

Чтобы связать таблицу каскадных стилей с XML-документом, вы

должны вставить в документ зарезервированную инструкцию

по обработке xml-stylesheet.

Эта инструкция по обработке имеет следующую обобщенную

форму записи, где URLТаблСтил есть URL, задающий местонахождение

файла таблицы стилей:

<?xml-stylesheet type="text/css" href="URLТаблСтил"?>

В нашем примере инструкция xml-stylesheet имеет вид:

<?xml-stylesheet type="text/css" href="CatalogCSS2.css"?>

Возможность присоединять к XML-документу внешнюю таблицу

стилей увеличивает гибкость форматирования документа.

Вы можете полностью изменить вид документа, просто присоединив

к нему другую таблицу стилей. Чтобы сделать это, достаточно всего

лишь отредактировать URL в инструкции по обработке xml-stylesheet –

не внося никаких других изменений в XML-документ.

Если вы связали таблицу стилей с XML-документом, вы можете

открыть этот документ непосредственно в браузере путем ввода URL

документа или путь к файлу в поле Address (Адрес).

Браузер откроет XML-документ и отобразит его с использованием

инструкций из связанной таблицы стилей.

На Рис. 4.3 показано, как браузер отображает XML-документ,

который использует данную таблицу стилей в соответствии с инст-

рукциями, содержащимися в этих объявлениях.

Рис. 4.3 Отображение XML-документа с помощью CSS-кода

129

Примечание. Если браузер не может найти файл таблицы стилей,

заданный в инструкции по обработке xml-stylesheet, он отобразит текст доку-

мента с использованием своего собственного набора свойств (например,

с текущими значениями гарнитуры и размера шрифта). Если XML-документ

не связан с таблицей стилей (т. е. документ не содержит инструкции по

обработке xml-stylesheet), то браузер отобразит исходный XML-код для доку-

мента, но не содержимое документа.

Набор свойств, используемых в таблицах каскадных стилей,

похож на набор свойств, которые вы можете применять в текстовом

процессоре.

4.2.2 ПРИМЕР БОЛЕЕ СЛОЖНОЙ ТАБЛИЦЫ КАСКАДНЫХ

СТИЛЕЙ

А теперь изменим таблицу стилей так, чтобы форматировать

символьные данные элементов следующим образом:

– отображать каждый элемент book с отступом сверху в 12 пт

(margin-top:12pt) и с переводом строки сверху и снизу (display:block),

используя размер шрифта 10 пт (font-size:10pt);

– отображать каждый из элементов title,author,binding и price

в отдельной строке (display:block);

– отображать элемент title шрифтом с размером 12 пт (font-size:12pt),

полужирным (font-weight:bold), курсивом (font-style:italic). Обратите вни-

мание, что установка для элемента title размера шрифта 12 пт превали-

рует над установкой размера 10 пт для родительского элемента book;

– отступ слева для каждого из элементов author,binding и price на

15 пт (margin-left:15pt);

– отображать элемент author полужирным (font-weight:bold);

– не отображать элемент pages (display:none).

Для этого измените CSS-таблицу CatalogCSS2.css, как показано

в листинге, приведенном ниже по тексту, и сохраните под именем CatalogCSS3.css.

/* Имя файла: CatalogCSS3.css */

book

{display:block;

margin-top:12pt;

130

font-size:10pt}

title

{display:block;

font-size:12pt;

font-weight:bold;

font-style:italic}

author

{display:block;

margin-left:15pt;

font-weight:bold}

binding

{display:block;

margin-left:15pt}

pages

{display:none}

price

{display:block;

margin-left:15pt}

В вашем текстовом редакторе откройте документ CatalogCSS2.xml.

Добавьте в конце пролога документа (над элементом inventory)

следующую инструкцию по обработке:

<?xml-stylesheet type="text/css" href="CatalogCSS3.css"?>

Рис. 4.4 Отображение XML-документа (CatalogCSS3.css)

131

Эта инструкция по обработке устанавливает связь между новой

CSS-таблицей, созданной вами, и XML-документом.

Сохраните файл под именем CatalogCSS3.xml и откройте его

в браузере. Браузер отобразит файл CatalogCSS3.xml в соответствии

с правилами, установленными в таблице стилей CatalogCSS3.css

(см. Рис. 4.4).

4.3 ПРИМЕНЕНИЕ XSL

4.3.1 ОСНОВЫ ИСПОЛЬЗОВАНИЯ XSL-ТАБЛИЦ СТИЛЕЙ

Существуют два основных шага для отображения XML-документа

при использовании XSL-таблицы стилей.

Создание файла XSL-таблицы стилей. XSL является приложе-

нием XML и подобно любому XML-документу, вы можете создать ее

с помощью любого текстового редактора.

Связывание XSL-таблицы стилей с XML-документом.

Вы можете связать XSL-файл с XML-документом, включив в документ

инструкцию по обработке xml-stylesheet, которая имеет следующую

обобщенную форму записи, где URLТаблСтил – URL, задающий распо-

ложение файла таблицы стилей:

<?xml-stylesheet type="text/xsl" href=XSLFilePath?>

В нашем примере аналогичная инструкция по обработке xml-

stylesheet имеет вид:

<?xml-stylesheet type="text/xsl" href="CatalogXSL01.xsl"?>

4.3.2 ИСПОЛЬЗОВАНИЕ ОДНОГО ШАБЛОНА XSL

В отличие от CSS, XSL-таблица стилей включает один или

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

отображения в определенной ветви элементов в XML-документе.

Рассмотрим простую XSL-таблицу стилей с одним шаблоном.

1. Сначала создадим и сохраним XML-документ CatalogXSL01.xml.





<book>

132

<title>Капитанская дочка</title>

<author>

<firstname>Александр</firstname>

<lastname>Пушкин</lastname>

</author>

<binding>твердый переплет</binding>

<pages>267</pages>

<price>250 руб.</price>

</book>

2. Далее введем таблицу стилей с единственным шаблоном,

содержащим информацию для отображения всего документа.

На листинге представлен пример XSL-таблицы стилей CatalogXSL01.xsl

с одним шаблоном.




<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">


<H2>Описание книги</H2>

<SPAN STYLE="font-style:italic">Автор: </SPAN>

<xsl:value-of select="book/author"/><BR/>

<SPAN STYLE="font-style:italic">Название: </SPAN>

<xsl:value-of select="book/title"/><BR/>

<SPAN STYLE="font-style:italic">Цена: </SPAN>

<xsl:value-of select="book/price"/><BR/>

<SPAN STYLE="font-style:italic">Тип переплета: </SPAN>

<xsl:value-of select="book/binding"/><BR/>

<SPAN STYLE="font-style:italic">Количество страниц: </SPAN>

<xsl:value-of select="book/pages"/>

</xsl:template>

</xsl:stylesheet>

133

3. Теперь эту таблицу стилей необходимо связать с XML-докумен-

том CatalogXSL01.xml, созданным выше. Для этого в пролог XML-

документа CatalogXSL01.xml добавляется строка


4. Откроем файл CatalogXSL01.xml с помощью браузера.

На Рис. 4.5 показано, как браузер отображает XML-документ

CatalogXSL01.xml в соответствии с инструкциями из таблицы стилей

CatalogXSL01.xsl.

А теперь проанализируем структуру XSL-документа и рассмот-

рим, каким образом с его помощью происходит отображение в брау-

зере XML-документа.

Каждая XSL-таблица стилей должна иметь элемент Документ,

представленный ниже. (Напомним, что элемент Документ, известный

как корневой элемент, является XML-элементом верхнего уровня,

который содержит все остальные элементы) .

В XSL-документе корневым элементом xsl:stylesheet является




</xsl:stylesheet>

Элемент xsl:stylesheet служит не только хранилищем других эле-

ментов, но также идентифицирует документ как XSL-таблицу стилей.

Рис. 4.5 Отображение XML-документа с помощью XSL

134

Этот элемент является одним из XSL-элементов специального назна-

чения, используемых в таблице стилей.

Все XSL-элементы принадлежат пространству имен xsl, т. е. вы

предваряете имя каждого XSL-элемента префиксом xsl:, обозначаю-

щим пространство имен. Вы определяете это пространство имен

в начальном теге элемента xsl:stylesheet, например, следующим

образом:

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

Это определение позволяет вам использовать пространство имен

внутри элементов таблицы стилей.

Элемент Документ xsl:stylesheet XSL-таблицы стилей должен содер-

жать один или несколько шаблонов элементов, которые для

краткости будем называть шаблонами. Элемент Документ из приве-

денного примера содержит только один шаблон, который имеет

следующую форму:




</xsl:template>

Браузер использует шаблон для отображения определенной

ветви элементов в иерархии XML-документа, с которым вы связы-

ваете таблицу стилей. Атрибут match шаблона указывает на опреде-

ленную ветвь. (Атрибут match аналогичен селектору в правиле CSS).

Значение атрибута match носит название образца (pattern). Образец

в данном примере ("/") представляет корневой элемент всего XML-

документа. Этот шаблон, таким образом, содержит инструкции для

отображения всего XML-документа.

Каждая XSL-таблица стилей должна содержать один и только

один шаблон с атрибутом match, который имеет значение "/".

Вы также можете включить один или несколько дополнительных

шаблонов с инструкциями для отображения определенных подчи-

ненных ветвей в структуре XML-документа; каждая из них должна

иметь образец, отвечающий определенной ветви.

Шаблон содержит два вида XML-элементов.

135

XML-элементы, представляющие HTML-разметку. Примерами

подобного вида XML-элемента из рассматриваемой таблицы стилей

являются:

– <H2>Описание книги</H2>, который отображает заголовок второго

уровня;

– <SPAN STYLE="font-style:italic">Название: </SPAN>, который отображает

блок текста, набранного курсивом (Author:);

– <BR/>, который создает пустую строку.

Все эти XML-элементы являются корректно сформированными

и представляют стандартные HTML-элементы. Браузер просто копи-

рует каждый HTML-элемент непосредственно на выход HTML, который

воспринимает и отображает их.

Подсказка. Каждый из элементов, представляющих HTML-разметку,

должен быть корректно сформированным XML-элементом, а также стандарт-

ным HTML-элементом. (Не забывайте, что XSL-таблица стилей является XML-

документом). Следовательно, вы не можете использовать HTML-конструк-

ции, которые не являются корректно сформированным XML, такие, как

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

элемент перевода строки в HTML, вы не можете просто ввести <BR>, как вы

это делаете для HTML-страницы. Вместо этого вы должны использовать кор-

ректно сформированный тег пустого XML-элемента, <BR/>.

XSL-элементы. Примерами XSL-элементов из рассматриваемой

таблицы стилей являются элементы xsl:value-of, например:

<xsl:value-of select="book/author"/><BR/>

Браузер отличает XSL-элемент от элемента, представляющего

HTML, поскольку первый имеет в качестве префикса описание про-

странства имен xsl:. XSL-элементы в шаблоне не копируются на выход

HTML. Они лишь содержат инструкции по выбору и модификации

данных XML либо используются для выполнения других задач.

XSL-элемент value-of добавляет текстовое содержимое определен-

ного XML-элемента (а также любых его дочерних элементов, которые

он имеет) в выходной модуль HTML, который воспринимается

и отображается браузером. Вы указываете определенный XML-

136

элемент заданием образца, который присваиваете атрибуту select

XSL-элемента value-of.

В рассмотренном выше примере элемента value-of атрибуту select

присвоен образец "book/author", что приводит к выводу текстового

содержимого элемента author XML-документа. Текстовое содержимое

элемента author состоит из символьных данных, принадлежащих

двум его дочерним элементам, firstname и lastname.

Обратите внимание, что XML-элемент в образце задается с помо-

щью оператора пути (в данном случае book/author ), который опреде-

ляет местонахождение элемента в иерархии XML-документа. (Опера-

тор пути аналогичен пути к файлу, который операционная система

использует для указания местонахождения файла или папки).

Главный момент, на который здесь следует обратить внимание,

состоит в том, что оператор пути в значении атрибута select

относится к текущему элементу. Каждый контекст внутри XSL-

таблицы стилей относится к текущему элементу. Поскольку

рассматриваемый пример шаблона относится к корневому элементу

всего документа (посредством установки атрибута match="/"),

текущим «элементом» для данного шаблона является корневой

элемент документа.

Таким образом, внутри этого шаблона оператор пути book/author

указывает на элемент author, вложенный в элемент book, который,

в свою очередь, вложен в корневой элемент документа.

Если вы опустите атрибут select для XSL-элемента value-of, элемент

будет осуществлять вывод текстового содержимого плюс текстовое

содержимое всех дочерних элементов текущего элемента.

(В примере пропуск атрибута select приведет к выводу всех

символьных данных XML-документа).

Целью создания шаблона элементов, представленного

в рассматриваемом примере, является отображение текста названия

для каждого из дочерних XML-элементов (author, title, price, binding, pages)

в документе, а также текстового содержимого каждого элемента.

Обратите внимание, что порядок элементов value-of в шаблоне опре-

деляет порядок, в котором браузер отображает эти элементы.

137

Таким образом, даже из этой простой таблицы стилей вы можете

понять, что XSL-таблица стилей является гораздо более гибкой, чем

CSS, которая всегда отображает элементы в том порядке, в котором

они следуют в документе.

Итак, как вы могли заметить, XSL-таблица стилей сообщает брау-

зеру, как отобразить XML-документ путем избирательного преобразо-

вания XML-элементов в блок HTML-разметки, который восприни-

мается и отображается браузером аналогично разметке, содержа-

щейся на HTML-странице. При этом не нужно включать в XSL-шаблон

элементы, представляющие элементы HTML или BODY, поскольку

браузер сам эффективно их формирует.

На Рис. 4.6 показано, как браузер генерирует первую часть блока

HTML-разметки для документа и таблицы стилей.

Рис. 4.6 Преобразование XML-документа в HTML-код

138

4.3.3 ОТОБРАЖЕНИЕ ПЕРЕМЕННОГО ЧИСЛА ЭЛЕМЕНТОВ

В примере, рассмотренном в предыдущем подразделе, XML-

документ содержал только один элемент book. В случае, если доку-

мент содержит несколько элементов book, методика, с которой вы

познакомились в предыдущем подразделе, способна отобразить

только один из элементов. Возьмем, для примера, XML-документ

CatalogXSL02.xml с двумя элементами book.





<inventory>

<book>

<title>Капитанская дочка</title>

<author>

<firstname>Александр</firstname>

<lastname>Пушкин</lastname>

</author>

<binding>мягкий</binding>

<pages>267</pages>


</book>

<book>

<title>Анна Каренина</title>

<author>

<firstname>Лев</firstname>

<lastname>Толстой</lastname>

</author>

<binding>твердый</binding>

<pages>563</pages>


</book>

</inventory>

Для отображения этого документа мы не сможем воспользо-

ваться шаблоном, рассмотренным выше. Этот шаблон использует

методику, описанную в предыдущем подразделе. Согласно этой

139

методике, образец, присваиваемый каждому атрибуту select, начина-

ется с указания элемента Документ, в данном случае inventory.

Но каждый такой образец в новом XML-документе соответствует

двум различным элементам. Например, "inventory/book/author" соответст-

вует элементу author для обоих элементов book. В подобной ситуации

браузер использует только первый из соответствующих элементов.

Таким образом, таблица стилей отобразит содержимое только

первого элемента book.

Чтобы отобразить все отвечающие образцу элементы, следует

использовать XSL-элемент for-each, который вызывает повторный

вывод для каждого из содержащихся в XML-файле элементов. XSL-

таблица стилей, приведенная ниже, демонстрирует данную методику






<H2>Описание книг</H2>

<xsl:for-each select="inventory/book">


<xsl:value-of select="title"/><BR />


<xsl:value-of select="author"/><BR />


<xsl:value-of select="binding"/><BR />.


<xsl:value-of select="pages"/><BR />


<xsl:value-of select="price"/><P />

</xsl:for-each>

</xsl:template>

</xsl:stylesheet>

Эта таблица стилей предназначена для отображения XML-

документа CatalogXSL02.xml, и в результате ее применения браузер Inter-

net Explorer выводит отображение, приведенное на Рис. 4.7.

140

Элемент for-each выполняет две основные задачи:

– осуществляет вывод блока элементов, содержащихся внутри

элемента for-each, повторяя его для каждого XML-элемента в доку-

менте, отвечающего образцу, присвоенному атрибуту select элемента

for-each. В данном примере цикл выполняется по одному разу для

каждого элемента book, найденного в элементе Документ с именем

inventory. Образец, присваиваемый атрибуту select элемента for-each,

работает точно так же, как образец, присваиваемый атрибуту select

элемента value-of;

– внутри элемента for-each задает текущий элемент, устанавли-

ваемый атрибутом select элемента for-each (/inventory/book в нашем

примере указывает на элемент book внутри элемента inventory), как

показано ниже





<xsl:for-each select="inventory/book">



Рис. 4.7 Отображение XML-документа с помощью XSL

141

</xsl:for-each>

</xsl:template>

</xsl:stylesheet>.

Аналогично, внутри элемента for-each каждый дочерний элемент

может быть выбран путем задания образца, содержащего только имя

элемента, например:

<xsl:value-of select="title"/><BR />.

В результате выводятся данные всех элементов book, найденных

в документе, независимо от того, сколько этих элементов содержит

документ.

4.3.4 ИСПОЛЬЗОВАНИЕ НЕСКОЛЬКИХ ШАБЛОНОВ

Другой способ отображения повторяющихся XML-элементов

состоит в создании отдельного шаблона для каждого элемента

с последующим вызовом этого шаблона с использованием XSL-

элемента apply-templates.

Пример использования подобной методики приведен в XSL-

таблице стилей, представленной в файле CatalogXSL03.xsl.






<h2>Описание книг</h2>

<xsl:apply-templates select="inventory/book" />

</xsl:template>

<xsl:template match="book">

<span style="font-style:italic">Автор: </span>

<xsl:value-of select="author"/><br />

<span style="font-style:italic">Название: </span>

<xsl:value-of select="title"/><br />

<span style="font-style:italic">Цена: </span>

<xsl:value-of select="price"/><br />

<span style="font-style:italic">Тип переплета: </span>

<xsl:value-of select="binding"/><br />

<span style="font-style:italic">Количество страниц: </span>

<xsl:value-of select="pages"/><p />

142

</xsl:template>

</xsl:stylesheet>

Эта таблица стилей предназначена для отображения XML-

документа CatalogXSL03.xml, который отличается от XML-документа

CatalogXSL02.xml только тем, что содержит другую инструкцию

обработки

<?xml-stylesheet type="text/xsl" href="CatalogXSL03.xsl"?>.

Рассматриваемая в примере таблица стилей содержит два

шаблона. Один шаблон содержит инструкции для отображения всего

документа (путем установки match="/", указывающей на корневую

часть документа). Все XSL-таблицы стилей требуют наличия такого

шаблона. Другой шаблон содержит инструкции для отображения

элемента book (шаблон с установкой match="book").

Сначала браузер обрабатывает шаблон, соответствующий

корневой части элемента:


<h2>Описание книг</h2>

<xsl:apply-templates select="inventory/book" />

</xsl:template>

XSL-элемент apply-templates сообщает браузеру, что для каждого

элемента book внутри корневого элемента inventory он должен обраба-

тывать шаблон, отвечающий элементу book, т. е. шаблон, для атрии-

бута match которого установлено значение "book". Таблица стилей

включает следующий шаблон, отвечающий элементу book:

<xsl:template match="book">

<span style="font-style:italic">Автор: </span>

<xsl:value-of select="author"/><br />



</xsl:template>

Поскольку этот шаблон отвечает элементу book, элемент book

является текущим элементом в контексте шаблона. В связи с этим

доступ к дочерним элементам book осуществляется посредством

образца, содержащего только имя элемента, как в нашем примере:

<xsl:value-of select="title"/>

143

Примечание. Если вы не укажете атрибут select для элемента

apply-templates, браузер обрабатывает соответствующий шаблон (если он

имеется) для каждого дочернего элемента текущего элемента. В рассматри-

ваемом примере элемента apply-templates единственным дочерним элементом

для текущего элемента (корневая часть документа) является элемент

inventory, который не имеет соответствующего шаблона. Таким образом, если

вы опустите атрибут select, никакие данные не будут выведены.

Браузер обрабатывает шаблон book один раз для каждого

элемента book, отображая всю информацию о книгах, имеющуюся

в документе. При этом мы получаем то же отображение, что

и в предыдущем примере (см. Рис. 4.7).

4.4 ФИЛЬТРАЦИЯ И СОРТИРОВКА ДАННЫХ XML

В последующих двух подразделах вы познакомитесь с основами

применения XSL-таблиц стилей для фильтрации и сортировки

данных XML. После этого вам будут представлены примеры таблиц

стилей, демонстрирующие методики фильтрации и сортировки.

4.4.1 ФИЛЬТРАЦИЯ ДАННЫХ XML

Значение, которое присваивается атрибутам match или select,

представляет собой образец, соответствующий одному или несколь-

ким элементам в XML-документе. (Атрибут match используется для

элемента template, а атрибут select – для элементов value-of, for-each

и apply-templates). Образцы, с которыми вы имели дело до сих пор,

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

и, возможно, одного или нескольких вложенных элементов.

Вы можете ограничить количество элементов, отвечающих шабло-

ну, введя фильтр – выражение, заключенное в квадратные скобки ([ ])

и следующее непосредственно за оператором пути. Например,

образец, присвоенный следующему атрибуту match, указывает, что

соответствующий элемент должен носить имя book, и кроме того (это

определяется фильтром), должен иметь дочерний элемент binding,

который содержит текст "бумажный переплет":

<xsl:template match="book[binding='бумажный переплет']">

144

Если в фильтр включено только имя элемента, то соответствую-

щий элемент должен иметь дочерний элемент с указанным именем.

Например, следующий образец отвечает любому элементу ITEM,

имеющему дочерний элемент с именем CD, независимо от содержи-

мого элемента CD:

match="item[CD]";

Следующий образец отвечает любому элементу SHIRT,

имеющему дочерний элемент COLOR, содержащий текст "red":

match="shirt[COLOR=`red`]";

Примечание. Если элемент имеет более одного дочернего элемента

с именем, указанным в условии фильтрации, оператор сравнения применя-

ется только к первому дочернему элементу. Например, если элемент shirt

имеет два дочерних элемента COLOR, образец "shirt[ COLOR='red']" будет отве-

чать элементу, только если первый элемент COLOR содержит слово "red".

4.4.2 СОРТИРОВКА ДАННЫХ XML

Мы уже познакомились с двумя элементами, которые можно

использовать для обработки повторяющихся элементов: for-each

и apply-templates. Вы можете использовать атрибут order-by для этих

элементов, чтобы управлять порядком, в котором браузер обрабаты-

вает элементы, тем самым осуществляя сортировку данных XML.

Вы можете назначать атрибуту order-by один или несколько

образцов, разделяя их точкой с запятой. Браузер будет сортиро-

вать элементы с использованием образцов в том порядке, в котором

они перечислены. Для указания направления сортировки (по возрас-

танию или по убыванию) следует предварить образец префиксом

+ или – .

Например, атрибут order-by, установленный для следующего

элемента for-each, предписывает браузеру сортировать элементы book

по фамилиям авторов в порядке возрастания, а также осуществлять

сортировку для одинаковых фамилий по именам и по возрастанию:

<xsl:apply-templates select="inventory/book" order-by="+author/lastname; +author/firstname"/>.

В другом примере следующая установка order-by осуществляет сортировку элементов book по названиям книг по убыванию:

145

<xsl:apply-templates select="inventory/book" order-by="-title"/>.

Оператор пути, который вы присваиваете атрибуту order-by,

действует относительно образца, назначенного атрибуту select. Так,

в данном примере установка order-by="-title" указывает на элемент title

внутри элемента book, вложенного в элемент inventory.

4.4.3 XSL-ТАБЛИЦЫ С ФИЛЬТРАЦИЕЙ И СОРТИРОВКОЙ

В этом подразделе приведены два примера XSL-таблиц стилей.

Каждый из них осуществляет фильтрацию и сортировку элементов

book, подлежащих отображению. Обе таблицы стилей разработаны

для связывания с XML-документом CatalogXSL04.xml.

В них использован фильтр [binding='бумажный переплет'], предписы-

вающий браузеру отображать только книги, имеющие бумажный

переплет.

В обоих примерах используется следующая установка order-by,

задающая сортировку элементов book по возрастанию по фамилиям

авторов, а затем по именам авторов:

order-by="+author/lastname; +author/firstname".

Рассмотрим таблицу стилей CatalogXSL04.xsl, приведенную ниже.






<H2>Book Inventory</H2>

<xsl:for-each

select="inventory/book[binding='бумажный переплет']"

order-by="+author/lastname; +author/firstname">

<SPAN STYLE="font-style:italic">Author: </SPAN>


<SPAN STYLE="font-style:italic">title: </SPAN>


<SPAN STYLE="font-style:italic">Binding type: </SPAN>

<xsl:value-of select="binding"/><BR />

<SPAN STYLE="font-style:italic">Number of pages: </SPAN>


<SPAN STYLE="font-style:italic">Price: </SPAN>

146


</xsl:for-each>

</xsl:template>

</xsl:stylesheet>.

Данная таблица стилей использует элемент for-each для отобра-

жения множества элементов book. В этой таблице стилей для

элемента for-each установлены и фильтр, и атрибут order-by:

<xsl:for-each select="inventory/book[binding='бумажный переплет']"

order-by="+author/lastname; +author/firstname">



</xsl:for-each>.

На Рис. 4.8 показано, как выглядит первая часть выводимой

информации, которая является одинаковой для обеих таблиц стилей.

Рис. 4.8 Отображение общей части выводимой информации

147

Вторая таблица стилей для отображения множества элементов

book использует элемент apply-templates вместе с отдельными шабло-

нами, отвечающими элементам book. В этой таблице стилей фильтр

добавлен к шаблону, соответствующему элементам book:

<xsl:template match="book[binding='бумажный переплет']">.

Добавление фильтра к элементу apply-templates будет иметь тот же

эффект.

Атрибут order-by может быть добавлен к элементу apply-templates

следующим образом:

<xsl:apply-templates select="inventory/book"

order-by="+author/lastname; +author/firstname"/>

Атрибут order-by следует добавить к элементу apply-templates,

поскольку элемент template не распознает этот атрибут. (Вы можете

использовать атрибут order-by только для элемента, который указы-

вает браузеру осуществить просмотр среди множества элементов,

а именно, for-each и apply-templates).

Таблица стилей CatalogXSL05.xsl в целом приведена ниже.






<H2>Описание книг</H2>

<xsl:for-each select="inventory/book[binding='твердый']">






<xsl:value-of select="binding"/><BR />





</xsl:for-each>

</xsl:template>

148

</xsl:stylesheet>

4.5 ДОСТУП К АТРИБУТАМ XML

XSL трактует атрибут, принадлежащий элементу в XML-

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

в образце XSL вы должны предварить имя атрибута символом @, что

указывает на то, что имя относится к атрибуту, а не к элементу.

Например, фильтр в следующем начальном теге выделяет все

элементы book с атрибутом InStock, имеющем значение "yes". Другими

словами, он выбирает только книги, которые имеются в наличии:

<xsl:for-each select="inventory/book[@InStock='yes']">

Вы можете использовать XSL-элемент value-of для извлечения

значений атрибута точно так же, как вы это делаете для извлечения

текстового содержимого элемента. Например, следующий элемент

value-of получает значение атрибута ГодРождения, вложенного

в элемент author:

<xsl:value-of select="author/@ГодРождения"/>

Таблица стилей, представленная в файле CatalogXSL06.xsl, демон-

стрирует технику доступа к атрибутам, принадлежащим элементам

в XML-документе.






<H2>Книги в хранилище</H2>

<TABLE BORDER="1" CELLPADDING="5">

<THEAD>

<TH>Название</TH>

<TH>Автор</TH>

<TH>Тип переплета</TH>

<TH>Страницы</TH>

<TH>Цена</TH>

</THEAD>


<TR ALIGN="CENTER">

<TD ALIGN="LEFT"><xsl:value-of select="title"/></TD>

149

<TD>

<xsl:value-of select="author"/> <BR/>

(год рождения <xsl:value-of select="author/@ГодРождения"/>)

</TD>

<TD><xsl:value-of select="binding"/></TD>

<TD><xsl:value-of select="pages"/></TD>

<TD><xsl:value-of select="price"/></TD>

</TR>

</xsl:for-each>

</TABLE>

</xsl:template>

</xsl:stylesheet>

Эта таблица стилей связана с XML-документом CatalogXSL06.xml

и отображает все имеющиеся в наличии книги из каталога, для

которых атрибут InStock имеет значение 'yes'.





<inventory xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="CatalogXSL06.xsd">

<book InStock="yes">

<title>Приключения Гекльберри Финна</title>

<author ГодРождения="1835">Марк Твен</author>

<binding>прошитый бумажный переплет</binding>

<pages>298</pages>

<price>$5.49</price>

</book> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . <book InStock="no">

<title>Moby-Dick</title>

<author ГодРождения="1877">Herman Melville</author>

<binding>твердый переплет</binding>

<pages>724</pages>

<price>$9.95</price>

</book> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . <book InStock="yes">

<title>The Turn of the Screw</title>

150

<author ГодРождения="1878">Henry James</author> <binding>картонный переплет</binding> <pages>384</pages> <price>$3.35</price> </book> </inventory>

Каждый элемент book в XML-документе содержит атрибут InStock, имеющий значение "yes" или "no", указывающий наличие или отсут-ствие книги в хранилище.

Каждый элемент author имеет атрибут ГодРождения, содержащий год рождения автора.

Вместо отображения значения атрибута InStock таблица стилей

использует атрибут в условии фильтрации с целью избежать

отображения элементов book для книг, которых нет в наличии:

Рис. 4.9 Отображение элементов book в виде таблицы

151




<TR ALIGN="CENTER"> . . . . . . . . . . . </TR>

</xsl:for-each>

Таблица стилей отображает каждый элемент book в виде HTML-

таблицы, а не через список элементов SPAN, как в предыдущих

примерах. Она отображает значение атрибута ГодРождения после

значения элемента author, используя XSL-элемент value-of.

Следующие элементы создают ячейку таблицы для отображения

этих значений:

<TD>

<xsl:value-of select="author"/> <BR/>

(год рождения <xsl:value-of select="author/@ГодРождения"/>)

</TD>

На Рис. 4.9 показано, как браузер по расширяемой таблице

стилей CatalogXSL06.xsl отображает XML-документ CatalogXSL06.xml.

152


1. Что собой представляет таблица стилей CSS?

2. Назовите преимущества и недостатки таблиц стилей CSS.

3. Этапы создания таблицы каскадных стилей, отображающей

XML-документ.

4. Опишите структуру правила, содержащего информацию по

отображению элемента определенного типа в XML-документе.

5. Опишите структуру блока объявлений.

6. Опишите структуру объявления.

7. Каково основное назначение расширяемой таблицы стилей

XSL?

8. Какова структура шаблона преобразований XSLT?

9. Как с помощью XSLT создаются новые структурные единицы

документа (элементы, атрибуты и т. п.)?

10. Каков алгоритм преобразования XML-документа с помощью

языка XSLT?

11. Опишите конструкцию таблицы стилей на основе одного

шаблона.

12. Опишите конструкцию таблицы стилей для отображения

нескольких элементов XML-документе.

13. Опишите конструкцию таблицы стилей на основе нескольких

шаблонов.

14. Опишите конструкцию таблицы стилей с фильтрацией

отображаемых элементов.

15. Опишите конструкцию таблицы стилей с сортировкой

отображаемых элементов.

16. Опишите конструкцию таблицы стилей с доступом к атрибу-

там элементов.

17. Каково назначение последовательностей языка XSLT?

153

ГЛАВА 5. XFORMS – ЯЗЫК ОПИСАНИЯ ФОРМ ДЛЯ ВВОДА ДАННЫХ

Традиционные HTML-формы нарушают многие принципы языка

разметки, часто перемешивая представление и данные. XForms – это

усовершенствованная версия HTML-форм, которая предоставляет

расширяемые средства, позволяющие включать в HTML-документы

более богатые по возможностям и динамичности формы.

С помощью XForms можно ускорить и упростить создание Web-форм.

XForms допускают поддержку многочисленных устройств и структу-

рированных данных форм, как например XML-документы. Они

избавляют разработчиков от необходимости писать скрипты,

которые используются при генерировании динамических Web-форм,

необходимых как для объединения многочисленных форм на одной

и той же странице, так и управления данными. Наконец, хотя каждая

часть XForms, а именно: модель данных (data model), вид (view)

и контроллер (controller) – полностью отделима от других и может

использоваться с другими технологиями, важно осознать, что мощь

этих частей – в их объединении в приложении.

5.1 XFORMS – ТЕХНОЛОГИЯ СОЗДАНИЯ WEB-ФОРМ

Спецификация XForms была разработана консорциумом W3C

и совмещает в себе гибкость языка XML и смежных с ним техно-

логий. В целом данная технология была разработана для замены уже

морально устаревших классических форм, поддерживаемых

154

до этого. При этом технология XForms не только отправляет инфор-

мацию, но и имеет довольно широкие возможности для ее обра-

ботки, например:

– осуществляет проверку правильности отправляемых данных;

– имеет возможность взаимодействовать с протоколом SOAP;

– осуществляет обработку данных на стороне клиента, избавляя

от необходимости перезагружать страницу;

– обеспечивает совмещение серверной и клиентской обработки.

Однако существенным минусом этой технологии на данный

момент является то, что многие браузеры все еще не поддерживают

данную технологию, но отдельные решения уже появились.

К примеру, для браузера Mozilla Firefox был создан проект, который на-

зывается Mozilla XForms Project. Существуют и альтернативные реше-

ния, но проблема все еще актуальна, так как основная масса пользо-

вателей на данный момент не имеет реальную возможность ввода

данных с поддержкой технологии XForms.

5.1.1 HTML-ФОРМЫ И ИХ НЕДОСТАТКИ

Язык XForms, как и другие языки, рассмотренные нами выше,

реализован на основе стандартного обобщенного языка разметки

SGML. Как уже было отмечено, основное назначение языка SGML

заключается в том, чтобы отделить текстовое содержимое от его

представления, для этого содержание заключалось в машиночи-

таемые теги. А это, помимо всего прочего, означает, что разработкой

содержания и представления могут заниматься разные люди.

Язык гипертекстовой разметки HTML, также являющийся типом

SGML-документа, на сегодняшний день является основным средством

реализации форм для ввода данных. Недостатки этого языка, глав-

ным из которых является отход от принципа отделения содержимо-

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

Но благодаря тому, что он обеспечивал относительную простоту

создания Web-страниц, HTML получил повсеместное признание. После

стандартизации тегов HTML превратился в язык, который был

понятен любому Web-браузеру. Это привело к расширению сферы

его применения и усложнению технологии создания сайтов. Сайты,

155

изначально статические, превратились в динамические, и ограни-

чения языка, вызванные отходом от принципов SGML, становились

все более очевидными.

Листинг 1. Пример HTML-формы

<FORM action="http://www.example/ " method="post">

<P><INPUT type="radio" name="HairColor" value="Brown">Brown<BR></P>

</FORM>

В приведенном листинге жестко запрограммирован тип управ-

ляющего элемента, в данном случае радио-кнопки (type="radio"),

а элементы name = "HairColor" и value = "Brown" определены в пределах

одного кода. Таким образом, определяется пользовательский

интерфейс, который не может корректно изобразиться на платфор-

мах, не поддерживающих радио-кнопки.

Поскольку HTML не поддерживает принцип отделения содержи-

мого от представления, то в определение формы могут быть вклю-

чены вложенные данные, а изменения представления отдельной

формы является довольно сложной задачей. Ситуацию усугубляет

невозможность расширения набора HTML-тегов, что существенно

ограничивает возможность адаптировать язык под решаемую задачу.

С появлением расширяемого языка разметки XML и расширяя-

емого языка стилей XSL эти проблемы были частично сняты. Если

в HTML и данные, и их представление определялись в одном коде,

то в новой технологии для этой цели создавались два файла: XML-

документ с определениями данных и XSL-файл с инструкциями

визуализации этих данных. При этом значения полей name и value мо-

гут храниться как XML-данные, а их представление может опреде-

ляться как результат XSL-преобразования XML-документа в HTML.

Благодаря этим возможностям резко повысилась гибкость фор-

матирования данных, когда одно и то же XSL-преобразование может

быть применено для неограниченного количества XML-документов

одного типа. Кроме этого, одни и те же XML-данные могут быть

отображены в разных устройствах (настольных компьютерах, план-

шетах, смартфонах и т. д.) путем использования различных таблиц

стилей XSL.

156

Но следует иметь в виду, что перечисленные достоинства новой

технологии, придающие дополнительную функциональность средст-

вам отображения данных, приводят к усложнению технологии

форматирования.

Во-первых, повышается нагрузка на сервер, который изначально

был спроектирован для отображения статических HTML-файлов.

Реализация XSL-преобразований связана с выполнением циклической

обработки и множеством итераций обмена данными между клиен-

том и сервером, и требует гораздо больших вычислительных мощ-

ностей, чем для отображения статического текста.

Во-вторых, разработка XML-документа и расширяемой таблицы

стилей XSL требует привлечения программистов, чей профессиональ-

ный уровень должен быть гораздо выше, чем для работы с HTML.

5.1.2 XFORMS: СЛЕДУЮЩЕЕ ПОКОЛЕНИЕ WEB-ФОРМ

XForms – новый платформенно-независимый язык описания инте-

рактивных форм, основанный на XML, и может рассматриваться как

следующее поколение Web-форм, в котором решены проблемы,

свойственные HTML-формам.

Любая форма должна содержать описание данных, вводимых

с формы. Для реализации процесса ввода данных создается пред-

ставление в виде интерактивных полей, позволяющих пользователю

ввести необходимую информацию. В результате заполнения формы

получаются данные формы.

Web-формы, созданные в стандарте HTML, не в состоянии отде-

лить данные формы от их представления и имеют довольно ограни-

ченные возможности для отображения данных в форме.

Можно привести следующие преимущества XForms по сравнению

с HTML формами:

– вводимые и пересылаемые данные строго типизированы

и могут быть проверены с помощью XSD-процессора;

– в формах, реализованных на языке XForms, можно использовать

уже существующие схемы данных. Это позволяет избежать дубли-

рования данных и применять правила проверки данных формы,

заданные в XML-схеме;

157

– возможность включения дополнительных ограничений, зада-

ваемых в XForms модели, расширяет сферу применимости конечного

Web приложения. Это позволяет разработчику формы не ограничи-

ваться набором базисных ограничений XML-схемы, объявленных во

внешней схеме;

– возможность представления данных в виде XML обеспечивает

передачу данных формы от Web-сервера прямо приложению-обра-

ботчику без выполнения какой-либо предварительной обработки

данных;

– использование формата XML обеспечивает сохранение данных

на любом языке с учетом национальных особенностей;

– элементы пользовательского интерфейса являются обобщен-

ными и не зависят от платформы;

– высокий уровень абстракции элементов пользовательского

интерфейса делает возможным вывод информации на различные

устройства.

Данная спецификация предполагает, что браузеры, снабженные

XForms-процессорами, могут отображать формы XForms, размещенные

на клиентских машинах. Это существенно сокращает трафик сети

и снижает нагрузку на сервер, связанную с повторными обращения-

ми к нему с целью модификации Web-формы при изменениях

данных.

Принципиально важным новшеством является то, что в специ-

фикации XForms решено выделить модель данных формы (model), вид

(view) и контроллер (controller) на разных уровнях. Этим обеспечивает-

ся их многократное использование. Кроме этого, XForms дифферен-

цирует вид формы на ее презентацию (presentation) и предназначение

(purpose).

Выделение модели данных XForms в отдельный компонент позво-

ляет отделять описание структур данных от элементов управления

(далее контролов), используемых для отображения значений

данных. Поэтому в XForms предусмотрены средства связывания

данных с элементами управления. В XForms также заданы деклара-

тивные средства определения поведения каждой отдельной единицы

данных при возникновении той или иной ситуации.

158

Контролы XForms определены абстрактно, что предполагает

наличие их различных реализаций. Это позволяет создавать для

каждого контрола реализации для применения на разных платфор-

мах. Например, если в HTML тег <radioButton> имеет только одну

презентацию для всех платформ, то в XForms контрол <select> может

быть «выпадающим» меню в браузере настольного компьютера или

списком радио-кнопок в смартфоне. Но назначение контрола от

этого не меняется, пользователь и в том, и другом случае получает

возможность выбирать единственный элемент из набора.

5.1.3 ДЕКЛАРАТИВНОСТЬ XFORMS

Имеется еще одно достоинство спецификация XForms, о котором

следует сказать особо – это возможность декларативного определе-

ния обработчиков событий. В HTML-формах кроме нескольких

специальных событий, инициируемых кнопками submit и reset,

остальные события, такие как установка фокуса в поле ввода, вывод

сообщения, установка значения и др., требуют написания обработ-

чика на языке сценария. С целью сокращения потребности в сцена-

риях, Рабочие группы HTML и XForms совместно разработали общую

структуру события, называемую XML Events и обеспечивающую XML-

интерфейс для событий DOM Level 2. Именно эта модель допускает

определение действий XForms на языке разметки (markup-based actions)

без написания сценария (script-free).

Чтобы понять, каким образом в Xforms обеспечиваются описан-

ные возможности, необходимо иметь в виду, что формы использу-

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

понятие в Xforms, – это «данные экземпляра» (instance), т. е. представ-

ление данных, отображаемых на «контролах формы». При этом

данные экземпляра реализованы на XML, а его элементы определяют-

ся в терминах XPath.

Связь между XPath и XForms может показаться странной. Язык

XPath широко используется в XSLT, но не является привычным сред-

ством при создании Web-форм. Однако, по мере развития XForms,

стало очевидно, что формы нуждаются в более детальном структу-

рировании данных, чем представление их в виде простых пар

159

значений и названий. Например, часто приходится выделять части

структурированных данных и «связывать» их с контролами формы.

Именно для этих целей целесообразно применить XPath.

Так как XForms и XSLT связаны через XPath, интересно сравнить

эти технологии форматирования данных. При преобразованиях XML-

документов с помощью XSLT участвуют три дерева, формируемые

при разборе XML-документов (см. Рис. 4.2):

– исходное дерево представляется преобразуемым XML-

документом;

– второе дерево представляется таблицей стилей в виде XSLT-

документа;

– третье выходное дерево представляется HTML-документом.

Обработка с помощью XForms реализуется аналогично, но при

этом входное и выходное деревья представляются XML-документом.

1. Из входного XML-документа (встроенного или считанного

с удаленного Web-сервера) «данные экземпляра» после разбора

(анализа) отправляются в память;

2. Обработка «данных экземпляра» включает в себя взаимодей-

ствие формы с пользователем и регистрацию в памяти любых изме-

нений данных, производимых пользователем.

3. Под управлением контрола submit измененные «данные экземп-

ляра» сериализуются и отправляются серверу в виде XML-документа.

Обработка данных в Web-формах заключается не просто в их

сборке, но и в выполнении дополнительной обработки, связанной

с вычислениями, проверкой корректности и т. д. Как уже было отме-

чено, в HTML-формах такая обработка достигается через написание

сценариев. Цель XForms состоит в том, чтобы при разработке

Web-форм практически исключить необходимость в создании сце-

нариев. Этого можно добиться через обеспечение поддержки языка

XForms следующими стандартами платформы XML:

– описанием элементов XML-документа в определении формы

в терминах языка XPath;

– поддержкой синтаксических и семантических ограничений

типов данных, определенных в спецификации XML-схемы.

160

Описание элементов или узлов в «данных экземпляра» в виде

XPath-выражений обеспечивает определение структур для вычисле-

ний, проверок корректности, а также для вывода их на контролы.

Поддержка типов данных XML-схемы позволяет накладывать на

XML-данные декларативные ограничения (в виде лексических значе-

ний, длины, количества экземпляров и т. д.), поддерживаемые XSD-

процессором, и таким образом, исключающие написание сценариев

для их обработки.

Исходя из описанных принципов, был разработан элементно-

ориентированный декларативный синтаксис языка XForms, используя

который разработчики, вместо написания сценариев, могут просто

объявить в формах:

– установление фокуса на элементе управления формы;

– отображение сообщения для пользователя;

– осуществление навигации к новому URI;

– изменение значения узла экземпляра данных;

– инициацию перевычисления, перепроверки корректности

данных или обновление экрана;

– передачу (submit) или сброс (reset) всех или части экземпляров

данных;

– выполнение действий, связанных с прокруткой и манипуля-

цией строками таблиц.

5.2 СОЗДАНИЕ ФОРМЫ НА ЯЗЫКЕ XFORMS

В этом разделе мы покажем, каким образом, используя всего

лишь небольшое количество основных XForms-тегов, решаются

поставленные задачи. Мы рассмотрим синтаксис этих тегов, их

использование, а также смысл некоторых атрибутов.

5.2.1 ОПИСАНИЕ ФОРМЫ ДОКУМЕНТА

Для знакомства со структурой формы и синтаксисом XForms

рассмотрим пример реализации формы, используемой для выполне-

ния заказа товара. Эта форма заказа состоит из разделов, предназна-

ченных для ввода информации о клиенте, подсчета цены и перечис-

ления приобретенных товаров.

161

Описание формы XForms состоит их двух частей. Первая часть

описывает данные, которые вводятся через данную форму, и пред-

ставляет собой модель формы (см. раздел «XForms-модель»). Вторая

часть описывает способ отображения формы (см. раздел «Пользова-

тельский интерфейс XForms») и определяет независящий от устройст-

ва пользовательский интерфейс, используя множество независящих

от платформы элементов управления формы, пригодных для обоб-

щенного использования.

В первой части описания описывается схема данных формы,

логические ограничения и связи между полями формы. Здесь допус-

кается использование формул для:

– описания зависимостей значений полей друг от друга;

– проверки допустимости значений, вводимых в поля формы.

В схеме XForms описываются следующие ограничения:

– фиксированные ограничения, которые обрабатываются

процессором XForms только один раз;

– вычислимые выражения. Это XPath выражения, результатом

которых является некоторое значение. Эти выражения описывают

динамические ограничения, такие как связи и зависимости между

различными элементами данных.

Также обратите внимание на то, что поскольку в настоящий

момент браузеры не располагают XForms-процессорами, изображения

всех примеров – это всего лишь иллюстрации, которые не являются

результатом реализации XForms.

В Листинге 2 приведена схема кода для формы заказа с выде-

ленными частями описания данных и их визуального представления:

Листинг 2. Скелет кода для формы заказа

<HTML xmlns = "http://www.w3.org/1999/xhtml"

xmlns:Xforms = "http://www.w3.org /2002/01/xforms"

xmlns:ev = "http://www.w3.org/2001/xml-events"

xmlns:xlink = "http://www.w3.org/1999/xlink">

<head>

<title>XForms: Order Form</title>

162

<xforms:model>



</xforms:model>

</head>

<body>



</body>

</HTML>

В данном подразделе проанализируем этот код по частям: в пунктах 5.2.2.1 - 5.2.2.3 подраздела – часть кода «Экземпляр XML-

документа и Логические компоненты», а в пунктах 5.2.3.1 - 5.2.3.3 – часть кода «Пользовательский интерфейс».

Описания синтаксических конструкций языка XForms, а также примеры, иллюстрирующие их работу, основаны на материалах статьи [37]. Общая структура экранной формы, генерируемой по XForms-документу, фрагменты которого описываются в данной главе пособия, изображена на Рис. 5.1.

Рис. 5.1 Изображение формы заказа

163

5.2.2 XFORMS-МОДЕЛЬ ДОКУМЕНТА

Поскольку XForms-модель представляет содержание формы, она

не изменяется от представления к представлению.

1. Модель состоит из данных формы и логических компонентов.

2. Данные формы находятся в пределах instance (подробнее о нем

ниже), включающего:

– все поля формы;

– временное хранилище.

3. Логические компоненты формы определяют ее поведение.

Эти логические компоненты описываются:

– связыванием данных (data bindings);

– обработчиками событий (event handlers);

– информацией об инициализации (submission information).

5.2.2.1 О п р ед е л е н и е э к з е м п л я р а д ан н ы х ф о р м ы

Данные экземпляра документа, вводимого с помощью формы,

определяются в пределах модели. Такие данные в XForms называются

instance и содержатся в пределах тега <model>. Именно эти данные

передаются в обработчик или во временное хранилище, используе-

мое в пределах модели. Каждый instance может содержать только

одиночное дерево XML-данных. Другими словами, instance как XML-

документ может содержать только один корневой узел.

Данные instance могут определяться локально в пределах модели

или указываться с помощью URI на XML-данные, хранящиеся на

удаленной машине. В Листинге 3 показан раздел instance элемента

OrderInfo, определенный локально в форме заказа.

Листинг 3. Определение локального instance

<xforms:model>

<xforms:instance>

<OrderInfo>



<PersonalInfo>

<Name>

<First></First> <Middle></Middle> <Last></Last>

</Name>

164

<Address>

<Street></Street> <City></City> <State></State><Zip></Zip>

</Address>

</PersonalInfo>

<!—Раздел вычисления стоимости заказа -->

<PriceInfo>

<SubTotal></SubTotal>

<TaxTotal></TaxTotal>

<TaxRate></TaxRate>

<Total></Total>

</PriceInfo>



<TaxInfo>

<CT>.060</CT>

<NY>.085</NY>

<NJ>.083</NJ>

</TaxInfo>



<ShoppingCart>

<ProductInfo name="itm1">

<Quantity>5</Quantity>

<Description>Wht. Chocolate Bars</Description>

<UnitPrice>1.45</UnitPrice>

<ItemTotal></ItemTotal>

</ProductInfo>



<Description>Blk. Chocolate Bars</Description>



</ProductInfo>



<Description>Car. Filled Choc</Description>



</ProductInfo>

</ShoppingCart>

165

</OrderInfo>

</xforms:instance> . . . . . . . . . . . . . . </xforms:model>

Объявление данных OrderInfo, приведенное в Листинге 3, состоит

из четырех основных компонентов:

– PersonalInfo содержит все информацию, которую вы хотите

получить от пользователя;

– PriceInfo включает сведения, необходимые для вычисления

стоимости заказа;

– TaxInfo содержит информацию о ставках налога в некоторых

штатах (для простоты этот пример определяет ставку только для

штатов Нью-Йорк (NY), Коннектикут (CT) и Нью-Джерси (NJ));

– ShoppingCart – список товаров.

Обычно под данными формы понимается информация, вводимая

пользователем в поля формы. Тег <instance> может определить только

структуру данных или может включить начальные значения.

Но в разделах PriceInfo и TaxInfo показывается, что в качестве данных

instance можно использовать и временную, и постоянную информа-

цию.

Данные, определенные instance, не обязательно должны быть

определены локально, они могут быть определены во внешних URI.

В Листинге 4 показано, как можно реализовать instance при обраще-

нии к удаленному XML-ресурсу.

Листинг 4. Обращение к удаленному XML-ресурсу

<xforms:model>

<xforms:instance href="http://www.example.com/OrderFormData.xml"/> . . . . . . . . . . . . . . </xforms:model>

5.2.2.2 С в я з ы в а н и я , з а в и с и м о с т и и о гр а н ич е н и я

В данном подразделе модели данных формы опишем, каким

образом осуществляются связывания, зависимости и ограничения

вводимых данных.

Существуют два способа присвоения значений данным instance

в XForms:

166

– данные могут зависеть от других данных и нужно каким-то

образом описать эту зависимость;

– данные могут быть связаны с входными данными, предостав-

ляемыми пользователем.

В этом пункте рассмотрим первый способ; второй – связывание

входных данных пользователя – будет рассмотрен в следующем

пункте «Пользовательский интерфейс XForms».

Для описания зависимостей между данными в пределах тега

<model> определяется тег <bind>, внутри которого задается выражение

зависимости между данными instance. Например, инструкция bind

в Листинге 5 связывает TaxTotal с вычисляемым налогом SubTotal.

В соответствии с этой инструкцией для определения значения

OrderInfo/ PriceInfo/TaxTotal значение OrderInfo/PriceInfo/TaxRate умножается на

значение OrderInfo/PriceInfo/SubTotal. Обратите внимание на то, что для

определения элементов TaxTotal, TaxRate и SubTotal применены выраже-

ния языка XPath.

Атрибут ref ссылается на узел TaxTotal.

Листинг 5. Инструкция bind



<xforms:bind ref="/OrderInfo/PriceInfo/TaxTotal"

calculate="/OrderInfo/PriceInfo/TaxRate * /OrderInfo/PriceInfo/SubTotal"/>.

Атрибут calculate связывает значение элемента TaxTotal с произве-

дением элементов TaxRate и SubTotal.

Для определения условий, при которых тег bind является допус-

тимым, вы можете воспользоваться атрибутом relevant. Пример

использования атрибута relevant приведен в Листинге 6:

Листинг 6. Инструкция bind с атрибутом



<xforms:bind ref="/OrderInfo/PriceInfo/TaxRate"

calculate="/OrderInfo/TaxInfo/CT"

relevant="/OrderInfo/PersonalInfo/Address/State = 'CT'"/>.

Приведенная инструкция присваивает переменной TaxRate ставку

налога в штате Коннектикут (CT) только в том случае, если пользо-

167

ватель живет в этом штате. Именно это условие задано с помощью

атрибута relevant.

Для выполнения этой процедуры для двух других штатов Нью-

Йорк и Нью-Джерси определите аналогичные инструкции, связав

TaxRate со значением соответствующего штата, т. е. OrderInfo/TaxInfo/NY

и OrderInfo/TaxInfo/NJ.

Вы можете также учитывать в теге <bind> ограничения типов

данных instance, например, указав тип данных с помощью атрибута

type. В Листинге 7 показано, как определить, чтобы в поле SubTotal

должно быть введено десятичное число:

Листинг 7. Инструкция bind и ограничение типа



<xforms:bind ref="/OrderInfo/PriceInfo/SubTotal" type="xs:decimal"/>.

При наличии таких ограничений XForms-процессор сверяет

введенные данные instance, проверяя поле за полем на соответствие

этим ограничениям. Если пользователь вводит данные, которые

нарушают эти ограничения, браузер, поддерживающий XForms,

выдаст сообщение об этом пользователю. Благодаря этому снижа-

ется количество ошибок при кодировании, а обработчик получает

только правильно оформленные данные.

5.2.2.3 И н и ц и а л и з а ция

В рамках модели данных формы определяется также способ

связи с сервером обработчика. Это необходимо для вызова серве-

ром обработчика, запускаемого при готовности пользователя

к инициализации. Для этого вы можете использовать тег <submission>

и атрибут action (см. Листинг 8):

Листинг 8. Инструкция инициализации



<xforms:submission id="submit1" action="http://www.example/" method="post"/>.

В рамках тега <submission> можно также задать HTTP-метод, указав

в качестве атрибута method значения get или post. Для инкапсуляции

XML-содержания рекомендуется использовать метод post.

168

В пределах одной и той же модели можно определить множе-

ство блоков <submission>. Поэтому каждому тегу <submission> необхо-

димо задать уникальный идентификатор с атрибутом id (в приведен-

ном примере id=" submit1"), поскольку в пользовательском интерфейсе

эти теги будут связаны с кнопками submit (см. описание инструкции

submit).

5.2.3 ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС XFORMS

Пользовательский интерфейс определяет, как элементы instance

модели данных отображаются на форме. Он выражается с помощью

как элементарных (как, например, <input> и <output>), так и составных

(<group>, <repeat> и <switch>) контролов.

Элементарные компоненты – это те элементы управления, кото-

рые используются для наполнения формы.

Составные компоненты пользовательского интерфейса приме-

няются для организации и группировки элементарных объектов.

Как было указано выше, в отличие от HTML, и элементарные,

и составные контролы не связаны с отдельным представлением,

а соотносятся с отдельной абстрактной задачей.

Описание пользовательского интерфейса будет проведено не

в порядке следования его компонентов в коде, а в виде иллюстрации

примеров использования контролов языка XForms в рассматриваемом

коде формы заказа.

5.2.3.1 Э л е м е н т а р н ы е к о н т р о л ы ф о р м ы

Элементарные контролы – это базовые компоненты, которые

используются для ввода и отображения данных в пользовательском

интерфейсе. Вы можете комбинировать эти контролы в составных

контролах, описанных ниже. В данном пункте рассмотрим основные

элементарные контролы.

Контрол input. Наиболее часто используемым контролом

формы является контрол для ввода данных <input>. Пример контрола

<input>, используемого в форме для ввода индекса адреса приведен

в Листинге 9:

169

Листинг 9. Инструкция input

 <xforms:input class="ZipCode" id="zipcode" ref="OrderInfo/PersonalInfo/Address/ZipCode"> <xforms:label class="label">Zip Code</xforms:label> <xforms:hint>Enter The Zip Code</xforms:hint> </xforms:input>

В данном листинге с помощью атрибута ref определяется выра-

жение XPath, локализующее входной элемент данных, значение

которого вводится с помощью данного контрола. Поскольку атрибут

ref использует XPath, чтобы установить расположение instance, в случае

совпадения множества узлов (например, многочисленных узлов

ShoppingCart/ProductInfo/Quantity), этот атрибут выбирает первое совпа-

дение, если только разработчик не установил явно, какой конкрет-

ный элемент Quantity выбирать. В нашем примере значение, которое

пользователь вводит в поле ввода, связано с единственным элемен-

том /OrderInfo/PersonalInfo/Address/ZipCode, поэтому необходимости

в таком определении элемента нет.

В данном примере в определении контрола <input> добавлен заго-

ловок поля ввода. Для этого введен тег <label> в виде потомка тега

<input>. Тег <label> является факультативным тегом, который может

быть создан в пределах каждого контрола формы.

В определении контрола <input> можно ввести также подсказку

для пользователя, которую он сможет прочесть при установке

мышки на поле ввода на форме. Для этого создается тег <hint> в виде

потомка тега <input>.

Контрол output. Контрол <output> не предполагает действий

оператора, а просто отображает значения данных instance на форме.

В примере, приведенном в Листинге 10, контрол output используется

для отображения значения вычисленного налога:

Листинг 10. Инструкция output



<xforms:label class="label">Tax Amount $</xforms:label>

<xforms:output class="Amount" id="taxtotal" ref="OrderInfo/PriceInfo/TaxTotal"/>.

170

Синтаксис определения этого контрола во многом схож с син-

таксисом контрола <input>; единственное различие состоит в том, что

<output> используется только для чтения.

5.2.3.2 С о с т а в ны е к о н т р о л ы

С помощью составных контролов вы можете распределить

элементарные объекты по разделам, например, раздел адреса, раздел

платежа и раздел товаров, и размещать их на площади формы

в соответствии со структурой, определенной в разделе instance модели

данных. Таким образом, с помощью составных тегов <group>, <repeat>

и <switch> можно организовать сложный пользовательский интер-

фейс, на котором структурные взаимосвязи между отдельными

элементами модели данных определяются неявно путем их соответ-

ствующего размещения на форме.

Контрол group – это простейший составной контрол и пред-

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

В Листинге 11 показано, как группировать различные контролы

формы, чтобы затем использовать эту группу в качестве отдельного

сложного объекта на форме.

Листинг 11. Фрагмент описания формы, содержащей поля вво-

да персональных данных клиента

<body>

<xforms:group> <div>

 <xforms:input class="First" id="first" ref="OrderInfo/PersonalInfo/Name/First"> <div> <xforms:label>First Name</xforms:label> </div> <xforms:hint>Enter First Name</xforms:hint> </xforms:input> <xforms:input class="Middle" id="middle" ref="OrderInfo/PersonalInfo/Name/Name/Middle"> <xforms:label class="label">Middle Initial</xforms:label> <xforms:hint>Enter Middle Initial</xforms:hint> </xforms:input>

171

<xforms:input class="Last" id="last" ref="OrderInfo/PersonalInfo/Name/Name/Last"> <xforms:label class="label">Last Name</xforms:label> <xforms:hint>Enter Last Name</xforms:hint> </xforms:input> </div> <div>

 </div> <br/> <div>

 </div> <br/> <div>

 </div> <br/>

</xforms:group>

</body>.

Спецификация W3C XForms описывает тег <group> как «контейнер

для определения иерархии контролов». Этот контрол используется

для визуального представления данных в древовидной форме.

Контрол repeat. Контрол repeat позволяет уменьшить избыточ-

ный код в форме. С этой целью разработчики могут создать шаблон

пользовательского интерфейса и применить к набору данных instance

с одинаковой структурой. В примере формы заказа тег repeat исполь-

зован для отображения данных о приобретенных товарах

(см. Листинг 12).

Листинг 12. Пример использования инструкции repeat

<xforms:repeat id="shoppingcart" nodeset="OrderInfo/ShoppingCart/ProductInfo">

<xforms:output ref="Quantity"/>

<xforms:output ref="Description"/>

<xforms:output ref="UnitPrice"/>

<xforms:output ref="ItemTotal"/>

</xforms:repeat>.

В этом примере вместо явного кодирования контрола пользова-

тельского интерфейса для каждого товара используется тег <repeat>,

который создает шаблон элемента узла OrderInfo/ShoppingCart/ProductInfo

172

в instance, XPath-адрес узла которого определяется с помощью

атрибута nodeset.

Для ссылки на значения полей в поддереве ProductInfo использу-

ется атрибут ref. Вы можете также сослаться на значения атрибута,

предварительно пометив выражение XPath символом @. Например,

вы могли бы обратиться к атрибуту name в каждом ProductInfo посред-

ством вызова ref = "@name".

Этот тег повышает выразительную мощь языка XForms и позво-

ляет создавать более короткие XForms-документы: вам не нужно

точно знать, сколько товаров приобретено; тег автоматически

обойдет дерево instance и выдаст данные для каждого возможного

соответствия.

Контрол switch предназначен для построения гибких форм,

которые в зависимости от текущих условий формируют тот или

иной фрагмент пользовательского интерфейса. Для определения

условий в пределах инструкции <switch> находятся инструкции <case>,

с помощью которых и определяются условия для формирования

требуемого пользовательского интерфейса.

Например, при работе с формой по получении личной информа-

ции поставщики могут захотеть установить метод платежа. В этом

случае может быть использован тег <switch> для перехода к типу пла-

тежа, который выбрал пользователь. Если пользователь избрал пла-

теж с помощью кредитной карты, форма генерирует необходимый

для этого набор контролов пользовательского интерфейса. Если же

пользователь решил платить наличными или выбрал еще какой-

нибудь иной способ, форма генерирует другой набор визуальных

компонентов. Таким образом, тег <switch> позволяет пользователю

управлять интерфейсом.

Описанный контрол в создаваемой нами форме не используется,

поэтому в Листинге 13 приведен простой пример для описанной

выше ситуации. В соответствии с приведенным описанием форма

ожидает ввода имени пользователя. Как только пользователь введет

свое имя, вариант инструкции switch меняется и появляется привет-

ствие "Hello" вместе с именем пользователя.

173

Листинг 13. Пример использования инструкции switch

<switch id="sw">

<case id="in" selected="true">

<input ref="yourname">

<label>Please tell me your name</label>

<action ev:event="activate">

<toggle case="out" />

</action>

</input>

</case>

<case id="out" selected="false">

<p>

Hello

<output ref="yourname"></output>

<trigger id="editTrigger">

<label>Edit</label>

<action id="editAction" ev:event="activate">

<toggle case="in" />

</action>

</trigger>

</p>

</case>

</switch>.

Таким образом, спецификация XForms предусматривает создание

динамических форм посредством задания условий, зависящих от

данных. Вам больше не нужно писать код для каждой отдельной

ситуации, пользовательские формы будут генерироваться «на лету»

при сборе данных и изменении условий.

5.2.3.3 А к т и в ны е к о нт р о лы

Контрол action. Контрол <action> является XML-обработчиком

событий. Поскольку он поддерживается набором декларативно

вызываемых XML-обработчиков, реагирующих на стандартные

действия пользователя, отпадает необходимость в написании слож-

ных скриптов. Благодаря упаковке событий формы в набор легко

вызываемых тегов, становится несложно определить ее динами-

174

ческое содержание и гарантировать работу формы на всех платфор-

мах, поддерживающих XForms.

В Листинге 14 продемонстрировано определение действия

refreshForm. Атрибут event устанавливает, на какое событие должен

реагировать тег <action>.

Листинг 14. Инструкция action



<xforms:action event="click" >

<xforms:refresh ev:event="xforms:activate"/>

</xforms:action>.

При возникновении события, заданного атрибутом event, обра-

ботчик событий перехватывает это событие и генерирует действие

<refresh>.

В одном теге <action> можно задать множество действий. Когда

обработчик событий активирован, он вызывает все действия, опре-

деленные в пределах своего тела.

Контрол trigger выполняет действие при активации. Например,

при щелчке мышки на кнопке срабатывает контрол trigger. При акти-

вации trigger вызывает XML-событие, перехватываемое обработчиком

событий, описанным с помощью тега <action>. Пример определения

контрола trigger приведен в Листинге 15:

Листинг 15. Инструкция trigger без указания события



<xforms:trigger>

<label>My Refresh Trigger</label>

</xforms:trigger>.

Но в этом определении не указано событие, на которое нужно

реагировать, поэтому этот trigger ничего не делает. Для того чтобы

он что-нибудь выполнил, необходимо встроить в его состав дейст-

вие, определенное с помощью контрола action. Определение триг-

гера, реагирующего на заданное событие, приведено в Листинге 16.

Листинг 16. Работающая инструкция trigger



175

<xforms:trigger>

<xforms:label>Reset</xforms:label>

<xforms:action event="click" >

<xforms:refresh ev:event="xforms:activate"/>

</xforms:action>

</xforms:trigger>.

При щелчке мышки на кнопке "Reset" trigger запускает событие

event, которое перехватывается обработчиком событий тега <action>.

В результате вызывается действие <refresh>.

176


1. Каковы недостатки Web-форм?

2. Каковы особенности технологии XForms в отличие от Web-

форм?

3. Что собой представляют данные instance?

4. Что собой представляют обработчики событий (event handlers)?

5. Что собой представляет связывание данных (data bindings)?

6. Что собой представляет информация об инициализации

(submission information)?

7. Как в XForms представляются связывания, зависимости и огра-

ничения данных?

8. Опишите инструкцию инициализации.

9. Опишите составной контрол group.

10. Опишите составной контрол repeat.

11. Опишите составной контрол switch.

12. Опишите элементарный контрол input.

13. Опишите элементарный контрол output.

14. Опишите контрол action.

15. Опишите контрол trigger.

16. Опишите контрол submit.

17. Из каких компонентов состоит модель XForms?

18. Объясните природу данных и логических компонентов

формы.

19. Опишите составные части логического компонента XForms.

20. Перечислите достоинства XForms.

21. Каким образом контролы XForms связываются с элементами

модели данных?

177

ГЛАВА 6. RDF – ЯЗЫК ПРЕДСТАВЛЕНИЯ СЕМАНТИКИ ДАННЫХ

Наиболее важной заслугой XML является то, что программы

различных производителей получили возможность «разговаривать»

на одном языке. Взамен многочисленных разрозненных способов

представления данных появился один универсальный синтаксис,

который лег в основу передачи информации между программами,

работающими в различных точках Интернета.

Однако постепенно с течением времени мировое сообщество

приходит к пониманию того, что позволяя закодировать любую

информацию и давая разработчику возможность без особого труда

получить синтаксический анализатор и средства манипулирования

данными, XML не в состоянии адекватно справиться с задачей семан-

тической интероперабельности.

В основе этого понятия лежит способность машин не только

читать, но и понимать содержание Интернет-ресурсов, причем

достигнуть этого мы должны не через создание программ искусст-

венного интеллекта, моделирующих деятельность человека, а через

использование средств выражения семантики данных и их связей.

6.1 ПРОБЛЕМЫ ОПИСАНИЯ СЕМАНТИКИ ДАННЫХ

Использование семантической информации предполагает обес-

печение связывания данных, размещающихся в разных узлах Сети,

по смыслу. Но для представления семантической информации суще-

178

ствующие на то время стандарты оказались не пригодными. Необ-

ходимо было создавать новые стандарты структурирования данных,

обеспечивающие возможность семантического связывания ресурсов,

распределенных в глобальной Сети.

С этой целью в 1998 году Тимом Бернерсом-Ли, изобретателем

WWW, URI, HTTP и HTML, была предложена идея создания Semantic

Web [38]. Согласно этой идее Web представляется в виде сети

информационных узлов, которые связаны друг с другом таким

образом, чтобы имеющаяся информация могла легко обрабаты-

ваться компьютером.

Таким образом, было положено начало следующему этапу

развития Web, который ориентируется на технологии, обеспечиваю-

щие возможности семантической интероперабельности. Идея Semantic

Web представляется логическим продолжением развития Web – от

гипертекстовых страниц к XML-данным, от XML – к машинной интер-

претации данных и объединению разбросанной во Всемирной

паутине информации по смыслу. При этом была заложена тенденция

развития Web-технологий, заключающаяся в переходе от докумен-

тов, которые «читаются компьютером», к документам, которые

«понимаются компьютером».

Но при этом создатели средств выражения семантики данных

и их связей столкнулись с несколькими проблемами. С одной

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

предметной области, с другой стороны, должны уметь сопоставлять

связанные термины различных предметных областей.

Относительно связанности терминов предметных областей

можно привести следующий пример. Предположим, что в одной

точке глобальной сети размещены данные о какой-то компании и ее

сотрудниках, в другой точке – информация о людях, в третьей – об

адресах.

Очевидно, что компании, люди и адреса принадлежат к отдель-

ным, относительно независимым областям знаний или предметным

областям. Но в непрерывном информационном поле программа,

обеспечивающая семантическую интероперабельность, должна

сопоставлять компании и людей, а также адреса этих людей.

179

Это требование является существенным, поскольку в против-

ном случае программы могли бы работать лишь с отдельными

сферами знаний, описанными, например, специализированными

XML-языками.

Итак, если синтаксическая интероперабельность неразрывно

связана с синтаксическим анализом данных, то семантическая

требует анализа самой информации, ее связи с мировым информа-

ционным полем, установления соответствия терминов и словарей

одной предметной области элементам другой [39].

XML не может стать таким средством, обеспечивающим связь

данных различных предметных областей, по ряду причин.

1. Основное ограничение XML состоит в том, что он описывает

только грамматику данных. Выделить семантическую единицу

в конкретной предметной области нельзя, поскольку этот язык

ориентирован на структуру документа и не предполагает интерпре-

тации данных, содержащихся в нем.

2. XML оказывается слишком гибким средством описания данных

и позволяет одну и ту же информацию разметить различными

способами. В качестве иллюстрации сказанного можно привести

несколько вариантов представления данных о человеке:

<Человек>

<Фамилия>

Иванов

</Фамилия>

<Рост>185</Рост>

</Человек>

<Человек Фамилия="Иванов" Рост="185" />

<Человек Фамилия="Иванов"> <Рост>185</Рост> </Человек>

С этой проблемой можно было бы попытаться справиться одним

из двух способов: либо всем заинтересованным сторонам догово-

риться об используемом формате описания, либо прибегать к преоб-

разованию одной грамматики в другую.

Но первый из этих способов не реален, поскольку заинтересо-

ванных сторон, как правило, много и состав их регулярно меняется,

а второй способ очень громоздок, и оба они, по-прежнему,

не решают проблему выделения семантической единицы предмет-

ной области.

180

Поэтому для эффективного представления фактов необходимо

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

автоматически (с помощью программных средств) анализировать

содержание ресурсов. А для этого необходимы новые средства

выражения семантики данных, которые были созданы в рамках

развития идеи Semantic Web.

6.2 SEMANTIC WEB – СОСТАВ И ЭТАПЫ РАЗВИТИЯ

В соответствии с определением, данным своим работам членами

W3C Semantic Web Activity, Semantic Web, – это расширение Web, в котором

информации (или данным) придается определенная семантика,

позволяя «людям и машинам работать вместе».

Целью проекта Semantic Web является внедрение в Web-среде

таких технологий, которые должны:

– позволить существенно повысить уровень интеграции инфор-

мации;

– обеспечить развитую машинную обработку данных;

– дать возможность выдавать более адекватные ответы на поис-

ковые запросы и т. д.

На сегодняшний день идея Semantic Web постоянно эволюциони-

рует и прошла следующие этапы развития.

1. Первый шаг на пути перехода на новый уровень представле-

ния данных был сделан в ходе разработки графовой модели описа-

ния ресурсов RDF (Resource Description Framework), позволяющей объеди-

нять информацию из различных источников. В рамках графовой

модели RDF факты описываются ориентированным графом,

представленным двумя узлами и связью между ними.

2. На втором этапе был создан RDF/XML-синтаксис, который дает

возможность представить RDF-данные графовой модели в XML-

форме. Относительно связи RDF с XML следует иметь в виду, что

графовая модель RDF с помощью языка XML представляется в тексто-

вой форме, пригодной для передачи по каналам связи и программ-

ной обработки. Применение языка XML для представления этой

модели, кроме этого, дает разработчикам возможность воспользо-

ваться для обработки содержащихся в ней данных всеми его

181

преимуществами, включая сопутствующие технологии XML-

платформы и ее стандартные средства.

Программная обработка RDF-описания на языке XML заключается

в том, что парсер анализирует соответствующий текст и строит по

нему внутреннее представление (т. е. ориентированный граф), а вся

дальнейшая программная обработка этого описания ведется уже на

уровне модели данных и абсолютно не зависит от изначально

используемого языка сериализации. Два документа считаются экви-

валентными, если их представления в виде модели совпадают,

поэтому в случае использования RDF не может возникнуть проблема

неоднозначного описания одного и того же факта, как это могло

случиться при работе с XML (см. примеры, приведенные

в разделе 6.1).

Для более точного понимания связи RDF с XML и другими язы-

ками сериализации можно привести следующую аналогию. Знание,

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

языке, но можно и на русском. В этой аналогии графовая RDF-модель

данных эквивалентна знанию, а его представление на XML – пред-

ставлению знания на каком-нибудь естественном языке.

3. Следующий этап развития технологий Semantic Web ведет

отсчет с момента разработки языка RDF Schema (RDFS), представ-

ляющего собой язык описания словарей RDF-терминов (свойств

и классов Web-ресурсов). В отличие от XML-схем, описывающих

структуру XML-документов и ограничивающих их содержание, RDF-

схемы позволяют определять семантику данных, основанных на XML-

представлении. Сегодня RDFS используется для создания более

богатых моделей описания предметных областей (например, языков

онтологий), которые позволяют адаптировать к Web-среде системы

математической логики и обеспечить семантическую обработку

данных.

6.3 ОПИСАНИЕ ФАКТОВ

Так как модель RDF определяется, прежде всего, как способ опи-

сания фактов при помощи тегов XML, первое, что мы должны сделать

для уяснения природы этой модели, описать, что собой представ-

182

ляют факты, и почему их описание так важно для формального

представления смысла данных.

6.3.1 ФАКТЫ КАК ЕДИНИЦА ПРЕДСТАВЛЕНИЯ СМЫСЛА

ДАННЫХ

Сначала определимся с понятием «смысл» по отношению

к данным. Для этого допустим, что в памяти машины хранится

число «185». Само по себе это число ничего не означает, т. е. не

имеет смысла, и непонятно, что с этим числом можно сделать.

Именно в таком виде хранятся данные в машине, а то, что

с ними делать, определяет программист путем написания кода,

предписывающего процессору выполнение последовательности

машинных инструкций над этими данными. Эта последовательность

операций определяется программистом исходя из его знаний

о предметной области и смысла решаемой задачи.

Ввиду отсутствия средств представления смысла в современных

информационных технологиях этот смысл остается в виде знаний

в памяти человека, а в машину заносится последовательность

машинных инструкций, обеспечивающая обработку данных, не

противоречащей их смыслу.

Хотя программный код также хранится в памяти машины, но

это не значит, что машина через него знает смысл выполняемой

работы. Для машины программный код – это просто последова-

тельность операций из состава системы команд процессора, и при

обработке данных машина об их смысле по-прежнему ничего не

знает. Она просто «слепо» выполняет над ними операции, опреде-

ленные в программном коде. Таким образом, в машине содер-

жатся данные и программный код, т. е. последовательность опера-

ций над ними, а их смысл – в памяти человека.

А теперь вспомним данные о человеке, представленные

в раз-деле 6.1 на языке XML в трех вариантах, и приведем их выра-

жение в виде одного единственного высказывания «Рост Иванова

185 см».

В этом высказывании число «185» представляется как значение

свойства «рост» субъекта «человек» по фамилии «Иванов».

183

Это и есть смысл числа «185», который в данном конкретном

примере определяется сопоставлением трех сущностей:

– «Иванов» – экземпляр сущности «Человек»;

– значения «185»;

– сущности «Рост», представляющей собой отношение между

приведенными сущностями.

Из приведенного описания видно, что в данном отношении эти

сущности четко упорядочены путем задания их ролей:

– «Иванов» – субъект;

– «Рост» – предикат или свойство;

– «185» – объект или значение.

Приведенное отношение описывает факт, определяющий, что

число 185 является значением свойства Рост сущности Человек по

фамилии Иванов. Другими словами, факт является единицей пред-

ставления смысла данных. Именно для описания фактов был создан

язык RDF, содержащий в своем арсенале средства для выражения

и связывания в единую структуру компонентов факта, рассматри-

ваемого как одну из форм представления единицы смысла данных.

6.3.2 ОПИСАНИЕ ФАКТОВ В ЯЗЫКАХ ПРОГРАММИРОВАНИЯ

В традиционных языках программирования отсутствуют сред-

ства обработки фактов, представляющих собой структуры, описы-

ваемые графовыми конструкциями. Хотя структура данных, соот-

ветствующая факту (например, описанному выше факту «Рост Иванова

185 см») может быть определена. Например, в языке C++ для пред-

ставления этого высказывания может быть использована структура

struct Chelovek

{ Family: string;

Rost: string;

Value: integer }.

Компоненты этой структуры рассматриваются не как субъект,

предикат и объект факта, а как обычные переменные и могут быть

обработаны по отдельности, например:

– с данными Chelovek.Family могут быть выполнены операции кон-

катенации и сравнения;

184

– с данными Chelovek.Value – арифметические операции сложения

или вычитания и т. д.

Но в языке C++ отсутствуют встроенные средства обработки

экземпляров этих структур целиком для выявления их ложности или

истинности, т. е. как фактов. Поэтому для обработки фактов были

созданы специализированные языки программирования, такие как

Lisp и Prolog. С помощью этих языков факты могут быть записаны

разными способами:

– на языке Lisp факт «Рост Иванова 185 см» может быть записан

с помощью выражения:

(предикат субъект объект)

(Рост Иванов 185).

– на языке Prolog тот же факт записывается так:

Предикат (субъект, объект)

Рост (Иванов, 185).

Языки Lisp и Prolog были созданы в рамках развития научного

направления «Искусственный интеллект», которое появилось задол-

го до возникновения Всемирной паутины, и не были приспособлены

для работы с данными, размещенными в Сети. Поэтому понадоби-

лись другие средства, адаптированные на работу с распределенными

данными, и именно такие средства были созданы в рамках проекта

Semantic Web. Но прежде чем приступить к рассмотрению этих средств,

постараемся выяснить, чем же отличаются факты от данных,

и почему для их обработки не подходят традиционные языки

программирования.

6.3.3 ДАННЫЕ И ФАКТЫ

Факты отличаются от данных, с которыми программисты при-

выкли иметь дело. Для описания этого отличия снова обратимся

к высказыванию «Рост Иванова 185 см». Для представления этого

высказывания, выраженного на естественном языке, на языке деск-

рипционной логики, лежащей в основе спецификации RDF, исполь-

зуется запись вида <Иванов, Рост, 185>. Такая запись в дескрипционной

185

логике называются кортежем, а каждый из его элементов называ-

ется термом.

Разница между кортежем и структурой данных заключается

в том, что кортеж представляет собой декларацию или высказы-

вание. Выражение, составленное из данных, может быть вычислено

и присвоено переменной. Но невозможно вычислить декларацию

или присвоить ее переменной. Обработка кортежа состоит в том, что

соответствующий факт признается либо истинным, либо – ложным.

Факты, для которых находятся подходящие кортежи, признаются

истинными, а остальные – ложными.

Основная проблема записей фактов в виде кортежей заклю-

чается в том, что они содержат три терма, представляющие сущ-

ности, в то время как факт определяется двумя сущностями, между

которыми зафиксировано некоторое отношение. Решение этой

проблемы заключается в том, что для обозначения отношений также

используются термы, а для каждого из термов кортежа определя-

ются роли из описания факта. В этом случае мы получаем кортежи

особого типа, называемые предикатами. Таким образом, предикаты

содержат как термы, представляющие сущности, так и термы, пред-

ставляющие отношения между ними.

Для упрощения обработки предикатов принято соглашение,

в соответствии с которым в каждом предикате содержится только

один терм-отношение, выражающий связь между двумя сущно-

стями. Такие предикаты содержат три терма и называются трипле-

тами. Каждый терм триплета имеет специфическое название:

первый терм называется субъект, второй терм, выражающий отно-

шение, – предикат, а третий терм – объект.

6.4 ДЕСКРИПЦИОННАЯ ЛОГИКА

При анализе проблем представления семантики данных в раз-

деле 6.1 было отмечено, что с проблемой связывания данных по

смыслу непосредственно связана проблема сопоставления связанных

терминов различных предметных областей.

В конструкциях представления фактов, описанных в предыду-

щих подразделах, на элементы триплета никакие ограничения не

186

накладываются. Для пояснения описанной ситуации снова вернемся

к триплету, описывающему данные о человеке по фамилии Иванов,

и рассмотрим его с точки зрения описания отношения между сущно-

стями.

С математической точки зрения триплет представляет собой

экземпляр некоторого бинарного отношения. Бинарное отношение

представляет собой множество пар. Например, отношение «Рост»

задает множество пар элементов вида {(Иванов, 185), (Петров, 179), …}.

Каждая тройка определяет одну пару из некоторого бинарного

отношения, но кроме этого, дополнительно задает еще имя отноше-

ния, т. е. если имеется пара (Иванов, 185) отношения «Рост», то эту

пару можно выразить тройкой <Иванов, Рост, 185>.

Математическое понятие отношения выводится из понятия

«множество». Отношением между парой элементов, определенным

на множествах их значений, называется фрагмент декартова произ-

ведения этих множеств. Для определения отношения элементов на

всевозможные их сочетания необходимо наложить некоторые огра-

ничения, выделяющие этот фрагмент декартова произведения.

Определим ограничения, которые должны быть наложены на

содержимые элементов отношения «Рост», для полноценного описа-

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

сделать для определения отношения «Рост», – это уточнить, что

первый элемент этого отношения должен быть фамилией человека,

а второй – число в сантиметрах. Для определения такого ограниче-

ния необходимо ввести понятия «фамилия человека» и «число в см».

После этого задается ограничение, выражающее тот факт, что если

имеется тройка вида («Иванов», «Рост», «185»), то сущность «Иванов»

должна быть экземпляром понятия «фамилия человека», а сущность

«185» – экземпляром понятия «число в см».

Для выражения ограничений описанного вида используется

математический аппарат дескрипционной логики [41], служащий

фундаментом языка RDF. Дескрипционная логика базируется на

формализмах семантических сетей [42] и фреймов [43], но исполь-

зует аппарат математической логики.

187

В математической логике производится явное разделение на

синтаксис и семантику. Синтаксис задает язык, с помощью которого

записываются различные высказывания об элементах мира данной

логической системы. Семантика признает истинными только те

высказывания, которые удовлетворяют заданным ограничениям.

Каждое выделенное высказывание отражает соответствующий факт

описываемого мира, а совокупность этих высказываний составляет

его модель.

6.4.1 ЭЛЕМЕНТЫ ДЕСКРИПЦИОННОЙ ЛОГИКИ

Язык дескрипционной логики состоит из следующих элементов:

– множества унарных предикатных символов, обозначающих

имена понятий. Понятия обозначают множества сущностей, которые

им принадлежат, т. е. это классы в программистской терминологии;

– множества бинарных предикатных символов, обозначающих

имена ролей. Роли задают отношения между понятиями;

– рекурсивного определения термов понятий, задаваемого

с помощью конструкторов на основе понятий и ролей. В качестве

конструкторов термов выступают как операции логики первого

порядка, такие как конъюнкция, дизъюнкция, ограничения универ-

сальности и существования и т. д., так и операции, задающие огра-

ничения ролей, т. е. бинарных отношений.

6.4.2 ЛОГИЧЕСКАЯ СИСТЕМА ДЕСКРИПЦИОННОЙ ЛОГИКИ

В математике логическая система обычно определяется как

некоторое множество �, состоящее из элементов и описываемое

выражением

� = ��, … , ��, … , ��.

В модели логической системы определяются классы, соответст-

вующие понятиям. Таким образом, совокупность понятий предмет-

ной области образует множество классов

� = ��, … , ��, … , ��, … , ��.

188

Каждый из элементов �� этого множества включает в себя опре-

деленное количество элементов �� множества �, что можно запи-

сать выражением

��(.)� , … , ��(.)

� , … , ��(.)� ∈ �� ,

где 1(�), … , �(�) ⊂ 1, … , Σ, а �(1) + ⋯ + �(�) + ⋯ + �(�) = Σ.

Примечание. В приведенном выражении (и далее в этом разделе) точка

внутри скобки в нижнем индексе обозначает верхний индекс, т. е. нижний

индекс �(. ) следует читать как �(�).

В результате проведенной классификации элементы �� множе-

ства � соотносятся с определенными классами, т. е. записываются

в виде ��(.)� . Описанное разбиение множества элементов �� на

классы можно представить как результат отображения множества �

на множество �. В этом случае мы получаем семейство отображений

классификации

� = ��, … , ��, … , ��.

Каждый член �� этого семейства представляется множеством

отображений

�� = {��(.)� , … , ��(.)

� , … , ��(.)� },

элементы которого реализуют связь между элементами мно-

жеств � и �, что можно записать как

��(.)

��⎯� ��, для всех � = 1, … , Σ, � = 1, … , �.

Определим на множестве � также отношения между элемен-

тами разных классов. Отношения между элементами ��(.)� ∈ ��

и ��(.)�

∈ �� запишем выражением

��(.)�

��(.)��

�⎯� ��(.)�

, для �(�) ⊂ 1, … , �(�), �(�) ⊂ 1, … , �(�).

Каждое отношение ��(.)��

определяет факт предметной области

и представляет собой суждение о состоянии некоторого ее фраг-

мента. Обозначим семейство �� (�, � ∈ 1, … , �) отношений-фактов

между элементами классов �� и �� как

� = {��}, где (�, � ⊂ 1, … , �).

189

Использование знака подмножества ⊂ в данном и предыдущем

выражениях означает, что отношения ��(.)��

, а также их множества ��

определяются не для всех возможных сочетаний �(�) и �(�) элемен-

тов и их множеств �� и ��, а только для выбранных.

Таким образом, в множестве �, кроме уже описанных элементов

и их классов-подмножеств ��, определяются подмножества �� ∈ �

и �� ∈ �, как показано на рис. 6.1.

�

��

��

��(.)��

��(� )

��(�)

��(.)�

��

��

�1

�1 ��

��(.)�

Рис. 6.1 Логическая система дескрипционной логики

6.4.3 КОМПОНЕНТЫ ДЕСКРИПЦИОННОЙ ЛОГИКИ

В дескрипционной логике семейства отображений �� ∈ �, � ∈

1, … , �, сопоставляют наименования сущностей с наименованиями

понятий в виде отношения принадлежности ��(.)� ∈ �� и, таким

образом, формируют терминологический компонент.

Множество � содержит высказывания, задающие отношения

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

отношениями и описывается выражением

�: �� = {��(.)� : (��(.)

� ∈ ��)},

где � = 1, … , �, �(�) = 1(�), … , �(�).

Отображения �� ∈ �, (�, � ∈ 1, … , �) фиксируют факты в виде

суждений ��(.)��

(��(.)� , ��(.)

�), т. е. определяют компонент суждений.

190

Множество � содержит высказывания, определяющие отношения

экземпляров понятий из множеств ��, и описывается выражением

�: �� = {��(.)��

(��(.)� , ��(.)

�)} для всех �, � = 1, … , �,

�(�), �(�) = 1(�), … , �(�).

Важно иметь в виду, что отношения ��(.)��

представляют собой

бинарные отношения и на них наложены ограничения, определен-

ные в множестве �, которые определяют, что первый элемент отно-

шения должен принадлежать классу ��, а второй – классу ��.

Описание логической системы в некотором множестве � соот-

ветствует классическому подходу, но в RDF принято использовать

еще и представление логической системы на графе, как показано на

рис. 6.2.

Графовое представление логической системы обеспечивает

более наглядную иллюстрацию ее компонентов (терминологическо-

го � и суждений �). Например, высказывание «Статья:713 является

Рис. 6.2 Ориентированный граф модели RDF

191

Статья» задает отношение между понятием «Статья» и его экземпля-

ром «Статья:713», следовательно, принадлежит множеству �.

Высказывание «Автором Статья:713 является Человек:136» задает

отношение между «Статья:713» и «Человек:136». Сущности «Статья:713»,

«Человек:136», «Журнал:549» и «Издат-во:18» являются экземплярами поня-

тий «Статья», «Человек», «Журнал» и «Издательство» соответственно, что

определяется через отношения, принадлежащие множеству �.

Кроме перечисленных сущностей на графе представлены стро-

ковые значения «Петр», «Федоров» и «Программирование», которые явля-

ются экземплярами класса «Литера».

В дескрипционной логике элементы множества � представляют

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

тами (понятиями), в этом состоит их отличие от высказываний

множества �.

Таким образом, и отношения, определяемые высказываниями

(элементы множества �), и ограничения, налагаемые на элементы

отношений (элементы множества �), задаются с помощью одной

и той же синтаксической конструкции, т. е. триплетов. А различение

высказываний из � и � используется при построении процедуры

логического вывода на моделях дескрипционных логик.

Высказывания из � задают свойства «классификации», а выска-

зывания из � – свойства, которые можно условно назвать

свойствами «проверки экземпляра». Логический вывод по этим

множествам может существенно различаться, поэтому имеет смысл

реализовать отдельные алгоритмы вывода для каждого компонента.

Соответствия между именами и сущностями и их отношениями

на множестве � будем называть моделью данной дескрипционной

логики, или ее интерпретацией. Обозначим ее через символ �

и определим выражением

� = ({��}, {��}) ,

где �� = {��(.)� → (��(.)

� ∈ ��)}, �� = {��(.)��

→ (��(.)� , ��(.)

�)}.

Данное описание интерпретации логической системы в некото-

ром множестве соответствует классическому подходу, но в RDF

192

часто используется интерпретация на графе, которая с учетом выра-

жений для � и �, приведенных выше, представляется как � = (�, �).

Иначе говоря, в RDF качестве моделей выступает граф, представ-

ляющий собой описанные выше два типа (или класса) троек или

триплетов (см. рис. 6.2).

6.5 ОБЩИЕ СВЕДЕНИЯ О МОДЕЛИ RDF

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

Если в XML упор делается на синтаксическую составляющую данных, то RDF является средством представления семантической составляющей данных в распределенном мире, что отчасти имеет отношение к смыслу.

6.5.1 ОПИСАНИЕ ФАКТА В ФОРМАТЕ RDF

Стандарт RDF описывает, как с помощью объединения различ-ных сущностей можно констатировать факты. Как уже было отме-чено, базовый строительный блок модели данных RDF – факт (утверждение), представляет собой триплет, состоящий из ресурса, именованного свойства и его значения. В терминологии RDF, как и в дескрипционной логике, эти три части утверждения называются соответственно: субъект, предикат и объект [40].

Основная цель RDF/XML – предоставить синтаксис для описания фактов в XML-формате. Синтаксис RDF/XML для описания фактов имеет следующую форму:

<факт субъект="..."> <предикат>объект</предикат> </факт>

193

Эта запись отражает лишь общую концепцию синтаксиса RDF.

Ниже приведено синтаксически корректное описание факта на языке

RDF в XML-формате:

<Description about="http://www.man.org/"> <man:Рост>185</man:Рост > </Description>

Тег <Description> в модели фактов интерпретируется следующим

образом. Атрибут about тега <Description> определяет субъект факта.

Если тег имеет содержимое, оно представляет прочие термы данного

факта и, возможно, вложенные факты.

Вложенный в <Description> тег <man:Рост> представляет собой

предикат, а его содержимое, простая строка или литерал «185», –

объект.

При изучении языка RDF следует иметь в виду, что его термино-

логия отличается от терминологии, используемой в дескрипционной

логике. В RDF не используются такие термины, как «субъект» или

«предикат», а применяемые в нем конструкции основаны скорее на

частных идеях, чем на общей концепции фактов, изложенной в этой

главе. Это затрудняет освоение RDF начинающими пользователями.

Например, в терминологии RDF приведенная конструкция

интерпретируется следующим образом. Тег <Description> определяет

ресурс. Этот ресурс может иметь свойства, выраженные вложен-

ными тегами. Например, тег <man:Рост> представляет собой такое

свойство, значением которого является литерал «185».

Согласно спецификации языка RDF, значение свойства или

объект может иметь один из двух типов. Первый – это ресурс, зада-

ваемый некоторым URI. Второй тип – литерал – есть некоторое

текстовое значение характеристики.

Тот факт, что значением свойства может быть некоторый

ресурс, задаваемый некоторым URI, превращает модель данных RDF

из дерева, которым является XML-разметка, в ориентированный

граф (см. Рис. 6.2).

194

6.5.2 СИНТАКСИС ФАЙЛА RDF

В этом учебном пособии мы не ставим себе цель освоить язык

RDF в полном объеме. Данная глава является факультативной, и ее

назначение – объяснить, каким образом с помощью конструкций

этого языка представляются факты, а через них – смыслы данных,

содержащиеся в фактах. Для этого в данном разделе опишем лишь

простейшие синтаксические конструкции языка RDF и рассмотрим

примеры определения с их помощью фактов и их компонентов.

6.5.2.1 Т е г и

Полный список основных тегов RDF представлен тегами <RDF>,

<Description>, <Seq>, <Bag>, <Alt>, <li>. Последние четыре тега являются

избыточными – эквивалентные им конструкции могут быть выра-

жены при помощи тега <Description>.

В RDF также предусмотрено несколько таких тегов, предназна-

ченных для реификации (реализации) фактов:

<Statement>, <subject>, <predicate>, <object>.

Тег <Statement> из приведенного перечня используется для реи-

фикации самого факта, а остальные три тега – для каждого из трех

термов триплета.

Тег <RDF>. Тег <RDF> является корневым элементом любого

документа RDF и его наличие обязательно. Как принято в стандартах

XML-платформы, в корневом теге определяется префикс для про-

странства имен RDF

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">.

Поскольку документы RDF, как правило, содержат теги из

нескольких пространств имен, традиционно в этом теге могут быть

определены префиксы любых других пространств имен путем вклю-

чения в документ дополнительных деклараций xmlns.

Других атрибутов для этого тега не предусмотрено, в нем могут

встречаться лишь декларации пространств имен XML, добавляющие

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

195

Все остальные теги, а именно тег <Description> и теги-контейнеры

<Seq>, <Bag>, <Alt>, являются тегами-потомками <RDF>.

Тег <Description>. Тег <Description> является основой языка RDF.

С его помощью описываются факты (один или несколько) и он

может содержать любое количество тегов-потомков, в том числе ни

одного. Каждый тег-потомок является предикатом (свойством RDF)

и выражает один факт, субъект которого указан в теге <Description>.

В следующем листинге, записанном на псевдокоде, представлены

два факта, выраженные с помощью одного тега <Description>.

< Description субъект="...">

<свойство1 ...>объект1</свойство1>

<свойство2 ...>объект2</свойство2> </Description >

В приведенном листинге представлена сокращенная запись двух

различных фактов с одним и тем же субъектом. Здесь вместо терми-

на предикат использован термин свойство, т. к. эти термины взаимо-

заменяемы, а описываемый факт определяет два свойства субъекта.

Следующий листинг представляет полностью оформленный RDF-

документ, в котором выражается единственный факт, свидетельст-

вующий о том, что Рост Иванова 185 см:


<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:ns="http://www.example.org/#">

<Description about="www.test.com/#Иванов">

<ns:Рост>185</ns:Рост>

</Description>

</rdf:RDF>.

В данном случае компоненты тега RDF представлены:

– субъект – с помощью URL-адреса "www.test.com/#Иванов";

– объект – с помощью литерала «185»;

– предикат – с помощью URL-адреса. Хотя в приведенном тексте

предикат «Рост» определен в пространстве имен с префиксом ns,

следует иметь в виду, что наименование пространства имен опреде-

196

ляется в виде URL-адреса, поэтому, в конечном счете, предикат также

определяется с помощью URL-адреса, заданного в заголовке RDF-

файла.

Теги <Seq>, <Bag>, <Alt> и <li>. RDF для организации одно-

типных фактов использует контейнеры. Контейнер состоит из

обрамляющего тега <Bag>, <Seq> или <Alt>, а также тегов <li>,

в которые заключаются элементы контейнера. Теги <Seq>, <Bag>

и <Alt> имеют следующее назначение:

– <Seq> – используется для представления последовательности

элементов или упорядоченного списка;

– <Bag> – представляет собой коллекцию элементов без каких-

либо ограничений на ее состав;

– <Alt> – используется для представления списка альтернатив. Это

также коллекция без ограничений, но подразумевается, что все ее

элементы являются альтернативами. Например, в контейнере <Alt>

могут содержаться варианты одного и того же сообщения

программы на разных языках.

Элементы контейнера заключены в теги <li>, подобно элементам

списков <ul> и <ol> в языке HTML. Ниже приведен пример простого

контейнера.

<Description about="www.example.com/#Петров"> <ns:Владелец> <Bag ID="Собаки"> <li>Шарик</li> <li>Бобик</li> <li>Цербер</li> </Bag> </ns:Владелец> </Description>

Смысл этой записи очевиден: Петров – владелец Шарика; Петров –

владелец Бобика; Петров – владелец Цербера.

Контейнеры позволяют компактно записывать несколько сход-

ных фактов путем организации субъектов и объектов в группы.

При этом каждый элемент контейнера является объектом.

К сожалению, интерпретация контейнера с точки зрения фактов

является несколько непривычной для восприятия.

197

6.5.2.2 А т р и б у ты т е га < D e s c r ip t i o n >

Для тега <Description> предусмотрены следующие специальные

атрибуты: ID, about, type. Атрибуты ID или about являются обязатель-

ными для каждого тега <Description>. Если в теге не представлен ни

один из этих атрибутов, то считается, что факт имеет анонимный

субъект. Для этого субъекта невозможно определить уникальный

URL, и он для внешнего мира невидим, а в рамках данного документа

считается неопределенным термом.

Атрибут ID обеспечивает идентификацию факта. Его использо-

вание имеет смысл в том случае, когда у этого тега есть ровно одно

свойство. Как правило, атрибуту ID присваивается имя, совпадающее

с его значением. Для получения уникального URL факта это имя

можно добавить к URL документа RDF. При этом этот же URL одно-

временно рассматривается как URL субъекта данного факта.

С помощью атрибута about определяется субъект факта.

В качестве значения этого атрибута определяется полный URL. Если

атрибут about используется вместо атрибута ID, факт как целое не

имеет собственного URL и недоступен из внешнего мира.

С помощью атрибута type тега <Description> в RDF можно определить

предикат type. Использование атрибута type="value" в этом случае позво-

ляет создавать сокращенный вариант записи тега-предиката type,

выражаемого в полном варианте следующей строкой:

<rdf:type>value</rdf:type>.

Использование предиката type позволяет расширить базовую

систему типов либо с помощью определения фактов RDF, либо

в схеме RDF (описание RDF Schema см. ниже). Обратите внимание на

то, что атрибут type вместе со своим значением фактически образует

пару «свойство-значение», т. е. «предикат-объект».

Атрибут type указывает тип объекта факта или значения свойства

ресурса. Как правило, объектом/значением является содержащееся

внутри открывающего и закрывающего тега XML-элемента.

198

6.5.2.3 И д е н т иф и к ац ия р е с у р со в

В отличие от многих других приложений XML, в RDF идентифика-

торы могут использоваться для обозначения целого факта. Для этого

к тегу, определяющему данный факт, добавляется атрибут ID. URL

документа RDF, дополненный символом # и значением атрибута ID

факта из данного документа, является уникальным идентифика-

тором факта в глобальном масштабе.

URL такого вида указывает на фрагмент документа, а не на ресурс

в целом. Однако в RDF ресурсом считается именно отдельный факт,

даже если он является частью большего документа. Поэтому RDF-

документ может рассматриваться как группа или коллекция

ресурсов.

Приведем пример объявления идентификатора с помощью атри-

бута ID тега <Description>:

<Description ID="printEnabled" ... />.

В данном объявлении в качестве значения атрибута ID исполь-

зовано осмысленное имя, позволяющее судить о состоянии подсис-

темы печати.

Другой способ использования идентификаторов в RDF – замена

локальных литералов, используемых в документе RDF для обозначе-

ния факта. При этом можно получить лаконичные записи фактов.

До сих пор мы рассматривали использование идентификаторов

для обозначения субъекта, а через него и всего факта. Однако URL

может быть идентификатором не только субъекта, но и объекта.

Таким образом, и субъект, и объект факта могут иметь собственные

URL.

RDF идет еще дальше в этом направлении и позволяет выразить

с помощью URL и «предикат/свойство» факта. URL предиката рас-

сматривается как ссылка на ресурс, в котором описан данный преди-

кат, и в RDF-документе замещает фактический предикат, который

может находиться на сайте какого-либо учреждения или организа-

ции по стандартизации или, например, на корпоративном сервере.

Для удобства чтения URL-предикат, как правило, содержит слово,

199

поясняющее его общий смысл, например www.example.com/#Owner

(владелец).

Таким образом, при необходимости факты можно выражать при

помощи одних лишь URL-идентификаторов. Фактически такие иден-

тификаторы являются указателями на термы, из которых составлены

факты.

Строго говоря, идентификаторы, заменяющие термы факта,

могут иметь более общий синтаксис – URI (универсальный указатель

ресурса). Синтаксис URI охватывает как URL, так и URN (универсаль-

ное имя ресурса).

6.5.3 СХЕМА RDF

Главная цель RDF – предложить базовую конструкцию данных

«объект-атрибут-значение» для описания фактов. Кроме этой семан-

тики (описанной в стандарте лишь неформально) RDF не содержит

никаких правил, ориентированных на моделирование данных.

В спецификации RDF ничего не говорится о том, какие свойства

могут быть у конкретных сущностей и каковы их допустимые

значения, подобно тому, как в спецификации XML определяются

лишь правила разметки данных, а не конкретный язык для выделен-

ной предметной области. В терминах дескриптивной логики

в RDF определены лишь правила составления высказываний из

множества �.

Важным ограничением RDF при описании предметных областей

в терминах ресурсов, их свойств и значений этих свойств является

невозможность атрибутирования (т. е. представления сущностей

в виде совокупности свойств) и типизации самих свойств, а также

отношений между ресурсами. Если перейти на терминологию опи-

сания фактов в виде RDF-графов, то можно сказать, что в RDF не

предусмотрено средств детализации данных о дугах графа, пред-

ставляющих свойства субъектов. RDF поддерживает только их

идентификацию.

Но из теории языков программирования известно, что именно

наличие возможностей типизации данных обеспечивает способность

языка к представлению семантической информации о предметных

200

областях. Введение в RDF понятия словарей и средств их формально-

го описания с помощью RDF Schema позволило в значительной

степени устранить эту проблему.

6.5.3.1 R D F S ch e ma к а к с по с о б о пр е д е л е н и я

о гр а н ич е н и й н а ф а к ты

Прежде чем перейти к описанию RDF Schema, постараемся

понять, в чем заключается суть типизации сущностей фактов. При

этом будем исходить из того, что факты, рассмотренные нами выше,

неявно подразумевают множество других фактов, которые могут

быть выражены в явном виде. Например, для факта <Иванов, Рост, 185>

это могут быть факты:

<Фамилия человека, есть, Иванов>,

<Число в см, равно, 185>.

Приведенные факты указывают типы субъекта и объекта

рассматриваемого примера факта и содержат дополнительную

информацию об этом факте. Эта информация аналогична информа-

ции, содержащейся в словаре данных или схеме БД, описывающей

и ограничивающей данные базы.

Таким образом, как и в случае представления данных в базах,

для полноценного описания утверждения, кроме определения отно-

шений, необходимо задать еще ограничения на их элементы.

Например, для отношения «Рост» необходимо уточнить, что первый

элемент каждой пары этого отношения должен быть фамилией

человека, а второй – число в сантиметрах.

Для явного определения этих ограничений необходимо ввести

понятия «Фамилия человека» и «Число в см». После этого задается огра-

ничение, определяющее то обстоятельство, что если имеется тройка

вида <Иванов, Рост, 185>, то сущность «Иванов» должна быть экземпля-

ром понятия «Фамилия человека», а сущность «185» – экземпляром

понятия «Число в см».

Формально описанная конструкция определена в дескрипци-

онной логике с помощью множеств � и � (см. Рис. 6.1 и Рис. 6.2).

Множество � дескрипционной логики, содержащее высказывания,

задающие отношения между понятиями и его экземплярами,

201

представляет собой множество «фактов о фактах», а множество �

содержит множество «обычных» фактов, описывающих ассоциации

между сущностями, составленных с учетом ограничений, заданных

в множестве �.

Для определения программно обрабатываемых ограничений на

высказывания, задаваемых в дескрипционной логике с помощью

множества �, в XML-платформу был введен язык RDF Schema.

Язык RDF Schema играет для RDF такую же роль, что и XML Schema

для XML. Если XML Schema используется для определения словаря

предметной области для составления XML-документов, то RDF Schema

разрешает разработчикам определять конкретный словарь для

данных RDF путем предоставления базовой системы типов сущно-

стей для формирования конструкций «объект-атрибут-значение».

RDF Schema можно рассматривать как расширение RDF для типи-

зации данных, базирующееся на двух понятиях – «класс» (class)

и «свойство» (property):

– класс в RDF Schema (RDF-класс) – это тип сущностей, который

идентифицируется RDF-ресурсом;

– свойство в RDF Schema – это тип атрибутов, характеризующих

некоторый класс (или группу классов).

Следует отметить, что понятие свойства в RDF, определяющее

отношение между субъектом и объектом, и термин «свойство» в RDF

Schema, где рассматриваются типы RDF-свойств, а не единичные дуги

в RDF-графе, различаются. Далее для различения понятия свойства

в RDF Schema будем употреблять термин «тип-свойство», а сущности,

относящиеся к классу, будем называть его экземплярами (instance).

Словари, определенные с помощью RDF Schema, позволяют мате-

риализовать модели данных, определенные в спецификации RDF,

которые сами по себе представляют лишь сосуд, требующий напол-

нения. Словари RDF Schema, включают в себя:

– ресурсы, используемые для описания свойств других ресурсов;

– классы ресурсов, которые могут быть описаны при помощи

заданных свойств;

– ограничения, налагаемые на значения свойств или наборы

допустимых значений.

202

Значимость словарей, обеспечивающих осмысление (понимание)

ресурсов программами, можно описать с помощью следующей ана-

логии. В обыденной жизни два человека, разговаривающие на одном

языке, не смогут понять друг друга, если они используют для этого

различную лексику (например, термины из области медицины

и математики). В области машинного представления ресурсов их

понимание при передаче между различными системами не будет

достигнуто, пока не будут разработаны единые для этих систем

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

6.5.3.2 С и н т а к с ич е с к и е к о н с т р ук ц ии я з ы к а R D F

S c h e ma

RDF Schema предоставляет механизм для определения необходи-

мой совокупности типов ресурсов и свойств, используемых для

ограничения описаний фактов некоторой предметной области сред-

ствами RDF. Типы ресурсов и свойств определяются с помощью RDF

Schema в виде классов, подклассов, свойств и подсвойств, т. е. в виде

совокупности фактов из множества �. Таким образом, факты из

множества � определяются не между отдельными сущностями,

а между их классами и подклассами. Это дает возможность накла-

дывать ограничения на субъекты, свойства и объекты фактов, опре-

деляющие их смысловое содержание.

Приведем синтаксические конструкции для определения типов

ресурсов и свойств, дающих представление о синтаксисе языка RDF

Schema. Для обозначения понятий, определяемых с помощью RDF

Schema, в нотации RDF/XML предусмотрен префикс «rdfs:».

Синтаксис описания классов в RDF Schema. Синтаксис описа-

ния классов в RDF Schema содержит следующие основные предопре-

деленные ресурсы и их свойства:

– «rdfs:Resource» – класс произвольных сущностей, т. е. класс,

к которому относятся любые описываемые в RDF ресурсы. Одновре-

менно «rdfs:Resource» представляет собой абстрактный суперкласс,

подклассами которого являются все классы RDF Schema;

– «rdfs:Class» – класс RDF-ресурсов, являющихся классами (соот-

ветственно «rdfs:Class» является экземпляром самого себя);

203

– «rdfs:Literal» – класс значений свойств, являющихся строками или

целыми числами, и является экземпляром класса «rdfs:Class»

и подклассом «rdfs:Resource»;

– «rdfs:datatype» – класс типов данных. Одновременно является

экземпляром и подклассом класса «rdfs:Class». Каждый экземпляр

класса «rdfs:datatype» является подклассом класса «rdfs:Literal»;

– «rdf:XMLLiteral» – класс XML-литералов, являющийся экземпляром

класса «rdfs:datatype» и подклассом класса «rdfs:Literal»;

– «rdf:Property» – класс RDF-свойств, являющийся экземпляром

класса «rdfs: Class».

Синтаксис описания типов-свойств языка RDF Schema.

Синтаксис описания типов-свойств языка RDF Schema содержит

следующие предопределенные элементы:

– «rdfs:range» – экземпляр класса «rdf:Property», используемый для

указания на то, что значение свойства является экземпляром одного

или нескольких классов. Триплет «P rdfs:range C» означает, что P явля-

ется экземпляром класса «rdf:Property», C – экземпляром класса

«rdf:class», а ресурсы, описанные как объекты триплетов, имеющих

предикат P, являются экземплярами класса С. В тех случаях, когда Р

имеет более одного свойства «rdfs:range», ресурсы, описывающие

объекты триплетов с предикатом Р, становятся экземплярами

классов, определенных через Р и «rdfs:range»;

– «rdfs:domain» – экземпляр класса «rdf:Property», используемый для

указания на то, что ресурс, имеющий данный тип-свойство, является

экземпляром одного или нескольких классов. Триплет «P rdfs:domain C»

означает, что Р является экземпляром класса «rdf:Property», С – экземп-

ляром класса «rdf:class» и все ресурсы, описанные субъектами трипле-

тов с предикатом Р, являются экземплярами класса С. В тех случаях,

когда Р имеет более одного свойства «rdfs:domain», ресурсы, описы-

вающие субъекты триплетов с предикатом Р, становятся экземпля-

рами всех классов, определенных через Р и «rdfs: domain»;

– «rdf:type» – экземпляр класса «rdf:Property», используемый для ука-

зания на то, что ресурс является экземпляром класса. Триплет «R

rdf:type C» означает, что С является экземпляром класса «rdf:class», а R –

экземпляром класса С;

204

– «rdfs:subClassOf» – экземпляр класса «rdf:Property», описывающий

подкласс класса;

– «rdfs:subPropertyOf» – экземпляр класса «rdf:Property», описывающий

тип-подсвойство типа-свойства (отношение «свойство – подсвой-

ство» является транзитивным);

– «rdfs:label» – экземпляр класса «rdf:Property», позволяющий опреде-

лять псевдонимы (удобные для восприятия) имен ресурсов;

– «rdfs:comment» – экземпляр класса «rdf:Property», позволяющий

определять для ресурсов комментарии, разъясняющие смысловое

значение классов и типов-свойств.

Дополнительные предопределенные типы RDF Schema.

Перечисленные предопределенные классы и типы-свойства счита-

ются базисными элементами словаря RDF Schema, на основе которых

строятся дополнительные средства типизации данных и производ-

ные словари. Дополнительные предопределенные типы RDF Schema

(классов и свойств) часто логически объединяют в отдельные

словари, расширяющие возможности базового словаря. Среди этих

словарей можно выделить словарь контейнеров, словарь коллекций,

словарь реализаций (термин «реализация» здесь и далее заменяет

английский термин «reification» – воплощение, материализация)

и словарь вспомогательных свойств.

Элементы словаря контейнеров. Словарь контейнеров содержит

предопределенные классы «rdf:Bag», «rdf:Seq», «rdf:Alt», а также:

– класс «rdf:Container», экземплярами которого являются перечис-

ленные ранее классы Bag, Seg и Alt;

– тип-свойство «rdfs:ContainerMembershipProperty», экземплярами

которого являются предопределенные свойства, имеющие обобщен-

ный вид «rdf:_n»;

– тип-свойство «rdfs:member», подсвойствами которого являются

все образцы типа-свойства «rdfs:ContainerMembershipProperty».

Элементы словаря коллекций. Словарь коллекций RDF Schema

содержит предопределенные классы и типы-свойства «rdf:List»,

«rdf:first», «rdf:rest» и «rdf:nil».

Элементы словаря реализаций. Словарь реализаций представлен

предопределенными символами, которые могут быть использованы

205

для типизации целостных триплетов. Данный словарь содержит

следующие элементы:

– «rdf:Statement» – класс, экземплярами которого являются утвер-

ждения RDF (триплеты);

– «rdf:subject» – тип-свойство, используемое для указания на субъ-

екты триплетов. Триплет «S rdf:subject R» определяет, что S является

экземпляром класса «rdf:Statement» (триплетом), в котором в роли

субъекта выступает R, относящийся к классу «rdf:Class»;

– «rdf:predicate» – тип-свойство, используемое для указания на

предикаты триплетов. Триплет «S rdf: predicate Р» определяет, что S –

экземпляр класса «rdf:Statement» (триплет), в котором предикатом

является R, относящийся к классу «rdf:Property»;

– «rdf:object» – тип-свойство, используемое для указания на

объекты триплетов. Триплет «S rdf:subject O» определяет, что S явля-

ется экземпляром класса «rdf:Statement» (триплетом), в котором в роли

объекта выступает О, относящийся к классу «rdf:Class».

Словарь вспомогательных свойств. Данный словарь содержит

следующие предопределенные символы:

– «rdfs:seeAlso» – тип-свойство, используемое для указания на

вспомогательный ресурс, предоставляющий дополнительную

информацию о ресурсе, являющемся субъектом триплета;

– «rdfs:isDefinedBy» – тип-свойство (подсвойство «rdfs:seeAlso»),

указывающий на ресурс, содержащий описание субъекта триплета

(например, на внешний словарь);

– «rdf:value» – тип-свойство, которое может быть использовано

при описании «структурированных» значений свойств (например,

значение структурированного свойства «время» может состоять из

десятичного числа «3.5» и определения единицы измерения – «час»).

6.5.4 RDF – ЯЗЫК ОПИСАНИЯ СЕМАНТИКИ РЕСУРСОВ

Описание с помощью RDF не ограничивается только описанием документов Интернета. Этот стандарт довольно универсальный и гибкий для того, чтобы описывать большинство типов структури-рованных данных. Например, в RDF естественно выражаются диаграммы сущность-связь, которые широко применяемы для

206

проектирования баз данных. Описание семантики ресурса на RDF может быть как «внешним», когда описывается ресурс в целом, так и «внутренним», когда описывается внутренняя структура ресурса, будь то база данных, XML-документ или целый сайт.

Важной особенностью стандарта RDF, как и лежащего в его основе XML, является расширяемость. На RDF можно задать структу-ру описания источника, используя и расширяя встроенные понятия RDF-схем, такие как классы, свойства, типы, коллекции. Модель схемы RDF включает наследование; наследоваться могут как классы, так и свойства.

Кроме описания структуры, RDF разрешает оперировать утвер-ждениями. Выражение «ресурс R1 как свойство P имеет ресурс R2» можно проинтерпретировать и как предикат P(R1, R2), а потом использовать это утверждение как объект других утверждений. Такая интерпрета-ция разрешает описывать с помощью RDF концептуальную инфор-мацию.

Таким образом, RDF целиком подходит на роль универсального языка описания семантики ресурсов и взаимосвязей между ними.

6.5.5 НЕДОСТАТКИ RDF

Однако, как утверждают сами авторы стандарта, RDF имеет и ряд отсутствующих свойств, которые они указывают как следующие:

– невозможность указания мощности множества значений свой-ства, например, что «Человек имеет только одного биологического отца»;

– невозможность указания того, что представленное свойство (например, hasAncestor – имеет предка, прототип) является транзитив-ным, например, что «если A hasAncestor B, и B hasAncestor C, тогда A hasAncestor C»;

– невозможность указания того, что два разных класса, опреде-ленных в разных схемах, фактически представляют одно и то же понятие;

– невозможность указания того, что два разных экземпляра (instances), определенные раздельно, фактически представляют один и тот же субъект;

– невозможность определения новых классов в терминах опера-ций (например, объединение и пересечение) над другими классами.

207


1. Опишите суть проблемы описания семантики данных.

2. В чем заключается идея Semantic Web?

3. Дайте определение факта, как единицы представления смысла

данных и опишите способы его представления.

4. В чем заключается разница между данными и фактами?

5. Дайте общее определение дескрипционной логики и опишите

понятия отношения, синтаксиса и семантики.

6. Дайте общее описание модели RDF.

7. Опишите, каким образом представляются факты в формате

RDF.

8. Опишите основные элементы синтаксиса модели RDF.

9. Дайте общее описание схемы RDF.

208

ЗАКЛЮЧЕНИЕ

Создание XML-платформы положило начало новому наукоемкому

и технологически более совершенному этапу в развитии Web. Язык

XML, а также другие, основанные на нем спецификации, стали

реально действующими стандартами, и многие ведущие поставщики

программного обеспечения не только Web, но и систем баз данных,

включают в свои программные продукты поддержку языка XML.

В результате XML-платформа становится существенным компонен-

том в технологии разработки информационных систем, а тенденция

их интеграции на уровне корпораций, ведомств, министерств только

укрепляет позиции XML в сфере информационных технологий

в целом.

Распространению стандартов XML-платформы существенным

образом способствует политика консорциума 3WC, направленная на:

– обеспечение доступности их спецификаций;

– создание ряда свободно распространяемых синтаксических

анализаторов, встроенных в популярные программные продукты,

например, в браузеры.

Широкое применение XML-платформы объясняется такими свой-

ствами XML-среды, как:

– наличие средств поддержки метаданных, описывающих свой-

ства информационных ресурсов, в том числе и семантические;

– способность технологий XML к интеграции с другими техноло-

гиями информационных систем;

209

– возможность обеспечивать интеграцию неоднородных инфор-

мационных ресурсов;

– возможность транспортировки XML-данных в глобальной

коммуникационной среде Web.

Главным звеном новой, открытой для расширения, технологиче-

ской платформы является язык XML. В отличие от традиционной Web,

где все основные функции управления информационными

ресурсами системы базируются на едином языке HTML, создатели

XML-платформы избрали иной путь:

– в первую очередь, выделяются «фундаментальные» стандарты,

составляющие концептуальную и синтаксическую основу

платформы;

– затем с помощью этих стандартов определяется комплекс

других стандартов, каждый из которых представляет отдельный

аспект описания данных;

– в случае необходимости этот комплекс открыт для пополнения

новыми стандартами.

Такая «модульность» организации платформы обеспечивает

ее открытый характер и определяет возможности введения новых

стандартов, не затрагивая уже существующие.

Основные стандарты платформы XML перечислены и вкратце

описаны в первой обзорной главе учебного пособия, где приведены

не только принятые стандарты, но и проекты, над которыми

в настоящее время еще продолжается работа.

В составе стандартов рассматриваемой платформы язык XML

выполняет две важные функции. Прежде всего, он обеспечивает

содержательную (структурную) разметку информационных ресур-

сов, которые в рассматриваемой среде называются XML-

документами. Кроме этого, язык XML служит одним из фундамен-

тальных стандартов платформы XML. Другие стандарты платформы,

которые дополняют его функции, связанные с управлением

данными, определяются в терминах синтаксиса XML.

Следует подчеркнуть, что XML, в отличие от HTML, не является

полнофункциональным языком, решающим задачи представления,

поддержки ограничений и обработки информационных ресурсов.

210

Если проводить аналогию с технологиями баз данных, то XML можно

квалифицировать как язык определения данных.

Специфика XML как языка определения данных заключается

в том, что в нем сочетаются возможности:

– самоописания свойств экземпляров элементов XML-документов,

составляющих содержание данного конкретного документа. Данная

группа свойств определяется с помощью встраиваемых в него тегов

разметки;

– другая группа свойств, характеризуемая как типовые свойства

группы документов, определяется с помощью другого стандарта,

описанного в спецификации XSD.

Таким образом, XML служит языком описания данных докумен-

тов или информационных ресурсов через определение самоописы-

ваемых свойств, составляющих содержимое размечаемых единиц

информации (XML-документов), и допустимой их структуры. Язык

XML описывается во второй, небольшой по объему, главе учебного

пособия.

Для представления типовой структуры XML-документов, т. е. их

синтаксических конструкций, разработан язык описания XML-схем

или стандарт XSD (XML Structure Definition). Этот язык является основным

инструментом определения структуры XML-документов. Использова-

ние XML-схемы позволяет формализовать набор правил, с соблюде-

нием которых составляется XML-документ конкретного назначения.

Именно в схеме XML-документа декларируется то, какие элементы

должны содержаться в нем, какой набор атрибутов должен или мо-

жет иметь каждый из них, и где их место в общей иерархии.

По мнению некоторых специалистов, спецификация XSD

в перспективе может стать универсальным средством моделирова-

ния данных. Поэтому в пособии описанию спецификации XSD

уделено особое внимание. Третья, самая объемная глава пособия,

посвященная описанию спецификации XSD, сопровождается боль-

шим количеством поясняющих примеров, а в конце главы приво-

дится подробное описание процедуры разработки XML-схемы. В этой

процедуре выделены этапы разработки композиционной схемы,

а также создания на ее основе агрегированной схемы.

211

Средства создания агрегированных схем в спецификации XSD

появились относительно недавно, но они играют исключительно

важную роль при интеграции разнородных информационных

систем, так как позволяют в точности копировать структуры их баз

данных. Агрегированные схемы дают возможность представлять

данные этих систем в XML-формате и использовать стандартную

инфраструктуру передачи данных в сетевой среде. Это гораздо

эффективнее разработки объемного программного кода для реализа-

ции протоколов обмена данными между многочисленными парами

взаимодействующих информационных систем.

Язык XML является удобным средством для описания данных, но

он не предназначен для их визуального представления. Для этого

XML-данные должны быть преобразованы в другую форму, напри-

мер, в HTML-документ, который затем может быть просмотрен чело-

веком через браузер. Такие преобразования выполняются с помо-

щью конструкций, определяемых языком XSLT. Преобразования на

XSLT записываются в виде так называемой таблицы стилей, которая

также представляется в формате XML.

Язык преобразований XSLT – это одна из наиболее мощных

и активно используемых технологий в семействе XML. Этот язык

получил широкое признание и активно используется в информаци-

онных технологиях для представления информации человеку,

а также в качестве средства для преобразования XML-документов

в другие форматы.

Преобразование, выраженное через XSLT (с помощью таблицы

стилей), описывает правила для преобразования исходного дерева

документа в конечное дерево. Структура конечного дерева может

полностью отличаться от структуры исходного дерева, в процессе

построения которого элементы исходного дерева могут подвергаться

фильтрации и переупорядочению, а также могут быть добавлены

новые элементы.

Вопросы преобразования XML-данных для их визуализации

занимают важное место в семействе XML-технологий и довольно

подробно представлены в учебном пособии. В четвертой главе,

посвященной описанию языка XSLT, приведены основы технологии

212

визуального представления содержимого XML-документов, а также

рассмотрены практические вопросы различных аспектов его приме-

нения, которые поясняются наглядными примерами.

Если XSLT представляет собой язык представления данных для

вывода информации, то для представления данных при их вводе

в систему предназначена спецификация XForms. С помощью XForms вы

можете определять Web-формы, отделив предназначение от пред-

ставления. При этом вы сможете уделять больше внимания содер-

жанию и собираемым данным, а не стилю представления. Этот язык

описывает мощную модель событий и устраняет необходимость

в специальных скриптах, используемых для выполнения простых,

связанных с формой, действий.

Следует также отметить, что данная спецификация была разра-

ботана еще в 2001 г., но до сих пор не представлен соответствующий

процессор, встроенный в браузер. Это существенно сдерживает

применение данной спецификации, и перспективы ее дальнейшего

развития пока не определены. Но независимо от того, являются ли

XForms в действительности окончательным решением для разделения

предназначения и представления, эта спецификация определила

направление развития следующего поколения Web-форм.

Студентам весьма полезно ознакомиться с основными положе-

ниями этой спецификации, которая завершает семейство технологий

представления информационных ресурсов, включающих средства:

– описания контента информационного ресурса (язык XML);

– описания структуры XML-документа (язык XSD);

– форматирования XML-документа при выводе данных (язык XSL);

– форматирования XML-документа при вводе данных (язык XForms).

Поэтому, несмотря на неясность перспективы дальнейшего

применения этой спецификации, в пособии этот язык также

рассмотрен, и в пятой главе приведены описания синтаксических

конструкций его основных элементов. Однако ввиду отсутствия

доступных XForms-процессоров, в разделе не представлены дейст-

вующие примеры его использования.

Одной из важнейших целей создания платформы XML является

привнесение в среду Web метаданных, описывающих смысловое

213

содержание (семантику) данных. Простейший способ задания

семантики – это использование пространства имен, рассмотренного

в третьей главе. Механизм пространства имен может определять

аспекты семантики элементов, их атрибутов, а также принимаемых

атрибутами значений XML-документов, путем их отнесения к различ-

ным смысловым группам, известным разработчикам этих XML-

документов.

Более формализованный способ описания семантики XML-

документов обеспечивается средствами RDF-спецификации, пред-

ставляющей собой стандартный способ описания утверждений.

Утверждения характеризуются тем, что данные в них представлены

в окружении контекста, определяющего их смысл.

В RDF-спецификации объявляется некоторое множество ресур-

сов, для каждого из которых контекст определяется в виде тройки

«объект-свойство-значение». Под свойством понимается некая

характеристика, используемая для описания объекта или информа-

ционного ресурса. Значения свойств преимущественно задаются

литерально. Таким образом, свойства могут определять связи между

сущностями (ресурсами) и значениями их характеристик.

В этом смысле способ представления данных с помощью специ-

фикации RDF аналогичен по своим возможностям способу представ-

ления данных в базе. В базах данных значения определяются

в ячейках таблиц, в которых описываются данные о некотором объ-

екте. В строках таблиц представляются экземпляры объекта,

а в колонках – различные его свойства. Значение в ячейке, располо-

женной на пересечении строки и колонки, определяется как значе-

ние известного свойства конкретного экземпляра объекта, описы-

ваемого в данной таблице. Другими словами, данные в базе также

представлены в контексте, определяющем их семантику или смысл.

В настоящее время уже создано значительное количество

свободно распространяемых и коммерческих инструментальных

средств для поддержки RDF-спецификаций. Хотя говорить о его

широком применении на практике пока не приходится, так как,

являясь одной из первых попыток представления семантики данных

в Web-среде, спецификация RDF, по мнению специалистов, обладает

214

большим количеством недостатков, главным из которых является

громоздкость ее конструкций, что делает описание ресурсов

не слишком удобным для применения. Создатели RDF изначально не

имели своей целью коммерческое использование языка, поэтому он

до сих пор остается преимущественно в сфере интересов исследова-

телей. Но вопросы представления семантики в сфере практического

программирования на современном этапе развития информацион-

ных технологий являются весьма актуальными. Поэтому для студен-

тов будет полезно ознакомиться с понятием семантики данных,

одного из труднейших вопросов современной информатики.

Основные положения спецификации RDF изложены в шестой главе

учебного пособия.

215

СПИСОК ИСТОЧНИКОВ

1.Эдди С.Э. XML : справочник. – СПб. : Питер, 1999. – 480 с.

2. XML Schema Part 0: Primer. W3C Recommendation. 2 May 2001.

http://www.w3.org/TR/2001/REC-xmlschema-0-20010502 (дата обра-

щения: 12.01.2017).

3. XML Schema Part 1: Structures. W3C Recommendation. 2 May

2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502 (дата

обращения: 12.01.2017).

4. XML Schema Part 2: Datatypes. W3C Recommendation. 2 May

2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502 (дата

обращения: 12.01.2017).

5. Resource Description Framework (RDF). Model and Syntax Spec-

ification. W3C Recommendation. 22 February 1999.

http://www.w3.org/TR/ REC-rdf-syntax/ (дата обращения: 22.04.2017).

6. Resource Description Framework (RDF). Schema Specification

1.0. W3C Candidate Recommendation. 27 March 2000.

http://www.w3.org/TR/2000/CR-rdf-schema-20000327 (дата

обращения: 22.04.2017).

7. Namespaces in XML. W3C Recommendation, 14 January 1999.

http://www. w3.org/TR/1999/REC-xml-names-19990114 (дата обраще-

ния: 20.01.2017).

8. Style Sheet, level 2. CSS2 Specification. W3C Recommendation.

12 May 1998. http://www.w3.org/TR/1998/REC-CSS2-19980512 (дата

обращения: 22.03.2017).

216

9. Extensible Stylesheet Language (XSL). Version 1.0. W3C Work-

ing Draft. 18 October 2000. http://www.w3.org/TR/2000/WD-xsl-

20001018 (дата обращения: 10.02.2017).

10. XSL Transformations (XSLT). Version 1.0. W3C Recommenda-

tion. 16 November 1999. http://www.w3.org/TR/1999/REC-xslt-

19991116 (дата обращения: 10.02.2017).

11. XForms 1.0. W3C Working Draft 16 February 2001.

http://www.w3.org/ TR/ 2001/WD-xforms-20010216 (дата обращения:

18.05.2017).

12. Document Object Model (DOM) Level 2 Specification. Version

1.0. W3C Recommendation. 13 November 2000.

http://www.w3.org/TR/2000/REC-DOM-Level-2-20001113 (дата обра-

щения: 28.07.2017).

13. XML Query 1.0 Requirements. W3c Working Draft. 15 February

2001. http://www.w3.org/TR/2001/WD-xmlquery-req-20010215 (дата

обращения: 18.05.2017).

14. XQuery 1.0 and XPath 2.0 Data Model. W3C Working Draft.

07 June 2001. http://www.w3.org/TR/2001/WD-query-datamodel-

20010607 (дата обращения: 18.05.2017).

15. XQuery 1.0 Formal Semantics. W3C Working Draft 07 June

2001. http://www.w3.org/TR/2001/WD-query-semantics-20010607 (дата

обращения: 18.05.2017).

16. XML Query Use Cases. W3C Working Draft 08 June 2001.

http://www. w3.org/TR/2001/WD-xmlquery-use-cases-20010608 (дата

обращения: 18.05.2017).

17. XML Syntax for XQuery 1.0 (XQueryX). W3C Working Draft.

07 June 2001. http://www.w3.org/TR/2001/WD-xqueryx-20010607 (дата

обращения: 18.05.2017).

18. XML Path Language (XPath). Version 1.0. W3C Recommenda-

tion, 16 November 1999. http://www.w3.org/TR/1999/REC-xpath-

19991116 (дата обращения: 18.05.2017).

19. ISO/IEC 9579:2000. Information technology - Remote Database

Access for SQL (RDA/SQL) (дата обращения: 08.07.2017).

217

20. Workflow Management Coalition. Workflow Standard - Interop-

erability. Wf-XML Binding. Document Number WFMC TC-1023. Draft

1.0. 20 April 1999 (дата обращения: 08.07.2017).

21. XML Metadata Interchange (XMI). Version 1.1. OMG Document

ad/99-10-02 (дата обращения: 20.01.2017).

22. Open Information Model. XML Encoding. Version 1.0. Review

Draft 2. Meta Data Coalition. December 1999 (дата обращения:

20.01.2017).

23. Open Information Model. Proposed XML Document Type Defini-

tions. Meta Data Coalition. http://www.mdcinfo.com/OIM/xmldtds.html

(дата обращения: 20.01.2017).

24. Common Warehouse Metamodel (CWM) Specification. Volume

2. XML, IDL and DTD. Proposal to the OMG ADTF RFP: Common

Warehouse Metadata Interchange (CWMI). OMG Document ad/00-01-

02. February 11, 2000 (дата обращения: 08.07.2017).

25. Robie J., Lapp J., Schash D. XML Query Language (XQL). The

W3C Query Languages Workshop. December 3-4, 1998. Boston,

Massachusets. http://www.w3.org/TendS/QL/QL98/pp/xql.html (дата

обращения: 18.05.2017).

26. XML Query 1.0 Requirements. W3c Working Draft 15 February

2001. http://www.w3.org/TR/2001/WD-xmlquery-req-20010215 (дата

обращения: 20.05.2017).

27. XQuery 1.0 and XPath 2.0 Data Model. W3C Working Draft.

07 June 2001. http://www.w3.org/TR/2001/WD-query-datamodel-

20010607 (дата обращения: 20.05.2017).

28. XQuery 1.0 Formal Semantics. W3C Working Draft. 07 June

2001. http://www.w3.org/TR/2001/WD-query-semantics-20010607 (дата

обращения: 20.05.2017).

29. XML Query Use Cases. W3C Working Draft 08 June 2001.

http://www. w3.org/TR/2001/WD-xmlquery-use-cases-20010608 (дата

обращения: 20.05.2017).

30. XQuery 1.0: An XML Query Language. W3C Working Draft.

07 June 2001. http://www.w3.org/TR/2001/WD-xquery-20010607 (дата

обращения: 20.05.2017).

218

31. XML Syntax for XQuery 1.0 (XQueryX). W3C Working Draft.

07 June 2001. http://www.w3.org/TR/2001/WD-xqueryx-20010607 (дата

обращения: 20.05.2017).

32. Melton J. Subproject: “XML-Related Specs (SQL/XML)”. Pro-

ject ANSI:1234D-ISO:1.32.3.4. 29 August, 2000 (дата обращения:

12.01.2017).

33. Rofail A., Wyke R.A., Rehman S. XML Programming Bible

(Using XML with Relational Database Management Systems)

http://flylib.com/books/en/4.456.1.29/1/ (дата обращения: 08.07.2017).

34. Shanmugasundaram J., Tufle K., Zhang C., He G., DeWitt D.J.,

Naughton J.F. Relation databases for Quering XML Documents: Limita-

tions and Opportunities. VLDB 1999, p. 302-314. http://www.vldb.org/

conf/1999/P31.pdf (дата обращения: 12.01.2017).

35. Klettke M., Meyer H. XML and Object-Relational Database Sys-

tems – Enhancing Structural Mappings Based on Statistics. WebDB 2000,

p. 63-68. https://link.springer.com/chapter/10.1007/3-540-45271-0_10


36. A. Renner. XML Data and Object Databases: A Perfect Couple?

Proc. of the 17th ICDE Conf., Heidelberg, Germany, 2001, 143–148.

37. Джоэл Ривара (Joel Rivera), Лен Тейнг (Len Taing). Приго-

товьтесь: xForms. – Клуб знатоков datawarehouse, OLAP, XML. Сен-

тябрь 2002 года; http://www.iso.ru/rus/document5918.phtml (дата об-

ращения: 18.05.2017).

38. Tim Berners-Lee – "Semantic Web Road map", Сентябрь 1998;

http://www.w3.org/DesignIssues/Semantic.html (дата обращения:

22.04.2017).

39. Стин Декер, Сергей Мельник, Франк ван Хермелен, и др. –

"Semantic Web: роли XML и RDF", "Открытые системы", Сентябрь

2001; http:// osp.admin.tomsk.ru/os/2001/09/041.htm (дата обращения:

22.04.2017).

40. Ora Lassila, Ralph Swick – "Resource Description Framework

(RDF) Model and Syntax Specification", W3C Recommendation,

Февраль 1999; http://www.w3.org/TR/1999/REC-rdf-syntax-19990222


219

41. Graham Klyne, Jeremy Carroll – "Resource Description Frame-

work (RDF): Concepts and Abstract Data Model", W3C Working Draft,

Август 2002; http://www.w3.org/TR/2002/WD-rdf-concepts-20020829


42. Dan Brickley, R.V. Guha – "RDF Vocabulary Description Lan-

guage 1.0: RDF Schema", W3C Working Draft, Ноябрь 2002;

http://www.w3.org/TR/2002/WD-rdf-schema-20021112 (дата обраще-

ния: 22.04.2017).

43. Diane Hillmann – "Using Dublin Core", Апрель 2001;

http://dublincore.org/documents/usageguide (дата обращения:

22.04.2017).

44. RDFVocabulary Description Language 1.0: RDF Schema, W3C

Working Draft. 23 January 2003. – http://www.w3.org/TR/2003/WD-rdf-

schema-20030123 (дата обращения: 22.04.2017).

220

ГЛОССАРИЙ

Активные контролы – элементы пользовательского интер-

фейса, определяющие, запускающие, а также обрабатывающие

события в экранных формах, реализованных на языке XForms.

Атрибут обязательный – атрибут, для которого в XML-схеме

определен атрибут use со значением "required".

Атрибут с фиксированным значением – атрибут, для которого

в XML-схеме определено фиксированное значение. При создании

экземпляра XML-документа это значение присваивается атрибуту

автоматически. В экземпляре XML-документа это значение не может

быть изменено.

Атрибут со значением по умолчанию – атрибут, для которого

в XML-схеме определено значение по умолчанию. При создании

экземпляра XML-документа это значение присваивается атрибуту

автоматически. При необходимости это значение может быть

изменено.

Атрибут элемента XML-документа – представляется парой

«имя – значение», связанной с данным элементом. Задание атрибутов

обеспечивает альтернативный способ включения информации

в элемент. В спецификации XML не установлено строгих разграниче-

ний относительно типа информации, которую можно описывать

с помощью атрибутов или внутри содержимого элемента.

221

Блок объявлений CSS – следует за селектором и содержит одно

или несколько объявлений, разделяемых точкой с запятой.

Данные формы – определяются в пределах instance, содержа-

щего все поля формы. Модель формы не изменяется от представле-

ния к представлению.

Квалифицированный атрибут XML-документа – атрибут, имя

которого включает префикс пространства имен. Квалифицированные

элементы определяются путем присвоения атрибуту attributeFormDefault

значения qualified.

Квалифицированный элемент XML-документа – элемент, имя

которого включает префикс пространства имен. Квалифицированные

элементы определяются путем присвоения атрибуту elementFormDefault

значения qualified.

Логические компоненты XForms – определяют поведение

формы и описываются: обработчиками событий (event handlers),

связыванием зависимых данных (data bindings), информацией об

инициализации (submission information).

Неквалифицированный (локальный) атрибут XML- документа – атрибут, имя которого не включает префикс простран-

ства имен; это имя может быть использовано только в локальной

схеме. Неквалифицированные элементы определяются путем

присвоения атрибуту attributeFormDefault значения unqualified.

Неквалифицированный (локальный) элемент XML- документа – элемент, имя которого не включает префикс простран-

ства имен; это имя может быть использовано только в локальной

схеме. Неквалифицированные элементы определяются путем

присвоения атрибуту elementFormDefault значения unqualified.

Объект утверждения – значение именованного свойства

субъекта утверждения.

Объявление CSS – задает установку определенного свойства,

такого как размер шрифта, цвет шрифта и т. д., которое будет

использовано для отображения элемента.

222

Ограничения по ключу – определяет элементы или атрибуты,

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

первичных ключей в базах данных.

Ограничения ссылок на значения ключей – определяет

элементы, значения которых являются ссылками на значения

ключей. Являются аналогами вторичных ключей в базах данных.

Ограничения уникальности – накладывают на элементы или

атрибуты ограничения, в соответствии с которыми их значения

должны быть уникальными.

Платформа XML – комплекс средств, базирующийся на

расширяемом языке разметки XML и служащий для описания

и обработки информационных ресурсов Web.

Последовательности – определяют элементы и атрибуты доку-

мента, также как пути файловой системы указывают на папки

и файлы жесткого диска.

Предикат утверждения – именованное свойство субъекта

утверждения.

Представление формы – определяет, как данные модели

встраиваются в презентацию страницы. Выражается с помощью как

элементарных, так и составных контролов. В отличие от HTML, элементарные и составные контролы не связаны с отдельным

представлением, а соотносятся с абстрактной задачей.

Префикс пространства имен – строка, дописываемая к назва-

нию элемента, по которому анализатор может определить, к какой

группе имен оно относится. Префикс определяется с помощью

конструкции вида xmlns:addr=http://www.usps.com/addresses, где xmlns –

атрибут, значением которого является префикс addr, добавляемый

к имени элемента или атрибута, и наименование пространства

имен http://www.usps.com/addresses.

Простой элемент – это элемент XML, который содержит только

текст и не может содержать другие элементы или атрибуты.

223

Простой элемент с фиксированным значением – простой

элемент, для которого в XML-схеме определено фиксированное значе-

ние. При создании экземпляра XML-документа это значение присваи-

вается элементу автоматически. В экземпляре XML-документа это

значение не может быть изменено.

Простой элемент со значением по умолчанию – простой элемент, для которого в XML-схеме определено значение по умолча-

нию. При создании экземпляра XML-документа это значение присваи-

вается элементу автоматически. При необходимости это значение

может быть изменено.

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

элемента, по которому анализатор может определить, к какой группе

имен оно относится, а также именем, представленным URL-адресом

или любой уникальной строкой.

Пространство имен умолчанию – пространство имен, которое

определяется путем объявления атрибута xmlns без префикса.

Процессор XML – это программный модуль, считывающий XML-

документ и обеспечивающий доступ к его содержимому. Он также

предоставляет этот доступ другим программным модулям, которые

манипулируют и отображают содержимое документа.

Расширяемый язык таблиц стилей XSL – спецификация, пред-

ставляющая собой стандартный способ описания таблиц стилей,

применяемых к информации XML-документа с целью ее визуализа-

ции. Позволяет не только форматировать содержимое XML-элемента,

но и преобразовывать содержимое документа с достаточно высокой

степенью гибкости. Сформированная с помощью XSL таблица стилей

состоит из последовательностей и шаблонов.

Селектор CSS – представляет собой конструктивный элемент CSS, используемый для определения имени элемента XML-документа,

к которому относится информация по отображению.

224

Синтаксический анализатор XML – сканирует символьные

данные элемента для XML-разметки. Запрещает использование

в содержательной части XML-документа символы: <, >, &, строку ]]>.

Если эти символы используются как часть данных внутри тегов, то

необходимо воспользоваться либо элементом CDATA, либо конструк-

циями сущностей.

Составной элемент – это элемент XML, содержащий вложенные

элементы, которые могут быть как простыми, так и составными.

Составные контролы – элементы пользовательского интерфей-

са XForms, применяемые для организации и группировки элементар-

ных контролов.

Субъект утверждения – информационный ресурс, аспект

которого описывается с помощью утверждения.

Таблица каскадных стилей CSS – простой язык таблицы

стилей. Оформляется в виде текстового файла с расширением .css, содержащего набор правил, сообщающих браузеру, каким образом

форматировать и отображать элементы в определенном XML-

документе.

Утверждение – способ представления данных о событии в виде

тройки «субъект-предикат-объект».

Фасеты – конструктивные элементы языка XSD, с помощью

которых определяются пользовательские ограничения для XML-

элементов и атрибутов. Используются для определения приемлемых

значений для XML-элементов или атрибутов.

Целевое пространство имен – пространство имен, введенное

с помощью атрибута targetNamespace.

Шаблоны − часть таблицы стилей, предназначенная для транс-

формации данных. Когда XSL-процессор обнаруживает последова-

тельность в документе, он пропускает ее через шаблон и трансфор-

мирует.

Элемент CDATA – текстовый блок XML-документа, в котором

свободно размещаются любые символы, за исключением строки ]]>

225

Элемент XML-документа – основной компонент XML-

документа. В XML-документе элементы определяют его логическую

структуру и несут в себе информацию, содержащуюся в документе.

Типовой элемент состоит из начального тега, содержимого элемента

и конечного тега. Содержимым элемента могут быть символьные

данные, другие (вложенные) элементы, либо сочетание данных

и вложенных элементов. Элементы организованы в иерархическую

древовидную структуру, в которой одни элементы вложены в другие,

и таким образом отражают логическую структуру информации.

Элементарные контролы – элементы управления XForms, используемые для наполнения формы.

Язык RDF – спецификация, представляющая собой стандартный

способ описания утверждений. Утверждения характеризуются тем,

что в них данные представлены в окружении контекста, определяю-

щего их смысл.

Язык XForms – предоставляет расширяемые средства, позво-

ляющие включать в HTML-документы более богатые и динамичные

формы. Создана по технологии MVC и содержит модель данных (Model), вид (View) и контроллер (Controller). Каждая часть полностью

отделима от других и может использоваться в рамках других

технологий.

Язык XML – это SGML-производный язык разметки документов,

позволяющий структурировать информацию разного типа, используя

для этого произвольный набор инструкций. Позволяет описывать

данные произвольного типа.

Язык XSD – формализует набор правил, с соблюдением которых

составляется XML-документ конкретного назначения. С помощью

языка XSD определяется то, каким образом в данных должны

выделяться элементы и их атрибуты, а также, правила описания

структурных отношений между элементами. На сегодняшний день

XSD (XML Schema) представляется как универсальный способ описания

грамматики данных, который может применяться не только для

верификации XML-документов, но и для описания баз данных,

структур данных, используемых в языках программирования и т. д.

226

URL пространства имен – определяется с помощью конструк-

ции вида xmlns:addr=http://www.usps.com/addresses, где xmlns – атрибут,

значением которого является префикс addr, добавляемый к имени

элемента или атрибута, и наименование пространства имен http://www.

usps.com/addresses. При этом необходимо иметь в виду, что уникаль-

ная строка http://www.usps.com/addresses не используется как URL,

т. е. XML-парсер ничего не выгружает с этого URL. Использование

строк, похожих на URL, объясняется необходимостью гарантировать

уникальность имени пространства имен.

227

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ

А

Агрегированная

XML-схема .............................. 102

Атрибуты

в XML-документе ..................... 40

Б

Базовые правила XML ............. 42

Блок объявлений каскадной

таблицы стилей ....................... 122

В

Вещественный тип

в XML-схеме ............................. 54

Вложенные элементы

XML-документа ........................ 37

Встроенные типы данных

XML-схемы ............................... 53

Д

Данные instance в xForms ...... 165

Документ ................................... 33

З

Значение атрибута по

умолчанию ................................. 61

И

Инициализация

в xForms ........................... 164, 169

Инструкции по обработке в

XML-документе ........................ 38

К

Квалифицированные

элементы в XML-схеме ........... 88

Комментарии в

XML-документе ........................ 38

Композиционная

XML-схема .............................. 102

Контрол action ......................... 174

Контрол group ......................... 170

Контрол input .......................... 173

Контрол output ........................ 174

Контрол repeat ......................... 171

Контрол submit ........................ 176

Контрол switch ........................ 172

Контрол trigger ........................ 175

Контролы XForms ................... 160

М

Модель данных XForms ......... 160

228

Н

Начальный (корневой) тег

XML-документа ........................ 37

Не квалифицированные

элементы в XML-схеме ........... 89

О

Обобщенный язык

разметки, GML .......................... 14

Обработчики событий

xForms ...................................... 164

Объявление каскадной

таблицы стилей ....................... 122

Ограничение элемента XML

по набору значений .................. 63

Ограничения по ключу

элемента XML ........................... 84

Ограничения уникальности

элемента XML ........................... 83

Ограничения элемента XML

по длине ..................................... 69


по значению............................... 62


по серии значений .................... 64

Описательные теги ................... 14

П

Подтип language

в XML-схеме ............................ .55

Подтип name в XML-схеме ..... 55

Подтип NCName

в XML-схеме ............................. 56

Подтип nmtoken

в XML-схеме ............................. 55

Пользовательский тип

в XML Schema ........................... 72

Последовательности

таблицы стилей XSL .............. 126

Пролог XML-документа .......... 34

Простой тип (simpleType)

XML-схемы ............................... 51

Простой элемент XML-

документа .................................. 59

Пространства имен

в XML-схеме ............................. 85

Пространство имен для

экземпляров XML-схемы ........ 88

Пространство имен

по умолчанию в XML-схеме ... 86

Р

Раздел CDATA

XML-документа ........................ 38

Разметка (markup) ..................... 15

Расширяемый язык таблиц

стилей XSL .............................. 124

С

Свойство таблицы

каскадных стилей ................... 122

Связывание данных

в xForms ................................... 164

Связь между XPath

и XForms .................................. 160

Селектор каскадной

таблицы стилей ....................... 122

229

Семантический Web ................. 13

Символьные данные

XML-документа ........................ 38

Символьный тип string

в XML-схеме ............................. 55

Синтаксис определения

атрибута ..................................... 61

Сложный тип (complexType)

XML-схемы ............................... 51

Сортировка данных XML ...... 146

Составной тип (complexType)

в XML-схеме ............................. 78

Спецификация Определений

Типа Документа (DTD) ............ 47

Стандартное пространство

имен в XML-схеме ................... 86

Стандартный обобщенный

язык разметки (SGML) ............ 16

Т

Таблица каскадных стилей .... 120

Таблица стилей ....................... 119

Тип anyURI в XML-схеме ....... 57

Тип dateTime в XML-схеме ..... 56

Тип duration в XML-схеме ....... 56

Тип normalizedString

в XML-схеме ............................. 55

Тип token в XML-схеме ........... 55

Ф

Фиксированное значение

атрибута ..................................... 61

Фильтрация данных XML ..... 146

Ц

Целевое пространство имен

в XML-схеме ............................. 86

Целый тип integer

XML-схемы ............................... 54

Ш

Шаблоны таблицы

стилей XSL .............................. 126

Ю

Юникод ...................................... 35

Я

Язык XForms ........................... 156

Язык XML.................................. 29

Язык XML Schema ................... 50

Язык разметки (markup

language) ..................................... 15

Язык разметки гипертекста

(HTML) ...................................... 16

X

XML-платформа ....................... 17

XML-процессор ........................ 36

XSL элемент for-each ............. 142

XSL-элемент

apply-templates ......................... 144

XSL-элемент value-of ............. 139

XSL-элементы ......................... 138

Учебное электронное издание

ТОКМАКОВ Геннадий Петрович

ОСНОВЫ XML-ТЕХНОЛОГИЙ

Учебное пособие

Редактор Н. А. Евдокимова

ЭИ № 990. Объем данных 2 Мб.

Печатное издание ЛР №020640 от 22.10.97

Подписано в печать 13.10.2017. Формат 6084/16. Усл. печ. л. 13,48. Тираж 75 экз. Заказ 846.

Ульяновский государственный технический университет

432027, г. Ульяновск, ул. Сев. Венец, 32.

ИПК «Венец» УлГТУ, 432027, г. Ульяновск, ул. Сев. Венец, 32. Тел.: (8422) 778-113

E-mail: [email protected] venec.ulstu.ru

Date post:	30-Jul-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times