Атрибуты

Ниже мы приводим формат объявления атрибутов. Сюда относятся синтаксис объявления атрибутов, их типы и ключевые слова, определяющие, является ли атрибут обязательным, и т. п.

Синтаксис объявления атрибута:

<!ATTLIST target_element name type default_value ?>

Тип

Атрибут

Пример объявления

Строковый

CDATA

<!ATTLIST image url CDATA>

Маркерный

IDREF

IDREFS

ENTITY

ENTITIES

NMTOKEN

NMTOKENS

<!ATTLIST id ID #REQUIRED>

Перечислимый

<!ATTLIST 11st type (ordered | bullet) "ordered" ?>

Ключевое члово		Описание
#REQUIRED		Этот атрибут должен присутствовать в каждом экземпляре элемента
#IMPLIED		Такой атрибут может не указываться в конкретных экземплярах элемента. Никакого значения для такого атрибута по умолчанию не предусматривается
#FIXED		Этот атрибут должен присутствовать в каждом экземпляре элемента и иметь указанное значение

DTD и допустимость документа XML

DTD, или определение типа документа, — это способ явным образом определить структуру класса документов XML Например, в DTD для перечня животных может быть задано, что для каждого животного нужно указать его имя, вид и характерный звук, который издает это животное DTD для этого перечня может выглядеть так [Animal-list - список животных, animal — животное, name — имя, type — вид, sound — звук. — Примеч перев]:

<!ELEMENT animal-list (ammal)*>

<!ELEMENT animal (name,type,sound)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT type (#PCDATA)>

<!ELEMENT sound (#PCDATA)>

Если бы это определение DTD было стандартным зоологическим определением (фактически это не так), любой зоолог мог бы быть уверен, что его данные сможет прочесть любой другой зоолог и что для составления перечня животных все зоологи используют одни и те же правила Документ XML, который соответ- ствует правилам DTD, то есть какому-то конкретному определению, так же как и общим правилам XML, называется правильно оформленным и допустимым. Ниже показан пример правильно оформленного документа XML, который соответствует приведенному выше определению DTD:

<?xml version="l 0" standalone="no"?>

<!DOCTYPE animal-list SYSTEM "zoology.dtd">

<animal-list>

<name>Бесси</name>

<type>Kopoвa</type>

</ammal>

<name>Ровер</name>

<type>Собака</type>

</animal>

</animal-list>

ПРИМЕЧАНИЕ

Слова, набранные в предыдущих примерах только прописными буквами, являются ключевыми словами XML. Это делается не просто из стилистических соображений. Язык XML чувствителен к регистру, поэтому процессор XML выдаст сообщение об ошибке, если в ключевом слове окажется хоть одна строчная буква. Таким образом, в XML слова DOCTYPE и Doctype не более похожи между собой, чем слова DOCTYPE и EGGDROP.

Если вы программируете на Java,

Описание данных с помощью XML
Если вы программируете на Java, за последние пару лет вам наверняка часто приходилось слышать об XML. Эта глава поможет вам максимально быстро освоиться с технологией XML и с сопутствующей терминологией, так что вы вскоре сможете оценить все преимущества XML. Когда вы начнете разрабатывать приложения с использованием XML, разделы «Краткий справочник по правилам XML» и «Правила XML» данной главы могут пригодиться вам в качестве справочного пособия по XML.

Инструкции по обработке

Инструкции по обработке (Processing Instructions, PI) используются для того, чтобы включить в документ информацию, предназначенную для приложений. Подобно комментариям, инструкции по обработке не считаются частью символьных данных документа. Но в отличие от комментариев, инструкции по обработке не игнорируются анализатором XML, а передаются приложениям.

Инструкции по обработке начинаются с символов <? и заканчиваются символами ?>. Первое слово в PI — это имя того приложения, для которого предназначается данная инструкция. Также можно использовать имя нотации, чтобы связать URI (Uniform Resource Identifier, универсальный идентификатор ресурса) с именем приложения. Следом за идентификационной информацией в PI может содержаться любой тип символьных данных. Ниже приведен пример PI:

<?playsound sounds.mp3?>

Эта инструкция инициирует воспроизведение соответствующим приложением файла формата трЗ.

Использование XML для хранения данных

XML подходит и для создания баз данных. В документе XML используется древовидная структура хранения данных. Хотя по большому счету хранение данных в виде документов XML не слишком эффективно, у такого способа хранения есть свои преимущества. Как и в отношении передачи сообщений, самым большим преимуществом является простота. Древовидная структура — интуитивно понятный и знакомый способ организации данных. Кроме того, почти любой тип древовидной структуры — от реляционных баз данных до объектно-ориентированных баз данных и иерархических структур — может быть представлен с помощью дерева данных XML. Другое существенное преимущество использования XML для хранения данных заключается в том, что XML поддерживает набор символов Unicode. Следовательно, любой символ любого алфавита мира можно включить в документы XML на «законном основании».

Unicode — это официальный путь реализации универсального набора символов (Universal Character Set, UCS), определенного Международной организацией по стандартизации (International Standards Organization, ISO); иначе говоря, это универсальный стандарт кодировки символов для электронного представления текста и его компьютерной обработки. Для преобразования кодировок символов в фактический набор битов используются форматы преобразования UCS, или сокращенно — UTF (UCS Transformation Formats).

Спецификация XML требует, чтобы процессоры XML поддерживали два формата UTF: UTF-8 и UTF-16. В UTF-16 используются два байта для представления каждого символа. В UTF-8 для символов ASCII используется кодировка ASCII, занимающая один байт, а для символов, не входящих в ASCII, — кодировка переменной длины. Формат UTF-8 полезен, если вы хотите поддерживать совместимость с ASCII. Недостатком этого формата является то, что для представления остальных символов (не входящих в ASCII) в нем может потребоваться от 1 до 3 байтов. Если ваш текст в основном состоит из ASCII-символов, UTF-8 позволит вам сэкономить объем памяти. Если же вы используете другие символы, то этот формат, напротив, потребует излишних затрат. По умолчанию в XML применяют формат UTF-8. Кодировка документа определяется в объявлении XML с помощью специального атрибута кодировки (encoding), как показано в следующем примере:

<?xml version="1.0" standalone='no' encochng="UTF-8"?>

Использование XML в приложениях

В данной книге мы будем использовать базу данных XML, предназначенную для хранения каталога товаров, которыми торгует вымышленный электронный магазин. Хотя мы предполагаем, что доступ к данным XML непосредственно из приложений осуществляется достаточно быстро, все же для повышения эффективности можно импортировать XML-базу данных приложения в реляционную базу данных. В настоящее время все поставщики баз данных предлагают средства (или планируют сделать это), позволяющие передавать данные между реляционной базой данных и документами XML, и ряд других вспомогательных инструментальных средств. Данные можно извлекать из любой базы данных и преобразовывать в данные XML, которые используются в приложении, при этом не приходится модифицировать само приложение. Вероятно, в этом и заключается основное преимущество создания приложений, рассчитанных на данные XML: XML — это стандарт, в который могут быть преобразованы данные любого типа, следовательно, приложение гарантированно сможет работать в будущем с данными любого нового типа.

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

Элементы

Ниже мы приводим общие сведения об элементах XML, в том числе о синтаксических правилах, регламентирующих применение элементов и их объявление.

Комментарии в XML

Комментарии (comments) в XML устроены и функционируют так же, как в

HTML, что видно из следующего примера:

<!-этот текст является комментарием.-->

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

В HTML комментарии часто используются в качестве контейнера текста, который не является частью документа, но доступен для программ. Например, команды CGI и JavaScript в документах HTML часто помещаются внутрь комментариев. Но анализаторы XML могут полностью игнорировать комментарии, поэтому в XML этим приемом не следует увлекаться, для этого имеются снециальные инструкции по обработке.

ВНИМАНИЕ

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

Краткий справочник по правилам XML

Этот раздел можно считать кратким справочником по самым основным правилам XML. Полную спецификацию XML можно найти по адресу www.w3c.org.

Модели программирования

Язык SGML был ориентирован на документ как на единое целое, поэтому нет ничего удивительного в том, что и в отношении XML сначала использовался подход, связанный с объектной моделью документа (Document Object Model, DOM). Любая обработка документа в соответствии с моделью DOM предполагает, что документ прошел синтаксический анализ и представлен в памяти в виде древовидной структуры, каждая часть которой одинаково доступна. Этот подход символически иллюстрирует рис. 1.2.

Рис. 1.2. Модель программирования DOM

Когда люди начали программировать в соответствии с моделью DOM, быстро выяснилось, что это не очень удобно — приходилось строить объектную модель всего документа, даже если нужно было отобрать всего лишь несколько элементов. Кроме того, этот способ требует больших ресурсов памяти, что может сделать его использование затруднительным, если не сказать невозможным. В результате возникла необходимость в разработке другого способа, который получил название SAX (Simplified API for XML — упрощенный интерфейс прикладного программирования для XML) И DOM, и SAX представляют собой, таким образом, интерфейсы прикладного программирования, которые были реализованы как на Java, так и на других языках.

Как показано на рис. 1.3, анализатор SAX осуществляет один проход по документу XML, сообщая о результатах анализа путем вызова различных методов из кода вашего приложения. В документации SAX есть термин событие (event): событие происходит, когда анализатор идентифицирует элемент в документе XML, поэтому указанные методы называются обработчиками событий (event handlers). Когда анализатор достигает конца документа, в памяти остается только то, что было сохранено вашим приложением.

Как было сказано ранее и как показано на рис. 1.2 и 1.3, использование DTD не является обязательным в XML.

Рис. 1.3. Модель программирования SAX

Для программирования сервлетов и JSP (JavaServer Pages) полезными могут оказаться обе модели, что демонстрируют приведенные ниже примеры. Сначала рассмотрим инструментальные средства Java для «первого уровня» DOM и для версии SAX 1.0. На момент написания книги версия SAX 2.O. и второй уровень DOM находились в разработке, но ко времени, когда книга будет опубликована, вероятно, эти новые версии уже будут доступны.

Непроверенные символьные данные

Проверенные символьные данные не могут содержать разметку. Следовательно, если вы хотите включить в содержимое элемента символы < или &, вам следует использовать для этого управляющую последовательность. Вы можете заменить эти символы их числовыми заменителями (&#60 и &#38 соответственно) или использовать встроенные в XML ссылки на сущности (&#lt и &#атр соответственно). Имеется еще один вариант, который позволит вам обойтись без управляющей последовательности, — использовать раздел символьных данных (CDATA section), чтобы пометить блок текста как непроверенные символьные данные.

Объявление

Синтаксис:

<!ELEMENT имя_элемента правило>

Тип элемента

Пример объявления

EMPTY

#PCDATA

ANY

Mixed

Children

<! ELEMENT url EMPTY>

<! ELEMENT name #PCDATA>

<! ELEMENT contacts ANY>

<! ELEMENT list (#PCDATA | item)*>

<!ELEMENT co-worker (title, name, address)>

Объявления

Синтаксис:

<!ENTITY имя "заменяемые символы">

Тип сущности

Пример

Описание

Общая

<! ENTITY publisher "Sybex">

Может использоваться только в данных XML

Параметрическая

<! ENTITY *cdata "#CDATA">

Может использоваться только в DTD

Внешняя

<! ENTITY stockquotes SYSTEM "quotes. xml">

Используется для включения внешних файлов XML

Непроверенная

<! ENTITY picture SYSTEM "picture.jpg" NDATA jpg>

Используется для включения файлов, не являющихся файлами XML

Объявления атрибутов

Атрибуты используются для связывания пар имя-значение с элементами. Они определяются с помощью специальных объявлений атрибутов. Формат объявления атрибута в DTD следующий [Target_element — элемент, к которому относится данный атрибут, type — тип, default_value — значение по умолчанию. — Примеч. перев. ]:

<!ATTLIST target_element name type default_value ?>

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

или

<dog>

<name>Snuggles</name>

</dog>

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

Ниже приведены некоторые примеры объявлений атрибутов (несколько позже будет объяснено их значение) [Gender (male|female) — пол (мужской|женский), species — вид, «Cams familiaris» — «собака обыкновенная». — Примеч. перев.]:

<!ATTLIST dog name CDATA #REQUIRED>

<!ATTLIST dog gender (male|female) #IMPLIED>

<!ATTLIST dog species #FIXED "Canis familiaris">

Существует девять различных типов атрибутов, которые подразделяются на три категории: строковые (string), маркерные (tokenized) и перечислимые (enumerated). Строковые атрибуты определяются с помощью ключевого слова CDATA, которое указывается в качестве типа атрибута, как показано в следующем примере:

<!ATTLIST dog name CDATA>

Значением этой строки может быть любая корректная строка символов.

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

<iATTLIST product id ID #REQUIRED>

Атрибуты ID и IDREF можно использовать почти так же, как теги якоря А в HTML Значением атрибута IDREF должно быть значение атрибута ID какого-либо другого элемента (то есть они задают перекрестную ссылку). Например, в следующем фрагменте DTD объявляется элемент с атрибутом ID и элемент с атрибутом IDREF, который ссылается на первый элемент [Featured_products — ключевые товары, product_reference — ссылка на товар — Примеч перев]:

<!ELEMENT product (name.description,price)>

<!ATTLIST product id ID #REQUIRED>

<!ELEMENT featured_products (product_reference)*>

<!ELEMENT product_ref (#PCDATA)>

<!ATTLIST product_ref link IDREF #IMPLIED>

В файле XML, который использует это DTD, может содержаться фрагмент, подобный следующему:

<product id= "X4343">

<name>rock</name>

</product> <featured_products>

<product_ref link = "X4343">a rock</product_ref>

</featured_products>

В атрибутах перечислимых типов приводится список всех возможных значений этого атрибута. Например, если вы хотите объявить атрибут с именем angle_type для элемента, названного triangle, можно указать возможные значения следующим образом [Triangle — треугольник, angle_type — тип угла, obtuse|acute|nght — тупои|острыи|прямой — Примеч перев]:

<!ATLIST triangle angle_type (obtuse | acute | right)? #REQUIRED>

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

Ключевое слово	Определение
#REQUIRED	Этот атрибут должен присутствовать в каждом экземпляре элемента
#IMPLED	Такой атрибут может не указываться в конкретных экземплярах элемента. Никакого значения для такого атрибута по умолчанию не предусматривается
#FIXED	Этот атрибут должен присутствовать в каждом экземпляре элемента и иметь указанное значение

Объявления элементов

Основным базовым типом объявления в DTD является объявление элемента, <!ELEMENT>. Формат объявления элемента:

<!ELEMENT имя_элемента правило>

Каждый элемент, который используется в документе XML, должен быть определен в DTD. Существует несколько правил, которым нужно следовать при именовании элементов:

имена элементов не должны содержать символа < или >;

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

имена элементов не могут начинаться с последовательности xml (в любой комбинации верхнего или нижнего регистров),

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

Объявления сущностей

Объявления сущностей позволяют использовать ссылки на сущность. Ссылка на сущность (entity) — это последовательность символов, которая автоматически подставляется вместо другой последовательности символов. Обычно ссылки на сущность требуются для того, чтобы обозначить символы, которые иначе могут быть приняты за символы разметки. Если вы имели дело с HTML, то, вероятно, сталкивались со ссылками на сущность. Наиболее распространенный тип сущности — это общая сущность (general entity), то есть сущность, которую можно подставить вместо символов в документах XML Формат объявления общей сущности следующий:

lt;!ENTITY имя_сущности "заменяемые символы">

Ссылки на сущность имеют вид &имя_сущности; В XML имеется пять встроенных сущностей. Их не обязательно объявлять в DTD, хотя в спецификации XML это сделать рекомендуется, чтобы гарантировать возможность взаимодействия с HTML и SGML. Пять встроенных сущностей перечислены в приведенной ниже таблице:

Ссылка на сущность

Числовой заменитель

Символ

Эти сущности можно объявить следующим образом:

<!ENTITY lt "&#38,#60,">

<!ENTITY gt "&#62,">

<!ENTITY amp "&#38,#38,">

<!ENTITY apos "&#39,">

<!ENTITY quot "&#34,">

ПРИМЕЧАНИЕ

Символы < и & в объявлениях It и amp дважды экранируются (escaped), чтобы обеспечить выполнение требований о хорошем оформлении документа XML. Другими словами, символы & и < — это два символа, которые сообщают процессору XML, что следующий текст — это фрагмент разметки. Если эти символы не экранировать дважды в объявлениях сущности, то процессор XML будет интерпретировать их как начало нового фрагмента разметки, не дойдя до конца объявления сущности, и сгенерирует ошибку.

Встроенные ссылки на сущности необходимы для создания документов XML, в которых любой из приведенных символов используется сам по себе, а не как фрагмент разметки Ссылки на общие сущности, которые вы определяете самостоятельно, удобны для присваивания имен последовательностям символов, которые вы часто используете. Например, чтобы объявить ссылку на сущность, представляющую символ торговой марки (™), можно включить следующее объявление:

<!ENTITY tm "&#8482">

Символ торговой марки можно затем вставить в любой документ XML, в котором имеется DTD с этим объявлением. Например:

<product_name>

Super Dnnk&tm;

</product_name>

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

Ниже приведен пример некорректного определения сущностей:

<!ENTITY myentity "please see &myotherentity, ">

<!ENTITY myotherentity "please see &myentity; ">

А это — корректное определение:

<!ENTITY tm "&#8482">

<!ENTITY myentity "I enjoy Super Dnnk&tm; ">

Объявление параметрических сущностей

Также можно объявлять ссылки на сущности, которые в DTD будут заменяться определениями сущности. Такой тип сущностей называется параметрическим. Ссылка на параметрическую сущность (parameter entity) начинается с символа * и не может присутствовать внутри документа XML — только в DTD, где она определяется. Ниже приведен пример использования параметрической сущности:

<!ENTITY % actors " (Joe, Mary, Todd, Bill, Jane)* ">

<!ELEMENT dialog %actors;>

Объявление внешних сущностей

Внешние сущности (external entities) — это способ включить внешние файлы в документ XML. Они объявляются следующим образом:

<!ENTITY latest_pnces SYSTEM

"http://www.getthepncesofthings.com/today.xml">

После объявления внешней сущности вы можете включить содержимое указанного документа XML в ваш документ, используя ссылку на сущность — в данном случае &latest_prices.

Объявление непроверенных сущностей

Непроверенные сущности (unparsed entities) можно использовать для включения в документ XML данных в формате, отличном от XML. Для определения такой сущности используется ключевое слово NOATA. Например:

<!ENTITY bookcover SYSTEM

"http://www.sybex.com/books/xml/javadevguide.gif" NDATA gif>

Непосредственно за ключевым словом NDATA следует ключевое слово нотации (notation data keyword). Это ключевое слово объявляется с помощью объявления нотации. Объявления нотации (notation declarations) предоставляют дополнительную информацию (например, для идентификации) или, как в данном случае, сведения о формате для непроверенных данных. Ключевое слово нотации определяется с помощью объявления <!NOTATION>. Например:

<!NOTATION gif SYSTEM

"-//CompuServe//NOTATION Graphics Interchange Format 89a//EN">

Области применения XML

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

Определение правильно оформленного документа XML

Весь текст XML-документа можно грубо разделить на две категории, символьные данные и разметку. К разметке (markup) относится все, что начинается с символа < и заканчивается символом > или начинается с символа & и заканчивается парой символов &;. Символьные данные (character data) — это все, что не является разметкой. Символьные данные можно подразделить еще на две категории: проверенные символьные данные (Parsed Character DATA, PCDATA) и непроверенные символьные данные (unparsed character data). Как следует из названия, данные PCDATA — это данные, проверенные анализатором XML.

В листинге 1.3 показан пример правильно оформленного документа XML [Beverage — напиток, manufacturer — производитель, nutntion_facts servmg_size= "1 can' — содержание питательных веществ в одной бутылке, calories — калории, amount unit="g" — количество в граммах, fat — жиры, sodium — натрий, carb — углеводы, protein — белки — Примеч перев ]:

Листинг 1.3. Правильно оформленный документ XML

<?xml version="1.0" standalone="yes"?>

<name>Вода в бутылках</name>

<name>Напитки высшего качества</name>

</manufacturer>

<nutrition_facts serving_size="1 can">

</calones>

<fat>

</fat>

</sodium>

<carb>

</carb>

</protein>

</nutntion_facts>

</beverage>

В первую очередь в этом листинге следует отметить, что в объявлении XML присутствует атрибут standalone="yes". Это означает, что в данном документе нет определения DTD. Наличие DTD в документах XML не является обязательным. Фактически приложения, в которых задействованы данные XML, часто не включают DTD в целях повышения эффективности в тех случаях, когда структура документа и возможность его многократного использования не являются важными факторами.

Следом за объявлением XML идут элементы. Элемент (element) — это наиболее распространенная форма разметки; он выделяется с помощью угловых скобок (< и >) и описывает тот фрагмент данных, который заключен между скобками > и <. Элемент состоит из открывающего и закрывающего тегов (<beve- rage>...</beverage>, например). Имя элемента называется его общим идентификатором (Generic Identifier, GI) или типом (type). Текст между открывающим и закрывающим тегами называется содержимым (content) элемента. Например, типом следующего элемента является book (книга), а название книги (Java Developer's Guide to XML) — его содержимым:

<book> Java Developer's Guide to XML </book>

Элемент, лишенный содержимого, называется пустым элементом (empty element). Открывающий и закрывающий теги пустого элемента можно объединить в один тег, поместив в его конец косую черту: . В XML также допускается запись пустого элемента с помощью открывающего и закрывающего тегов, например .

Фактически существуют два типа пустых элементов: те, которые заранее определены как пустые и в принципе не могут иметь содержимого, и те, которые оказались пустыми случайно. Чтобы различить эти два типа элементов, рекомендуется использовать пару (открывающий тег, закрывающий тег) для тех элементов, которые не содержат данных, и один тег для тех элементов, которые определены как пустые.

Например, тег HTML не может иметь содержимого, поэтому его нужно записывать как Если же, к примеру, в вашем документе XML имеется экземпляр элемента, который в данный момент не имеет содержимого, но может получить его в дальнейшем, следует использовать стандартный синтаксис, то есть два тега [Cupboard — шкаф — Примеч перев ]:

<cupboards></cupboards>

У элементов могут быть атрибуты. Атрибут (attribute) — это пара имя-значение, расположенная в открывающем теге элемента. В следующем примере src, width и height являются атрибутами элемента img [Image — изображение, width — ширина, height — высота — Примеч перев ].

<img src = "balloons.gif" width= "100" height = "100" />

СОВЕТ

Если вы хотите, чтобы ваш код HTML был совместим с XML, то обратите внимание, что тег HTML переноса строки способен причинить немало хлопот. Некоторые браузеры не воспринимают тег , а пару тегов воспринимают как два переноса строки. Для решения этой проблемы поместите пробел между символами br и косой чертой: .

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

Правила XML

В, настоящее время HTML-браузеры, как правило, делают попытки отобразить любой документ, даже содержащий ошибки или использующий очень старую версию HTML. С другой стороны, процессоры XML должны сообщать о неисправимой ошибке в случае, если они встречают ошибку в разметке. Неисправимая ошибка (fatal error) означает, что приложение не может выполняться далее, и выдает сообщение об ошибке. Такая строгая обработка ошибок иногда называется драконовской (draconian error-handling). Хотя этот способ обработки ошибок для тех, кто создает свои документы на HTML или на SGML, может показаться примитивным, в случае с XML он необходим, так как гарантирует, что любые XML-анализаторы будут воспринимать данный документ XML одинаково.

Документ XML, соответствующий правилам синтаксиса XML, называется правильно оформленным (well-formed). Авторы XML включили требование об этом в спецификацию XML, чтобы предотвратить для XML опасность стать жертвой так называемых «войн браузеров». Результатом таких «войн» между Microsoft и Netscape стало то, что теперь при создании HTML-документа авторам приходится постоянно заботиться о совместимости. Если бы такая история приключилась и с языком XML, он стал бы совершенно бесполезным.

Процессор XML (XML processor) — это программный модуль, который обеспечивает доступ приложений к данным, хранящимся в документах XML. Процессоры XML могут быть как проверяющими, так и не проверяющими допустимость (validating) документа. Проверяющий допустимость документа процессор определяет, существует ли для данного XML-документа DTD, и в случае положительного результата — соответствует ли структура документа правилам, указанным в DTD. Не проверяющий допустимость документа процессор должен удостовериться только в том, что документ соответствует правилам XML.

Применение

Примеры:

<tag/>

<tag attribute="value"> какой-нибудь текст </tag>

Примеры:

while( a %lt; b) // для представления кода Java в HTML

Программирование на основе DOM

Окончательная версия API для работы с объектной моделью документа находится в пакете org.w3c.dom, одобренном Консорциумом W3C. Этот интерфейс API включает в себя определения интерфейсов и один класс исключений. Основная идея заключается в том, что документ XML преобразуется в документ DOM, состоящий из объектов Java, которые реализуют эти интерфейсы. Любая часть документа становится объектом, а связи между объектами отражают иерархическую структуру документа.

Анализ XML для создания DOM

С точки зрения программиста, нет ничего проще, чем создать документ DOM, поскольку вся работа фактически делается анализатором. Все, что должен сделать программист, — это создать входной поток, выбрать анализатор и отойти в сторону. В листинге 1.9 показан шаблон метода, который считывает данные из файла с помощью утилит из пакета com.sun.xml.parser и возвращает объект com.sun.xml.tree.XmlDocument Класс Xml Document реализует интерфейс Document, как указано в спецификации W3C.

Если вы используете утилиты других пакетов, то конкретные имена могут измениться, но общий принцип останется прежним. В этом конкретном примере используются классы интерфейса прикладных программ Java для анализа XML (Java API for XML Parsing, JAXP), предложенные компанией Sun, которые в настоящее время используются в ядре сервлетов (servlet engine) Tomcat.

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

Листинг 1.9. Шаблон метода создания объекта XmlDocument

public XmlDocument exampleDOM(String src ) {

File xmlFile = new File( src ) ;

try {

InputSource input = Resolver create!nputSource( xmlFile );

// ... флажок "false" указывает, что проверка не нужна

XmlDocument doc = XmlDocument.createXmlDocument (input, false);

return doc ;

}catch(SAXParseException spe ){

// здесь обрабатываются исключения, возникшие при

// синтаксическом анализе

}catch( SAXException se ){

// здесь обрабатываются другие исключения SAX

}catch( IOException ie ){

// здесь обрабатываются исключения ввода-вывода

}

return null ;

}

Имея в памяти объектную модель документа, вы можете манипулировать ею с помощью методов интерфейса DOM из пакета org.w3c.dom, а также с помощью дополнительных инструментальных средств.

Программирование на основе SAX

Основные этапы обработки документа XML на основе SAX можно сформулировать следующим образом.

Создание одного или нескольких пользовательских классов для обработки событий анализатора SAX.

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

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

Присоединение классов, обрабатывающих события, к анализатору.

Присоединение входного потока к анализатору, начало анализа.

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

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

Таблица 1.1. Сравнение программирования на основе DOM и SAX

Фактор

DOM

SAX

Требования к ресурсам памяти

Могут оказаться довольно высокими

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

Скорость первой обработки

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

Высокая, особенно если нужные элементы легко локализуются

Скорость повторной обработки

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

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

Допустимость модификации

Очень высокая

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

Разделы символьных данных

Разделы символьных данных начинаются со строки <![CDATA[ и заканчиваются строкой ]]>. Кроме строки ]]>, содержимое раздела символьных данных не подвергается синтаксическому анализу. Если вы хотите включить пример кода XML в документ XML, вместо того чтобы заменять все символы & и It на &lt и &атр, можете включить весь блок, содержащий эти символы, в раздел символьных данных. Например:

Это пример правильно оформленного документа XML:

<!CDATA[

<?xml version="1.0" standalone="yes"?>

<name>Super-Drink</name>

<name>Extra Good Beverages</name>

</raanufacturer>

</beverage>

]]>

</example>

Схема XML

Хотя определения DTD в настоящее время являются стандартом определений типов документов XML, у них есть несколько серьезных ограничений. Определения DTD были унаследованы от языка SGML, где они были исходно разработаны для определения языков разметки, а не для создания схем баз данных. Самое существенное ограничение определения DTD заключается в том, что оно не обеспечивает достаточного контроля над содержимым элементов. Например, с помощью DTD невозможно указать, что показанный ниже элемент является допустимым [Today's date — сегодняшняя дата — Примеч. перев. ]:

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

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

В результате этих ограничений, а также из-за того, что XML все больше используется для хранения данных, были предложены некоторые альтернативные варианты. В настоящее время среди них лидирует язык определений схем XML (XML Schema Definition Language, XSD).

ПРИМЕЧАНИЕ

На момент написания данной книги XSD находится в стадии разработки. Это означает, что к моменту, когда этот язык получит официальный статус, в нем могут произойти значительные изменения по сравнению с нынешней версией. Со спецификацией XSD можно ознакомиться по адресу www.w3.org/XML/Schema.html.

Назначение схем XML то же, что и DTD: определение классов документов XML. Основная разница между ними заключается в том, что в схемах XML все элементы подразделяются на два типа: простые и сложные.

Элементы, которые содержат другие элементы или атрибуты наряду с символьными данными, относятся к типу сложных (complex), а те элементы, которые содержат только символьные данные, называются простыми (simple) элементами. Атрибуты всегда имеют простой тип. В листинге 1.5 показана схема XML для каталога товаров. В листинге 1.6 приведен документ XML, использующий эту схему [On sale date — дата начала продаж, quantity in stock — количество имеющегося в наличии товара. — Примеч. перев. ].

Листинг 1.5. Схема для каталога (catalog.xsd)

<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<xsd:element name="Catalog" type="CatalogType"/>

<xsd:complexType name="CatalogType">

<xsd:element name="product" type="ProductType"/>

<xsd:attribute name="onSaleDate" type="xsd:date"/>

<xsd:attribute name="partNum" type="Sku"/>

</xsd:complexType>

<xsd:complexType name="ProductType">

<xsd:element name="productName" type="xsd:string"/>

<xsd:element name="quantity_in_stock">

<xsd:simpleType base="xsd:positivelnteger">

<xsd:maxExclusive value="500"/>

</xsd:simpleType>

</xsd:element>

<xsd:element name="pnce" type="xsd'decimal"/>

<xsd:element name="description" type="xsd:string" minOccurs="0"/>

</xsd:complexType>

<xsd:simpleType name="Sku" base="xsd:string">

<xsd:pat tern value="\[A-Z]{3}-[A-Z]{3}d{3}"/>

</xsd:simpleType>

</xsd:schema>

<catalog>

<product partNum="ABC-PR0336" onSaleDate="12/12/2004">

<productName>BigSoft Xtreminator 3.36</productName>

<quantity_in_stock>20</quantity_in_stock >

<price>195.99</price>

<description> Managing your life has never been so easy.</description>

</product>

<product partNura="ABC-PR0343" onSaleDate="12/12/2004">

<productName>E-Dev ProntoWorks</productName>

<quanti ty_in_stock>35</quantity_in_stock >

<price>299.99</price>

<description>The premier integrated rapid e-development suite for busy e-professionals.</description>

</product>

</catalog>

Элементы сложного типа определяются с помощью элемента compl exType. Как было уже сказано, элементы сложного типа содержат другие элементы и атрибуты. Элементы и атрибуты, содержащиеся внутри сложных элементов, определяются с помощью элементов element и attribute соответственно. Например, в листинге 1.5 элемент product определен как элемент сложного типа. Внутри определения типа ProductType определяются пять элементов: productName, quantity_in_stock, price, comment и partNum.

Элементы простого типа не имеют атрибутов и не содержат других элементов. В XSD имеется ряд встроенных простых типов, в том числе string, binary, boolean, double, float и т. д. На основе встроенных простых типов можно сконструировать дополнительные простые типы. В частности, в предыдущем примере определяется простой тип Sku, сконструированный на основании типа string.

Процесс конструирования новых простых типов из уже существующих называется ограничением (restriction). Обратите внимание, что в определении нового типа Sku используется регулярное выражение, задающее шаблон, которому должно соответствовать содержимое любого элемента или атрибута данного типа.

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

Создание таблиц стилей с использованием XSL

Расширяемый язык таблиц стилей (Extensible Stylesheet Language, XSL), как следует из его названия, — это язык для конструирования таблиц стилей. Таблицы стилей XSL используются для описания внешнего вида документов XML, предназначенных для чтения людьми.

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

Применение таблицы стилей к документу процессор таблиц стилей осуществляет в два этапа. Первый этап — трансформация дерева (tree transformation). Вы можете, например, написать таблицу стилей, которая расположит товары в вашем каталоге в алфавитном порядке или пронумерует их, прежде чем отобразить. Трансформация дерева позволяет также перемещать данные XML и выполнять вычисления с этими данными.

Второй этап — форматирование (formatting). Форматирование фактически представляет собой процесс задания стиля отображения данных, размеров шрифтов, разрывов страниц и т. п.

Спецификация XSL содержит три различных языка, предназначенных для осуществления этих двух задач:

XML Path Language (XPath) — язык для создания ссылок на различные части документа XML;

XSL Transformations (XSLT) — язык, предназначенный для генерации дерева документа;

Extensible Stylesheet Language (XSL) — XSLT плюс описание набора объектов форматирования и свойств форматирования.

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

Листинг 1.7. Пример каталога музыкальной библиотеки (MyMusic.xml)

<?xml version="l.0"?>

<cd>

<title>Just Singin' Along</title>

<artist>The Happy Guys</artist>

A lovely collection of songs that the whole family can sing right along with.

</description>

<song><title>I'm Really Fine</title></song>

<song><title>Can't Stop Grinnin'</title></song>

<song><title>Things Are Swell</title></song>

<purchase_date>2/23/1954</purchase_date>

</cd>

<cd>

<title> It' s Dot Com Enough for Me: Songs From Silicon Somewhere </title>

<artist>The Nettizens</artist>

<description> A collection of the best folk music from Internet companies. </description>

<song><title>My B2B Is B-R-0-K-E</title></song>

<song><title>Workin' in a Cubicle</title></song>

<song><title>Killer Content Strategy</title></song>

<song><title> She Took the Bricks. I Got the Clicks </title></song>

<purcnase_date>7/12/2000</purchase_date>

</cd>

</library>

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

Листинг 1.8. Таблица стилей, генерирующая документ HTML (CDstyle.xsl)

<?xml version="l.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">

<xsl:template match="/">

<TABLE STYLE="border:lpx solid black; width:300px">

<TR STYLE="font-size:10pt; font-family:Verdana; font weight:bold; text-decoration:underline">

<TD>Title</TD>

<TD>Artist</TD>

</TR>

<xsl:for-each select="library/cd">

<TR STYLE="font-family:Verdana; font-size:12pt; padding:0px 6px">

<TD><xsl lvalue-of select=" title"/></TD>

<TD><xsl:value-of select="artist"/></TD>

</TR>

</xsl:for-each>

</TABLE>

</xsl:template>

</xsl:stylesheet>

Связать таблицы стилей с документом XML можно с помощью инструкции по обработке. Например:

<?xml-stylesheet href="CDstyle.xsl" type="text/xsl"?>

Также вы можете использовать каскадные таблицы стилей (Cascading Style Sheets, CSS) для применения определенного формата к данным XML. В этом случае вы должны связать документ с таблицей стилей с помощью инструкции по обработке, подобной следующей:

<?xml-stylesheet href="CDstyle.ess" type="text/css"?>

В листинге 1.8 показан базовый пример трансформации данных XML с помощью стандартной таблицы стилей. XSLT находит данные, которые соответствуют некоторому образцу, и вставляет их в нужное место шаблона. Поиск соответствия с образцом — очень важная часть XSL. Посмотрим на образец, который применялся во второй части нашего примера:

<xsl:for-each selееt="library/cd">

Эта строка задает цикл по всем экземплярам элемента cd внутри элемента library. Если вы хотите создать разделенный запятыми список всех песен на каждом диске (каждому диску соответствует свой экземпляр элемента cd), вы можете задать еще один цикл внутри приведенного выше цикла, как показано в следующем примере:

...

<xsl:for-each select="library/cd">

<TR STYLE="font-family:Verdana; font-size:12pt; padding:0px 6px">

<TD><xsllvalue-of select="title"/></TD>

<TD><xsl:value-of select="artist"/></TD>

<TD>

<xsl:for-each select="song">

"<xsl :value-of select="title"/>"

<xsl:if test="context()[not(end())]">, </xsl:if>

</xsl: for-each>

</TD>

</TR>

</xsl:for-each>

...

Если получившийся документ XML открыть в браузере, поддерживающем XSL, то он будет выглядеть примерно так, как показано на рис. 1.1.

Рис. 1.1. Результат применения таблицы CDstyle.xsl к файлу MyMusic.xml

Спецификация содержимого

В объявлении элемента вы указываете, что может появиться в качестве содержимого этого элемента Если вам нужно объявить элемент, который не должен содержать никаких данных, вы можете использовать тип EMPTY (например, <!ELMENT img EMPTY>).

Хороший пример пустого элемента — элемент HTML img Чтобы этот элемент не нарушал принципа допустимости документа XML, нужно использовать синтаксис, определенный для пустого элемента XML:

Если вам нужно, чтобы в элементе были только данные PCDATA, используется следующее объявление:

<!ELEMENT mymemoirs #PCDATA>

Вы можете также указать, какие типы элементов могут появиться в элементе, в каком порядке и в каком количестве, как показано в следующем примере [My memoires — мои воспоминания, title — название, author — автор, philosophizing — философствования, sad_story — грустная история, funny_story — смешная история, lesson — наставление, conclusion — вывод — Примеч nepee ]:

<!ELEMENT mymemoires (

title, author, philosophizing, sad_story,

funny_story, lesson, conclusion)>

В данном примере каждый из приведенных типов элементов должен появиться один раз (и только раз) внутри элемента mymemories в том порядке, в котором они перечислены в объявлении.

ПРИМЕЧАНИЕ

Элементы, которые появляются в элементе mymemoires, называются его дочерними элементами, а сам элемент mymemoires называется родительским. Каждый элемент может быть дочерним по отношению к любому количеству других элементов в документе. Элементы, разделенные более чем одним уровнем в иерархической системе, называются внуками, правнуками и т. д. (или соответственно дедами, прадедами — в другом направлении). Также можно при описании взаимоотношений между элементами использовать термины «предок» и «потомок».

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

? — элемент должен встретиться один раз или не встретиться ни разу;

+ — элемент должен встретиться один или более раз;

* — элемент может встретиться любое количество раз или не встретиться вовсе.

Ниже снова приведено объявление элемента mymemoirs, переписанное с использованием операторов повторяемости:

<!ELEMENT mymemoires (title, author, philosophizing+,

sad_story*, funny_story*,

lesson*, conclusion)>

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

<!ELEMENT mymemoires (title, author, philosophizing+,

sad_story*, funny_story*,

lesson+| conclusion)>

В этом объявлении элемент mymemoirs может содержать один или более элементов lesson или conclusion, но не оба одновременно. Еще более сложные правила можно создавать с использованием вложенных скобок. В листинге 1.4 показано, как может выглядеть определение mymeroirs.dtd [Paragraph - абзац, letter — письмо. — Примеч. перев. ].

Листинг 1.4. Полная версия определения mymeroirs.dtd

<!ELEMENT mymemoirs (title, author, philosophizing*,

sad_story*, funny_story*,

(lesson+ | conclusion)*)>

<!ELEHENT title (#PCDATA)>

<!ELEMENT author (#PCDATA)>

<!ELEMENT philosophizing (paragraph)*>

<!ELEMENT sad_story (paragraph*, letter*, (lesson | conclusion)*)>

<!ELEMENT funny_story (paragraph*, letter*.

(lesson | conclusion)*)>

<!ELEMENT letter (paragraph)*>

<!ELEMENT lesson (paragraph)*>

<!ELEMENT conclusion (paragraph)*>

<!ELEMENT paragraph (#PCDATA)>

Наименее строгим является правило, которое можно выразить словами: «подходит что угодно». Если вы хотите указать, что в данном элементе могут появиться любые проверенные символьные данные или элементы, вы должны использовать ключевое слово ANY (любой), как показано в следующем примере:

<!ELEMENT mymemoirs ANY>

ПРИМЕЧАНИЕ

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

Сущности

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

Требования к правильно оформленному документу XML

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

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

неправильно: <Name></name>;

правильно: <name></name>.

Элементы должны быть правильно вложены друг в друга. Варианты:

неправильно. <р> какой-нибудь текст </р>;

правильно: <р> какой-нибудь текст </р>.

Имена элементов не должны содержать символа < или > и должны начинаться с буквы или символа подчеркивания

Имена элементов не могут начинаться с символов xml (в любой комбинации верхнего и нижнего регистров)

В именах элементов не должно содержаться двоеточия, за исключением пространств имен.

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

Значения атрибутов должны быть заключены в кавычки.

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

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

Введение в XML

Расширяемый язык разметки (Extensible Markup Language, XML), созданный в 1996 году Консорциумом W3C (World Wide Web Consortium), является подклассом стандартного языка разметки (Standard Generalized Markup Language, SGML). XML был задуман как гибкий и в то же время формальный метаязык для использования в Интернете.

Метаязык (metalanguage) — это язык, предназначенный для описания других языков. Например, можно сказать, что словарь английского языка в совокупности с английской грамматикой образуют метаязык, описывающий английский язык.

Что касается языка XML, то назначение его — описывать языки разметки. В языке разметки (markup language) для структурирования данных используются теги. Язык гипертекстовой разметки (Hypertext Markup Language, HTML), наиболее распространенный на сегодняшний день язык разметки, исходно был написан на SGML, но мог бы быть и в какой-то степени был написан и на XML.

Язык HTML был задуман для решения специфических задач — разметки документов научной и академической направленности. Если вы занимались какой-либо деятельностью по разработке web-страниц, то хорошо знаете, что в настоящее время HTML «трещит по всем швам», так как на протяжении многих лет делаются попытки дополнить его так, чтобы он соответствовал всем запросам web-программистов. Многие называют XML заменой HTML, но это не совсем точное высказывание.

В то время как HTML содержит фиксированный набор тегов, в XML теги вообще отсутствуют. Вместо этого XML позволяет программисту самому создать такой язык разметки, который в точности соответствует требованиям конкретного приложения. В нашей книге мы проиллюстрируем процесс создания приложения, относящегося к области электронной коммерции. Язык разметки, который мы будем использовать, содержит теги, выглядящие осмысленно именно в этой области (такие, например, как <price> и <quantity>) [Price — цена, quantity — количество. — Примеч. перев. ].

В приложениях XML обычно используются следующие типы данных и вспомогательные функции:

сам файл XML, имеющий строго определенную структуру;

определение типа документа (Document Type Definition, DTD), где определяется структура файла XML (необязательный элемент);

таблицы стилей, содержащие информацию о том, как данные должны быть отформатированы при выводе (необязательный элемент);

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

XML и электронная коммерция

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

К примеру, предположим, что вы — торговый посредник и занимаетесь продажей электрических лампочек. На вашем web-сайте приводится самая свежая информация о ценах на товары от различных производителей. Вместо того чтобы вручную проверять web-сайты этих производителей и таким образом узнавать информацию о ценах, вы решаете написать программу, которая автоматически бы считывала цены, добавляла бы 10 % (надбавка для вас) и отображала бы информацию о товарах на вашем web-сайте. Пусть одним из ваших поставщиков является фирма ABC Lightening. В листинге 1.1 приводится часть кода HTML для таблицы, содержащей данные о товарах из web-сайта ABC Lightening [Авторы книги в листингах глав 1 и 2 приводят вымышленные описания товаров, которые не следует воспринимать всерьез. — Примеч. перев. ].

Листинг 1.1. Код HTML для таблицы, содержащей информацию о товарах [Все представленные в книге тексты программ можно найти на сайте издательства по адресу www.piter.com. — Примеч. ред. ]

<table>

<tr>

<th>Название товapa</th>

<th>0писание</th>

<th>Ценa</th>

</tr>

<tr>

<td>Фонарик

</td>

<td>Свет, который всегда с вами!</td>

<td>$9.95</td>

</tr>

<tr>

<td>Неоновая лампа</td>

<td>Ничто не скажет слово "класс" так,

как неоновая лампа!</td>

<td>$14.75</td>

</tr>

</table>

Документ HTML только определяет, как должен быть отформатирован данный текст. Автоматическое извлечение информации из статической страницы HTML даже в лучшем случае окажется весьма непростой задачей. Если вы хотите написать программу, которая бы извлекала данные о цене из приведенного кода HTML, вы можете указать, что цена фонарика присутствует в третьем столбце таблицы в той строке, где в первом столбце стоит слово «фонарик». Но при этом вы рискуете тем, что ваша программа перестанет работать, если изменится дизайн web-сайта ABC Lightening или просто поменяется название данного товара.

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

В листинге 1.2 приведен пример того, как та же информация может быть представлена с помощью XML [Catalog — каталог, product — товар, name — название, description — описание. — Примеч. перев ].

Листинг 1.2. Документ XML, содержащий информацию о товарах

<?xml version="l.0" standalone="no"?>

<!DOCTYPE ABC_Lighting: catalog SYSTEM "catalog.dtd">

<ABC_Ughting: catalog xmlns:ABC_Lighting =

"http://www.abclighting.com">

<ABC_Lighting:product>

<ABC_Lighting:name>Фонарик</ABC_Lighting:name>

<ABC_Lighting:description>Cвeт, который всегда с вами!

</ABC_Lighting:description>

<ABC_Lighting:price>$9.95</ABC_Lighting:price>

</ABC_Lighting:product>

<ABC_Lighting:product>

<АВС_Lighting:name>Неоновая лампа</ABC_Lighting:name>

<ABC_Lighting:description>Ничто не скажет слово "класс"

так, как неоновая лампа!</ABC_Lighfmg:description>

<ABC_lighting:price>$14.75</ABC_Lighting:price>

</ABC_Lighting:product>

</ABC_Lighting:catalog>

Первая строка этого документа — объявление XML, которое содержит информацию, предназначенную для анализатора XML. Объявление XML (XML declaration) идентифицирует тип документа и версию XML, которая использовалась при создании документа. Эта строка не является обязательной, но, как правило, именно с нее начинается документ XML. Атрибут standalone = "no" означает, что данный документ снабжен DTD. Следующая строка — это объявление типа документа (document type declaration), которое указывает, какому DTD соответствует этот документ. В данном случае используется определение DTD, называемое catalog.dtd. Обратите внимание на то, что, хотя аббревиатуры совпадают, имеется большая разница между определением типа документа (сокращенно DTD — Document Type Definition) и объявлением типа документа. Объявление типа документа используется, чтобы указать, какому определению типа документа соответствует данный документ XML.

В объявлении типа документа также указывается корневой элемент документа. Корневой элемент (root element) — это элемент, который включает в себя все остальные элементы документа. В данном случае корневым является элемент ABC_Lightening:catalog. Часть имени элемента, расположенная перед двоеточием, идентифицирует пространство имен тега. Пространства имен не являются обязательными, но их можно использовать для того, чтобы гарантировать уникальность тегов. Если фирма ABC_Lightening начнет продавать товары других производителей, то пространства имен помогут избежать возможной путаницы, связанной с тем, что появятся элементы данных, внешние по отношению к этой фирме, с теми же названиями, но иначе структурированные.

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

<!ELEMENT ABC_Lightening:catalog (product)>

<!ELEMENT ABC_Lightening:product (name, description?, price+)>

<!ELEMENT ABC_Lightening:name (#PCDATA)>

<!ELEMENT ABC_Lightening:description (#PCDATA)>

<!ELEMENT ABC_Lightening:price (#PCDATA)>

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

WEB-РЕСУРСЫ XML

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

консорциум W3C (www.w3.org);

O'Reilly&Associates, Inc.'s XML.com (www.xml.com) — один из лучших сайтов в Сети, посвященных коммерческому применению XML;

XML Industry Portal, (www.xml.org);

xmlhack (www.xmlhack.com) — новости для web-разработчиков;

Enhydra (www.enhydra.org) — домашняя страница сервера Enhydra, посвященного приложениям Java/XML;

консорциум Unicode (www.unicode.org).

XML на стороне клиента

На стороне клиента XML позволяет достичь такого уровня соответствия конкретным условиям представления данных, которого очень трудно или невозможно достичь с использованием HTML. Например, для таких устройств, как PDA (Personal Digital Assistant — «карманный» компьютер, предназначенный для выполнения некоторых специальных функций) или мобильный телефон, требуется, чтобы страницы были отформатированы совсем не так, как для стандартных web-браузеров. Обычно, если даже имелась готовая страница, предназначенная для web-браузера, для подобных устройств приходилось полностью ее переделывать, то есть фактически создавать новую версию этой страницы. Однако благодаря структурированным данным документа XML, в котором содержательные данные отделены от форматирующих указаний, все, что вам надо сделать для приведения страницы в соответствие с каждым конкретным отображающем ее прибором, — это применить к имеющимся данным нужную таблицу стилей.

XML на стороне сервера

В наши дни XML оказывает очень большое влияние на организацию работы сервера. Один из способов применения XML на стороне сервера — передача сообщений (messaging), то есть обмен данными между приложениями или компьютерами. Чтобы приложения и компьютеры могли обмениваться информацией, для них должен быть определен единый формат сообщений. Представить себе то огромное влияние, которое XML может иметь в этой области, невозможно, не зная, хотя бы в общих чертах, истории передачи сообщений. Выбор стандарта для этого остается проблемой с тех времен, когда люди начали общаться между собой, но здесь я имею в виду только последние 30 лет.

Электронная коммерция, согласно определению европейского семинара, посвященного технической поддержке электронной коммерции (European Workshop on Open System's Technical Guide on Electronic Commerce, EWOS TGEC 066), включает в себя такие разнообразные области, как маркетинг, поддержка логистики, проведение деловых операций и взаимодействие с административными органами (например, обмен данными по налогам и таможенным отчислениям). Механизм EDI (Electronic Data Interchange), предназначенный для обмена данными в электронной форме, начинает свою историю с 1970-х годов, когда он был впервые предложен Комитетом по координации передачи данных (Transportation Data Coordinating Committee, TDCC). В таких отраслях деятельности, как финансовая, где сетевые технологии начали применяться уже более тридцати лет назад, EDI служил в качестве стандартного формата обмена сообщениями. Недостаток систем EDI заключается в том, что их установка и поддержка обходятся дорого и, кроме того, они часто требуют выделенных линий.

В 1980-х годах началось бурное распространение и внедрение в фирмах систем электронной почты для рабочих групп. По мере того как производители пытались утвердить свои варианты таких систем в качестве стандарта, все больше фирм переходило на использование в своем бизнесе электронной почты. Такие пакеты, как Microsoft Mail и Lotus cc:Mail, позволяли небольшим компаниям обмениваться электронными сообщениями в пределах своей внутренней сети, но при попытке увеличить ее охват обычно начинались проблемы, управление сетью становилось все более трудной задачей. Также оказалось сложным объединить с внешним миром локальную сеть (Local Area Network, LAN). Результат, как и всегда в отношении компьютерных технологий, заключался в том, что передача сообщений становилась все более децентрализованной. По мере того как передача электронных сообщений отходила от первоначальной централизованной, строго контролируемой системы, требующей выделенных линий связи, в эту технологию вовлекалось все больше пользователей. Децентрализация привела также к огромным проблемам в отношении совместимости различных форматов, к дублированию разработок в области электронной коммуникации и к невозможности организованного ее развития.

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

В первую очередь нужно было договориться о языке, и здесь XML оказался наиболее подходящим кандидатом. Основная причина, по которой XML прекрасно подходит для создания форматов передачи сообщений, — это его простота. XML подчиняется строго определенному стандарту, он не связан с какой-либо операционной системой или производителем, он совместим с большим количеством инструментальных средств и приложений, которые на протяжении многих лет разрабатывались для SGML. Требование строгого соответствия документов XML стандартам, установленным для правильно оформленных (well-formed) документов, гарантирует, что любой анализатор XML будет в состоянии прочесть и осмыслить любой документ XML. Кроме того, гораздо больше людей знакомы с языками разметки, чем с форматами сообщений, необходимыми для построения систем EDI. Благодаря XML формат сообщений может разработать любой, кто способен составить правильно оформленный документ XML.

Другой областью применения XML в web-документах является определение метасодержимого. Метасодержимое, или сведения о содержимом, позволяет сделать работу поисковых машин гораздо эффективнее. Например, пусть вам нужно найти сообщения о последних событиях в городе Остин (Austin) штата Техас. Тогда вы задаете поисковой машине следующие слова:

Остин Техас новости

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

City = Austin, State = ТХ, StoryType = News.

Близкие по назначению шаблоны

Вместе с универсальным элементом часто используется шаблон Role Attribute (атрибут role).

Доработка DTD

После внимательного изучения этого определения DTD его недостатки становятся очевидными, и мы начинаем понимать, что требуется внести ряд исправлений. Первый недостаток заключается в том, что у нас нет способа однозначно идентифицировать записку. Во-вторых, следовало бы более подробно указать, что может содержаться в элементах from и to. В-третьих, возможны ситуации, когда записки посылаются не от одного, а от нескольких лиц или нескольким лицам. Обдумав, какие виды записок реально могут пересылаться между служащими фирмы, мы переделали DTD (листинг 2.2 [Name — название, department — отдел, important part — наиболее существенная часть. — Примеч. перев. ]).

Листинг 2.2. Исправленное определение DTD для записок (memo.dtd)

<!ELEMENT memo (from, to, cc?, body)>

<!ATTLIST memo

id ID «REQUIRED

date CDATA «REQUIRED

subject CDATA #IMPLIED>

<!ELEMENT from (name.department)*>

<!ELEMENT to (name,department)*>

<!ELEMENT cc (name,department)*>

<!ELEMENT name (#PCDATA)>

<!ELEMENT department (#PCDATA)>

<!ELEMENT body (#PCDATA,important_part?)>

<!ELEMENT important_part (#PCDATA)>

Используя это определение DTD, любой сотрудник фирмы XMLGifts может точно ответить на вопрос, что такое служебная записка В листинге 2 3 показана правильно оформленная и допустимая служебная записка

Листинг 2.3. Правильно оформленная и допустимая служебная записка (memoexamplel.xml)

<?xml version="l.0" standalone="no"?>

<!DOCTYPE memo SYSTEM "memo.dtd">

<memo id = "cm0001"

date = "8/2/2000"

subject = "ваша задача на сегодня">

<from>

<name>Крис Минник</name>

</from>

<to>

<department>Bceм coтpyдникaм</department>

</to>

<body>

Поздравляю с окончанием проекта XMLGnfts.com

Предлагаю <important_part>сделать выходной и поехать на озеpo</important_part>

</body>

</memo>

Этот метод — изучение реального образца данных и последующее исправление DTD с учетом возможных потребностей в будущем — мы и будем использовать при создании каталога товаров для сайта XMLGifts.com

В листинге 2 4 приводится первый черновой вариант документа XML, описывающего несколько товаров из будущего каталога для сайта XMLGifts.com Этот документ написан без DTD Он является правильно оформленным документом XML, но, поскольку никакому определению DTD он не соответствует, его нельзя назвать допустимым и самодокументируемым [Caption — подпись (к рисунку) productlme — серия товаров — Примеч перев ].

Листинг 2.4. Первая черновая попытка описания товаров

<?xml version="1.0"?>

<catalog>

<product_line name="Books">

<product id="bk0022">

<name>Guide to Plants</name>

<description>Everything you've ever wanted to know about plants. </descnption>

<price>$12 99</price>

<quantity_in_stock>4</quantity_in_stock>

<image width="234" height="400"

src="images/covers/plants.gif ">

<caption>

This is the cover from the first edition

</caption>

</image>

<onsale_date>12/23/1999</onsale_date>

</product>

<product id="bk0035">

<name>Writing Fake Catalogs</name>

<description>Chns Hinnick's latest book explains, in agonizing detail, the process of thinking up fake products for a demonstration catalog </description>

<pnce>$59.95</pnce>

<quantity_in_stock>30</quantity_in_stock>

<onsale_date>09/01/2000</onsale_date>

</product>

</product_line>

<product__line name="CDs'>

<product id="cd0024">

<name>Just Singin' Along</name>

<description>A lovely collection of songs that the whole family can sing right along with </description>

<price>$10 00</price>

<quantity_in_stock>100</quantity_in_stock>

<onsale_date>2/23/2000</onsale_date>

</product>

<product id="cd0025">

<name>It' s Dot Com Enough for Me Songs from Silicon

Somewhere</name>

<description>A collection of the best folk music from

Internet companies.

</descnption>

<clip format="mp3" length="4.32" size="4.0 Mb"

src="track2.mp3">

<title>Track 2: My B2B Is B-R-0-K-E</title>

</clip>

<onsale_date>4/12/2000</onsale_date>

</product>

</product_line>

<product_line name="widgets">

<product id="wi0026">

<name>ElectroThermal Oxidizor</name>

<description>This amazing gizmo uses electricity to

produce heat that can be used for oxidization

purposes.</description>

<price>$24.95</price>

<quantity_in_stoek>10</quantity_in_stock>

<image width="200" height="200" src="/images/toaster.gif">

</image>

<onsale_date>6/2/2000</onsale_date>

</product>

<product id="wz0027">

<name>Percusive Interface Unit</name>

<description>Communicate with your favorite electric

calculating machine through tapping!</description>

<price>$109.99</price>

<quantity_in_stock>7</quantity_in_stock>

<onsale_date>6/23/200K/onsale_date>

</product>

</product_line>

</catalog>

Достоинства XML

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

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

Одним из результатов этой стратегии может оказаться то, что запросы и ожидания заказчика придется несколько урезать, но зато будут удовлетворены основные требования: разработка сайта уложится в отпущенные сроки и не потребует дополнительных расходов. Если вы навсегда запомните, что невозможно достичь всех трех целей сразу (быстрее, лучше, дешевле), и сумеете находить компромисс в любой ситуации, ваши проекты будут иметь высокие шансы на успех Если вы правильно построите web-приложение, то его расширение и дополнение в будущем не доставят проблем.

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

ПРИМЕЧАНИЕ

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

Некоторые причины такого выбора приведены ниже:

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

гибкость инструментальных средств;

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

поддержка Unicode.

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

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

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

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

До недавнего времени недостающим звеном между Java и XML был стандарт обмена данными между web-приложениями. Но появление протокола SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) восполнило этот недостаток. Пользуясь поддержкой таких гигантов компьютерной индустрии, как Microsoft и IBM, SOAP дает разработчикам прекрасные возможности для создания приложений.

Финальная версия

После того как мы внесли все указанные выше исправления в первую черновую версию, мы можем скомпоновать окончательную версию определения catalog.dtd и создать пример каталога catalog.xml. Он довольно сильно отличается от первой версии и (как мы надеемся) гораздо лучше соответствует нашим требованиям. Листинг 2.6 содержит последнюю версию нашего определения DTD.

Листинг 2.6. Исправленный файл catalog .dtd

<!ENTITY % running_text "(#PCDATA | bold |

italics | quote | link | general)*">

<!ENTITY % date_time "(day_of_week?, month?,

day_of_month?, year?,(hour, minute, seconds?)?)">

<!ELEMENT catalog (product_line*) >

<!ELEMENT product_line (product*)>

<!ATTLIST product_line name CDATA #IMPLIED>

<!ELEMENT product (name,author*,artist*,description, price,quantity_in_stock,image*, onsale_date?,clip*,shipping_info*)>

<!ATTLIST product id ID #REQUIRED>

<!ATTLIST product keywords CDATA #IMPLIED>

<!ELEMENT name (#PCDATA)>

<!ELEMENT author (name)>

<!ELEMENT artist (name)>

<!ELEMENT description (paragraph|general)* >

<!ELEMENT paragraph %running_text;>

<!ELEMENT bold (#PCDATA)>

<!ELEMENT italics (#PCDATA)>

<!ELEMENT quote (#PCDATA)>

<!ATTLIST quote attrib CDATA #IMPLIED>

<!ELEMENT link (#PCDATA)>

<!ATTLIST link href CDATA #REQUIRED alt CDATA #IMPLIED>

<!ELEMENT general (#PCDATA)>

<!ATTLIST general type CDATA #REQUIRED>

<!ELEMENT price (#PCDATA)>

<!ATTLIST price discount CDATA #IMPLIED>

<!ELEMENT quantity_in_stock (#PCDATA)>

<!ELEMENT image (caption?)>

<!ATTLIST image format (gif|png|jpg) #REQUIRED width CDATA #IMPLIED height CDATA #IMPLIED src CDATA #REQUIRED>

<!ELEMENT caption (paragraph)* >

<!ELEMENT onsale_date %date_time;>

<!ELEMENT day_of_week (#PCDATA)>

<!ELEMENT month (#PCDATA)>

<!ELEMENT day_of_month (#PCDATA)>

<!ELEMENT year (#PCDATA)>

<!ELEMENT hour (#PCDATA)>

<!ELEMENT minute (#PCDATA)>

<!ELEMENT seconds (#PCDATA)>

<!ELEMENT clip (title,description?)>

<!ATTLIST clip format (mp3|mpeg|mov|rm) #REQUIRED length CDATA #IMPLIED size CDATA #IMPLIED src CDATA #REQUIRED>

<!ELEMENT title (#PCDATA)>

В листинге 2.7 содержится правильно оформленный и допустимый документ XML, в котором используется DTD из файла catalog.dtd. Это только фрагмент исходного текста для полного каталога, который вы найдете на прилагаемом к данной книге компакт-диске.

Листинг 2.7. Пример каталога из файла catalog.xml

<?xml version="1.0" standalone="no"?>

<!DOCTYPE catalog SYSTEM "catalog.dtd">



<catalog>

<product_line name="Books">

<product id="bk0022" keywords="gardening, plants">

<name>Guide To Plants</name>

<description>

<paragraph> <italics>Everything</italics> you've ever wanted

to know about plants. </paragraph>

</description>

<price>$12.99</price>

<quantity_in_stock>4</quantity_in_stock>

<image format="gif" width="234" height="400"

src="images/covers/plantsv1.gif">

<caption>

<paragraph>This is the cover from the first

edition.</paragraph>

</caption>

</image>

<onsale_date>

<month>4</month>

<day_of_month>4</day_of_month>

<year>1999</year>

</onsale_date>

<shipping_info type="UPS" value="1.0" />

</product>

<product id="bk0023" keywords="gardening,

plants">

<name>Guide To Plants, Volume 2</name>

<description>

<paragraph>Everything else you've ever wanted

to know about plants.</paragraph>

</description>

<price>$12.99</price>

<quantity_in_stock>4</quantity_in_stock>

<image format="gif" width="234" height="400"

src="images/covers/plantsv2.gif">

<caption>

<paragraph> This is the cover from the first

edition.</paragraph>

</caption>

</image>

<onsale_date>

<month>4</month>

<day_of_month>8</day_of_month>

<year>2000</year>

</onsale_date>

<shipping_info type="UPS" value="1.0" />

</product> <product id="bk0024"

keywords="how-to, technology">

<name>The Genius's Guide to the 3rd Millenium</name>

<author>

<name>Christoph Minwich</name>

</author>

<description>

<paragraph>Learn to convert your replicator

into a transporter..and other neat tricks.</paragraph>

</description>

<price>$59.95</price>

<quantity_in_stock>0</quantity_in_stock>

<image format="gif" width="234" height="400"

src="images/covers/millenium.gif">

</image>

<onsale_date>

<month>1</month>

<day_of_month>1</day_of_month>

<year>2001</year>

</onsale_date>

<shipping_info type="UPS" value="2.0" />

</product>

<product id="bk0025" keywords="how-to, art">

<name>Dryer Lint Art</name>

<description>

<paragraph>A new book about the new folk art

that's catching on like wildfire.</paragraph>

</description>

<price>$5.95</price>

<quantity_in_stock>34</quantity_in_stock>

<image format="gif" width="200" height="200"

src="images/covers/dryerart.gif">

</image>

<onsale_date>

<month>11</month>

<day_of_month>3</day_of_month>

<year>1971</year>

</onsale_date>

<shipping_info type="UPS" value="1.5" />

</product>

</product_line>





</product_line>

<product_line name="CDs">

<product id="cd0023" keywords="music,easy

listening,pets,dogs">

<name>Music for Dogs</name>

<description>

<paragraph> Keep your pets calm while you're

away from the house! Each of the 15 tracks

on this CD has been scientifically shown to

relax pets of all kinds.</paragraph>

</description>

<price>$14.99</price>

<quantity_in_stock>50</quantity_in_stock>

<image format="gif" width="200" height="200"

src="http://www.musicfordogs.com/images/cover.gif"> </image>

<onsale_date>

<month>3</month>

<day_of_month>2</day_of_month>

<year>1990</year>

</onsale_date>

<clip format="mp3" length="2:12" size="1.6 Mb" src="http://www.musicfordogs.com/sounds/track1.mp3">

<title>Track 1: Fetching the Stick</title>

<description>

<paragraph>An exciting and playful melody.</paragraph>

</description>

</clip>

<shipping_info type="UPS" value="0.5" />

</product>

<product id="cd0024" keywords="music,easy listening">

<name>Just Singin' Along</name>

<description>

<paragraph>A lovely collection of songs that the whole family can sing right along with.</paragraph>

</description>

<price>$10.00</price>

<quantity_in_stock>100</quantity_in_stock>

<onsale_date>

<month>2</month>

<day_of_month>23</day_of_month>

<year>2000</year>

</onsale_date>

<shipping_info type="UPS" value="0.5" />

</product>

<product id="cd0025" keywords="music,folk">

<name>It' s Dot Com Enough For Me: Songs From Silicon Somewhere</name>

<description>

<paragraph>A collection of the best folk music from Internet companies.</paragraph>

</description>

<price>$12.99</price>

<quantity_in_stock>4</quantity_in_stock>

<onsale_date>

<month>4</month>

<day_of_month>12</day_of_month>

<year>2000</year>

</onsale_date>

<clip format="mp3" length="4.32" size="4.0 Mb" src="track2.mp3">

<title>Track 2: My B2B is B-R-O-K-E</title>

</clip>

<shipping_info type="UPS" value="0.5" />

</product>

</product_line>





<product_line name="widgets">

<product id="wg0026" keywords="appliance,electronics">

<name>ElectroThermal Oxidizer</name>

<description>

<paragraph>This amazing gizmo uses electricity to produce heat that can be used for oxidization purposes.</paragraph>

</description>

<price>$24.95</price>

<quantity_in_stock>10</quantity_in_stock>

<image format="jpg" width="208" height="178" src="/images/toaster.jpg"> </image>

<onsale_date>

<month>6</month>

<day_of_month>2</day_of_month>

<year>2000</year>

</onsale_date>

<shipping_info type="UPS" value="12.0" />

</product>

<product id="wg0027" keywords="computing,

electronics, input device">

<name>Percusive Interface Unit</name>

<description>

<paragraph>Communicate with your favorite

electric calculating machine--through

tapping!</paragraph>

</description>

<price>$109.99</price>

<quantity_in_stock>7</quantity_in_stock>

<onsale_date>

<month>6</month>

<day_of_month>23</day_of_month>

<year>2001</year>

</onsale_date>

<shipping_info type="UPS" value="12.0" />

</product>

<product id="wg0028" keywords="outdoors">

<name>Umbrella</name>

<description>

<paragraph> Imagine going out into the rain and NOT getting wet! The amazing umbrella makes it possible.</paragraph>

</description>

<price>$10.99</price>

<quantity_in_stock>7</quantity_in_stock>

<onsale_date>

<month>7</month>

<day_of_month>2</day_of_month>

<year>2000</year>

</onsale_date>

<shipping_info type="UPS" value="10.0" />

</product>





</catalog>

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

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

Для выполнения этой задачи существуют различные промежуточные приложения. Наиболее совершенные серверы XML обеспечивают такие возможности, как кэширование, репликация и балансировка нагрузки. Серверы XML обычно представляют собой приложения, написанные на Java и способные воспринять любые данные, для которых у вас имеется драйвер JDBC (Java Database Connectivity — средство доступа Java-приложений к базам данных).

И XML, и Java являются переносимыми стандартами (portable standards). Это означает, что они не зависят от платформы, на которой будет работать приложение. Если приложение написано на Java, то для его работы годится любая виртуальная машина Java. Приложение, которое использует данные XML, может легко взаимодействовать с любым типом источников данных. Если вам потребуется изменить источник данных приложения XML, вносить изменения в само приложение не потребуется.

Из первой главы вы узнали,

Каталог товаров на ХМL
Из первой главы вы узнали, что представляет собой XML и как с помощью XML создаются языки разметки. Теперь вы располагаете инструментальными средствами для создания документов XML и определений типов документов (DTD). Но иметь инструменты — это далеко не то же самое, что уметь их использовать. Как вы знаете, изучение любого языка невозможно без опыта его практического применения.
Для того чтобы вы получили представление о том, как происходят создание документа XML и определение типа документа, какие вопросы при этом должен решить программист, в данной главе мы продемонстрируем вам весь процесс создания XML-каталога товаров для гипотетической компании, занимающейся электронной коммерцией. Рассматривается большая часть аспектов этого процесса, в том числе вопросы сбора данных, разработки DTD и фактического программирования каталога.

Избегайте субтрактивного уточнения

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

Самым известным примером таких дополнений HTML является элемент font (шрифт). Когда этот элемент был введен, не существовало никакого жизнеспособного альтернативного способа указать, как именно должен форматироваться текст. В настоящее время имеются каскадные таблицы стилей (Cascading Style Sheets, CSS) и, более того, расширяемый язык таблиц стилей (Extensible Stylesheet Language, XSL), которые предназначены как раз для работы с форматом представления документов. Но до сих пор многие (если не большинство) web-дизайнеры используют элемент font для форматирования текста. Причина в том, что web-дизайнеры хорошо знакомы с этим элементом и знают в точности его действие на текст документа. Каскадные таблицы стилей являются гораздо более гибким, но и более сложным инструментом; кроме того, реализация CSS в каждом из браузеров сопровождается различными сбоями и неполадками, пока что недостаточно хорошо изученными.

Последние несколько лет Консорциум W3C пытается исключить элемент font из HTML. Но так как этот элемент присутствует в очень многих web-страницах и очень многие web-дизайнеры весьма активно его используют, видимо, пройдет еще немало времени, прежде чем элемент font прекратит свое существование. Было бы замечательно, если бы всегда удавалось избегать субтрактивного уточнения, но реально это не всегда получается. Тем не менее можно постараться минимизировать количество элементов, которые впоследствии, возможно, придется удалять из документа.

Первый шаг, который следует предпринять, если вы хотите минимизировать потребность в субтрактивном уточнении, — это осознание причин, по которым такое уточнение вообще становится необходимым. Основной причиной удаления объявлений из DTD является то, что эти объявления задают типы данных или правила, не соответствующие или вступающие в противоречие с теми реалиями данной сферы деятельности, которые призваны отображать. Например, представьте себе, что у вас имеется DTD для разметки документов, описывающих счета за предоставленные услуги. Допустим, в вашей фирме оплата производится по фиксированной шкале, за каждый вид работ назначена определенная сумма. Но определение DTD могло сохраниться с тех времен, когда присутствовала и другая форма оплаты — почасовая. Соответствующие объявления могли бы выглядеть следующим образом [Invoice — счет, service — вид работ, duration — затраченное время, rate — оплата за час работы, fee — стоимость работ, totaldue — общая сумма к оплате. — Примеч. перев. ]:

<!ELEMENT invoice (service*,total_due)>

<!ELEMENT service (description,(duration,rate)?,fee?)>

<!ELEMENT description (#PCDATA)>

<!ELEMENT duration (hours.minutes)>

<!ELEMENT rate (#PCDATA)>

<!ELEMENT fee (#PCDATA)>

<!ELEMENT total_due(#PCDATA)>

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

<!-первый способ записи-->

<invoice> <service>

<description>Установка бензинового нacoca</description>

<duration>

<hours>3</hours>

<minutes>0</minutes>

</duration>

<rate>$100</rate>

<fee>$300</fee>

</service>

</invoice>

<!-второй способ записи-->

<invoice>

<service>

<description>Установка бензинового нacoca</description>

<fee>$300</fee>

</service>

</invoice>

Согласно существующему определению DTD, оба эти способа корректны, но только второй отражает реальную ситуацию. Чтобы исключить возможность некорректного использования этого определения, следует удалить элементы rate и duration, как это сделано во втором способе записи.

Известные примеры применения

Элементы div и span в XHTML являются распространенными примерами применения данного шаблона.

Элемент shipping

Наконец, нам нужен элемент, описывающий требования по доставке товаров покупателю. Хотя исходно каталог был рассчитан на товары, которые доставляются покупателю посылкой, но на случай расширения каталога нужно предусмотреть и другие возможности, например пересылку определенных видов товаров по электронной почте или пересылку каких-то особых товаров, для которых имеются специфические требования [Shipping info — информация о доставке — Примеч перев. ].

<!ELEMENT shipping_info >

<!ATTLIST shipping_info

type CDATA #REQUIRED>

<!ATTLIST shnpping_infо

value CDATA #IMPLIED>

Вместо того чтобы указывать какую-то одну характеристику отправляемого товара (например, вес), мы выбрали более общий термин — величина (атрибут value). Этот атрибут можно легко приспособить к любому типу товаров и способу их доставки; например, если мы будем продавать электронные версии книг, загружаемые через Интернет, то данный атрибут будет идентифицировать размер книги в мегабайтах.

Элементы catalog, productline и product

В первой строке содержится объявление корневого элемента catalog:

<!ELEMENT catalog (product_line)*>

Это объявление достаточно очевидное: в нем указывается, что catalog может состоять из любого количества элементов productJ i ne.

Элемент product_line тоже очень просто устроен, но в отличие от элемента catal og у него имеется атрибут name:

<!ELEMENT product_line (product)* >

<!ATTLIST product_line

name CDATA #IMPLIED>

В объявлении атрибута name элемента productjine указано, что этот атрибут не является обязательным (#IMPLIED). Но информация о принадлежности товара (элемент product) к некоторой серии товаров (элементу productjine) не имеет смысла, если мы не знаем названия этой серии. Поэтому соответствующий атрибут, name, мы сделаем обязательным. Внести это изменение несложно:

<!ATTLIST productjline

name CDATA #REQUIRED>

Следующее объявление — наиболее содержательная часть этого определения DTD [Photo — фотография, clip — клип. — Примеч. перев. ]:

<!ELEMENT product(name|description|price|

quantity_in_stock|photo| onsale_date|clip)* >

В таком виде это объявление подразумевает, что элемент product может содержать любое (в том числе нулевое) количество любых перечисленных здесь элементов. Это не соответствует фактической организации каталога на сайте XMLGifts.com. Также здесь не учитываются сведения об авторах книг (для элементов Books) и исполнителях (для элементов CDs). Такие промашки часто случаются, если используется недостаточно большой фрагмент исходных данных, для которых вы составляете DTD. Полностью исправленное объявление элемента product выглядит следующим образом:

<!ELEMENT product name,author* , artist*,

description,price,quantity_in_stock,image*,

onsale_date?,clip*>

ПРИМЕЧАНИЕ

Обратите внимание, что в исправленной версии объявления элемента product указано, что элементы name, description, quantity_m_stock могут встречаться в одном элементе product только один раз. Заметим также, что они обязательно должны присутствовать в этом элементе. Далее обратите внимание, что элемент photo (фотография) был переименован в image (изображение) для большей общности.

Хотя получившееся определение DTD не идеально и, возможно, не учитывает все особенности каждого товара, все же это неплохое «первое приближение». Поскольку оно было сконструировано для конкретного типа документа, а не как DTD общего назначения, мы можем позволить себе пересматривать DTD по мере изменения каталога. Всегда предпочтительнее (и проще) начинать с более обобщенного определения DTD и добавлять к нему новые элементы по мере надобности. Этот метод называется аддитивным уточнением (additive refinement). Противоположный метод уточнения DTD, который сводится к удалению лишних объявлений элементов, называется субтрактивным уточнением (subtractive refinement).

После определения элемента product в DTD определяется атрибут id этого элемента:

<!ATTLIST product

id CDATA #IMPLIED>

Как и с атрибутом name элемента product_line, в каталоге у каждого товара должен быть однозначный идентификатор, поэтому следует сделать этот атрибут обязательным. Кроме того, чтобы гарантировать уникальность значения каждого атрибута id, то есть идентификатора каждого товара, тип атрибута должен быть ID. Исправленное объявление атрибута id выглядит следующим образом:

<!ATTLIST product

id ID #REQUIRED>

Кроме определения товара по его уникальному идентификатору также мы хотели бы иметь возможность отыскать этот товар по ключевым словам. Для этого мы добавим в элемент product еще один атрибут, keywords [Keyword — ключевое слово (характеризующее товар) — Примеч перев.]:

<!ATTLIST product

keywords CDATA #IMPLIED>

В нашем представлении значение атрибута keywords — это список с разделенными запятыми элементами, который можно использовать для поиска и группировки.

Элементы description, paragraph и general

Следующая часть DTD определяет элементы, дочерние по отношению к product. Дочерний элемент name в настоящий момент может содержать любую разновидность проверенных символьных данных, что вполне соответствует нашим требованиям. Элемент description, определенный таким же образом, содержит информацию, исходно предназначенную для прочтения людьми, но также в нем могут содержаться некоторые данные, которые мы хотели бы сделать доступными для программ, то есть которые можно было бы извлекать автоматически.

Чтобы сделать содержимое элемента description удобным для восприятия и для применения к нему в дальнейшем различных стилей, нужно предусмотреть возможность разделения элемента description на части, которые будут содержать элементы для отображения текста жирным шрифтом, курсивом и т. д. Для этого в первую очередь нужно, чтобы элемент description мог содержать элементы paragraph, и определить paragraph, как это сделано ниже [Paragraph — абзац (имеется в виду просто некая часть текста), bold — полужирный (шрифт), italics — курсив, quote — цитата, link — ссылка — Примеч перев ]:

<!ELEMENT description (paragraph*)>

<!ELEMENT paragraph (#PCDATA | bold |

italics|quote|link)*>

<!ELEMENT bold #PCDATA>

<!ELEMENT italics #PCDATA>

<! ELEMENT quote #PCDATA>

<!ATTLIST quote

attrib CDATA #IMPLIED>

<!ELEMENT link (#PCDATA)>

<!ATTLIST link

href CDATA «REQUIRED

alt CDATA #IMPLIED>

Существует большая вероятность того, что такой же список элементов разметки, который используется в элементе paragraph, потребуется в каком-то другом месте DTD (например, в элементе title или footnote, то есть в заголовке или в сноске). Чтобы упростить процесс создания DTD, мы ввели параметрическую сущность, представляющую собой список элементов разметки текста:

<!ENTITY %runmng_text "(#PCDATA | bold |

italics | quote | link)* ">

СОВЕТ

Напомним, что сущность — просто подстановочный текст, который пишется вместо заменяемого им значения, и что общие и параметрические сущности должны быть объявлены прежде, чем будут использованы. Поскольку параметрические сущности могут существовать только в DTD, то обычно их объявления сгруппированы в начале DTD. В нашем случае это тем более удобно, что при необходимости добавления какого-либо элемента разметки в элемент paragraph эту сущность будет легко найти.

Когда объявление параметрической сущности добавлено в начало DTD, объявление элемента paragraph можно переписать следующим образом:

<!ELEMENET paragraph %running_text;>

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

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

<description>

<paragraph>Эта яркая новая группа из Бельгии,

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

Iggy Pop и Spice Girls,стремительно завоевывает

популярность во всем мире.</paragraph>

</description>

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

Хорошим способом обойти эту проблему является использование элемента general с атрибутом type. Идентифицирующую информацию можно сделать значением этого атрибута, что дает максимальную гибкость автору документа и тому, кто конструирует разметку элемента description, как видно из приведенного ниже листинга:

<!ELEMENT general #PCDATA>

<!ATTLIST general

type CDATA #REQUIRED>

Используя элементы general и paragraph, мы можем теперь разметить описание (то есть элемент description) в нашем примере таким образом, чтобы информацию из него могли извлечь и человек, и программа:

<description>

<paragraph>Эта яркая новая группа из

<general type="country">Бельгии</general>,

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

<general type="artist">Iggy Pop</general>и

<general type = "artist">Spice Girl</general>

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

мире.</paragraph>

</description>

Теперь приложение легко справится с задачей преобразования элементов general в пары имя-значение.

В результате объявление элемента description и его дочерних элементов будет выглядеть следующим образом:

<!ELEMENT description (paragraph|general)* >

<!ELEMENT paragraph %running_text;>

<!ELEMENT bold #PCDATA>

<!ELEMENT italics #PCDATA>

<!ELEMENT quote #PCDATA>

<!ATTLIST quote

attrib CDATA #IMPLIED>

<!ELEMENT link (#PCDATA)>

<!ATTLIST link

href CDATA #REQUIRED

alt CDATA #IMPLIED>

<!ELEMENT general #PCDATA>

<!ATTLIST general

type CDATA #REQUIRED>

Элементы или атрибуты?

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

первый способ:

<Book>

<Titlе>Справочник по растениям</Тitle>

</Book>

второй способ:

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

Существует, однако, несколько правил, которые были выработаны уважаемыми авторами, долгое время пишущими на XML и SGML. Этими правилами можно руководствоваться в вопросе о том, как следует оформить конкретный фрагмент данных — в виде элемента или в виде атрибута. Чтобы пользоваться этими правилами, нужен некоторый опыт. Также следует помнить, что из любых правил существуют исключения.

Атрибуты следует использовать для записи информации о содержимом (метаданные), в то время как элементы следует использовать для записи фактической информации. Например, цвет обложки книги может быть отнесен к метаданным и записан как атрибут. Абзац из этой книги следует рассматривать как фактическое содержимое.

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

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

Если важен порядок следования значений, используйте элементы. (Причина заключается в том, что невозможно задать порядок следования атрибутов, но порядок следования элементов можно смоделировать нужным образом.)

Элементы onsale_date, time, clip и title

Следующий объявленный в DTD элемент — onsa!e_date. Исходным назначением этого элемента было обеспечение возможности внесения товаров в каталог заранее, еще до фактического начала их продажи В будущем возможно и другое применение этого элемента. Например, мы можем предоставить пользователю возможность просматривать новые товары или учитывать значение этого элемента (дату начала продаж) при составлении отчетов для внутреннего использования

Как отмечалось в главе 1, не существует способа указать в DTD, что значением некоего элемента должна быть дата Тем не менее можно создать несколько дочерних элементов onsale_date, чтобы более точно указать, данные какого типа ожидаются, а также чтобы формат этих данных был достаточно гибким и мог включать, например, день недели, число месяца или даже часы, минуты и секунды [Day of week — день недели, month — месяц, day of month — день месяца year — год, hour — час, minute — минута, seconds — секунды — Примеч перев]

<!ELEMENT onsale_date

(day_of_week?.month?,day_of_month?,year?,

(hour,minute, seconds?)?)>

<!ELEMENT day_of_week (#PCDATA)>

<!ELEMENT month (#PCDATA)>

<!ELEMENT day_of_month (#PCDATA)>

<!ELEMENT year (#PCDATA)>

<!ELEMENT hour (#PCDATA)>

<!ELEMENT minute (#PCDATA)>

<!ELEMENT seconds (#PCDATA)>

Здесь уже структура элемента становится несколько сложнее. Фактически в приведенном объявлении говорится, что каждый из дочерних элементов onsale_date может присутствовать один раз или отсутствовать Элемент time не является обязательным, но, если он присутствует, то и часы, и минуты (элементы hour и minute) должны быть указаны. Здесь мы можем несколько усовершенствовать DTD, введя параметрическую сущность date_time [Date — дата, time — время — Примеч перев ], которую можно будет повторно использовать в других элементах для указания даты и времени:

<!ENTITY % date_time"(day_of_week?,month?,

day_of_month?,year?,(hour.minute, seconds?)?)">

<!ELEMENT onsale_date %date_time;>

Чтобы включить в наше приложение отрывки из музыкальных записей, дающие покупателю представление о том или ином компакт-диске, в документе XML и в соответствующем определении DTD используется элемент clip (то есть музыкальный клип). Этот элемент функционирует так же, как элемент image, — он содержит ссылку на файлы мультимедиа, которые хранятся отдельно в базе данных XlL [Size — размер, format — формат — Примеч перев ]:

<!ELEMENT clip (title)* >

<!ATTLIST clip

format CDATA #IMPLIED>

<!ATTLIST clip

length CDATA #IMPLIED>

<!ATTLIST clip

size CDATA #IMPLIED>

<!ATTLIST clip

src CDATA #IMPLIED>

<!ELEMENT title (#PCDATA)* >

Возможно, вы обратили внимание на то, что название (title) определено как дочерний элемент, в то время как format, length, size и src определены как атрибуты. Хотя и title можно было бы определить как атрибут, но основная причина, по которой мы не сделали этого, заключается в том, что атрибуты format, length, size и src в первую очередь предназначены для приложения, в то время как title — для людей. Также учитывались соображения логической согласованности: в элементе image подпись (caption) также была определена как дочерний элемент.

Как и в предыдущих объявлениях элементов этого определения DTD, можно внести несколько изменений в элемент clip и его атрибуты и дочерние элементы, чтобы добиться более точного соответствия с реальным документом XML. В первую очередь следует изменить правило для самого элемента clip. Хотя вполне возможно, что для одного товара может быть несколько клипов (элементов clip), но трудно представить ситуацию, в которой для одного клипа потребуется несколько названий (то есть несколько элементов title для одного элемента clip). Мы можем переписать объявление для clip заново, чтобы учесть это соображение:

<!ELEMENT clip (title)>

Также может возникнуть ситуация, когда для какого-то клипа потребуются пояснения. Для этого в элемент clip можно включить элемент description, содержащий описание данного клипа:

<!ELEMENT clip (title, description?)>

Как и в случае с атрибутом format элемента image, значение атрибута format элемента clip должно быть ограничено несколькими возможными форматами мультимедиа:

<!ATTLIST clip format (mp3|mpeg|mov|rm) #REQUIRED>

Атрибут scr элемента clip также должен быть объявлен как обязательный атрибут. Что касается атрибутов scr и length, их можно оставить почти в том же виде, в котором они определены на данный момент. Мы думаем, что нам поначалу не придется слишком много работать с этими атрибутами; мы просто укажем их значения рядом со ссылкой на файл мультимедиа. На самом деле мы все равно можем сделать лишь немногое в отношении задания единиц или ограничений для этих полей. За проверку правильности этих атрибутов отвечает само приложение.

Элементы price, quantity_in_stock и image

Следующий элемент, объявленный в DTD, — элемент price. Было бы замечательно, если бы сведения о ценах действительно имели такой простой формат, как указано в DTD:

<!ELEMENT price(#PCDATA)*>

Но реально ситуация с ценами сложнее и цена товара не выражается какой- то одной фиксированной суммой. В реальном мире для различных товаров могут быть предусмотрены различные скидки, а иногда на какие-то товары или группы товаров объявляется распродажа. Чтобы учесть скидки, в элемент price следует добавить атрибут с именем di scount:

<!ELEMENT price #PCDATA>

<!ATTLIST price

discount CDATA #IMPLIED>

База данных каталога не занимается определением того, как именно тот или иной клиент получает скидку (как член определенной привилегированной группы клиентов или по распродаже). Эти факторы контролируются приложением и базой данных о клиентах. База данных о клиентах содержит информацию как раз о том, какие клиенты или группы клиентов имеют право на скидки.

Все, что должно содержаться в элементе price, — это сведения о стоимости данного товара. Поскольку в стандартном определении DTD отсутствует возможность указать тип данных элемента, то за соответствие реальным ценам тех данных, которые содержатся в элементе price, отвечает приложение.

Следующий элемент DTD, quantity_in_stock, не требует больших изменений:

<!ELEMENT quantity_in_stock (#PCDATA>*>

Если убрать излишний символ оператора повторяемости (*), то элемент получится как раз таким, как надо:

<!ELEMENT quantity_in_stock (#PCDATA)>

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

<!ELEMENT image (caption)>

width CDATA #IMPLIED>

<!ATTLIST image height CDATA #IMPLIED>

<!ATTLIST image

src CDATA #IMPLIED>

<!ELEMENT caption (#PCDATA)*>

Некоторые товары из каталога XMLGifts.com не сопровождаются изображениями В тех случаях, когда изображение товара отсутствует, во многих электронных магазинах появляется определенная картинка, которая извещает посетителей магазина о невозможности предоставить изображение товара Эту замену можно было бы описать в DTD, введя некоторое значение атрибута scr, используемое по умолчанию (то есть когда не указано никакого другого значения) Но, рассмотрев эту возможность, компания XMLGifts решила просто внести соответствующие дополнения в само приложение, а не в DTD Причиной этого является то, что указанная картинка, используемая по умолчанию, на самом деле не содержит никаких сведений о товаре. Она требуется только для того, чтобы при отсутствии изображения товара не пришлось изменять единый для всех товаров дизайн страницы. Поскольку эта картинка связана скорее с представлением данных, чем с описанием товаров, ее не следует включать в DTD.

Хотя наличие изображений не является обязательным требованием для всех товаров, если элемент image все же присутствует, у него обязательно должен быть атрибут scr (источник) и необязательно — caption (подпись).

<!ELEMENT image (caption?)>

<!ATTLIST image

width CDATA #IMPLIED>

<!ATTLIST image

height CDATA #IMPLIED>

<!ATTLIST image

src CDATA #REQUIRED>

<!ELEMENT caption (#PCDATA)>

Существует еще одна деталь, которую необходимо уточнить при описании элемента image. Это способ указания формата изображения Чтобы гарантировать, что форматы изображения товаров окажутся приемлемыми для большинства web-браузеров, мы ограничим количество возможных форматов тремя — GIF, PNG и JPG Ограничения на формат можно записать с помощью следующего нового атрибута

<!ATTLIST image

format (gif|png|jpg) #REQUIRED>

Теперь у элемента image имеется один дочерний элемент (caption) и четыре атрибута, из которых два (scr и format) являются обязательными.

Заголовок изображения может содержать только символьные данные Здесь появляется прекрасная возможность — снова использовать элемент paragraph, который мы создали для элемента description

<!ELEMENT caption (paragraph*)>

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

<!ELEMENT image (caption?)>

<!ATTLIST image format (gif|png|jpg) #REQUIRED

width CDATA #IMPLIED

height CDATA #IMPLIED

src CDATA #REQUIRED>

<!ELEMENT caption (paragraph*) >

Каталог товаров и DTD

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

В начале работы над проектом каталог данных сайта XMLGifts.com хранился в виде электронной таблицы. Часть этой таблицы показана в табл. 2.1.

Наш опыт показывает, что такой способ хранения данных характерен для многих физических (в отличие от виртуальных) магазинов, которые только начинают разрабатывать web-сайты. Реальная таблица может иметь гораздо больше столбцов, чем показано в нашем примере, но общий принцип заключается в том, что для каждого товара в таблице отводится отдельная строка, а для каждой возможной характеристики товара имеется отдельный столбец. Подобный тип организации каталога (все данные в одной таблице) обычно является результатом того, что количество видов товаров, с которыми имеет дело данная фирма, растет быстрее, чем техническая квалификация сотрудников. Излишне говорить, что эта ситуация требует кардинального пересмотра. Следующим этапом является выбор оптимального способа организации данных.

Таблица 2.1. Образец каталога XMLGifts.com

Шифр

Название товара

Описание

Категория

Цена

Количество на складе

Автор

bk0022

Справочник по растениям

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

Книги

$12.99

Вильям Смит

cd0024

Просто подпевай

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

Компакт- диски

$10.00

100

WZ0027

Ударный интерфейс

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

Приборы и устройства

$109.99

Контекст

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

Краткое описание

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

Написание DTD

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

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

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

Чаще, однако, при создании DTD используется комбинация этих двух методов. Если, к примеру, нам требуется создать DTD для служебных записок, можно начать с типичной записки и разметить ее как документ XML [Memo — служебная записка, from — от кого, to — кому. — Примеч. перев. ]:

<memo>

<from>Крис Минник</from>

<to>Сотрудникам</to>

<body>Сегодня выходной. Поезжайте на озеро отдыхать</body>

</memo>

Для этого простого документа DTD может выглядеть следующим образом:

<!ELEMENT memo (from,to,body)>

<!ELEMENT from (#PCDATA)>

<!ELEMENT to (#PCDATA)>

<!ELEMENT body (#PCDATA)>

Назначение web-сайта

Наша гипотетическая компания Xtreme Mega-Large Gifts (XMLGifts) занимается продажей редких музыкальных записей, книг и других предметов. Рынок сбыта очень ограничен, так как магазин расположен в маленьком городе. Однако владельцы компании уверены, что их товары будут пользоваться спросом, если потенциальные покупатели получат информацию об этих товарах. Поэтому компания решила создать свой web-сайт XMLGifts.com.

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

Обсуждение

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

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

Ограничения

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

Фундаментальное правило коммерции «быстрее, лучше, дешевле» в данном случае не работает. Многим разработчикам и консультантам понимание этого факта дается нелегко. Если заказчик упорно настаивает на том, чтобы разработка его проекта удовлетворяла всем трем требованиям, — это часто означает, что проект заранее обречен на неудачу или же консультанту придется делать больше за меньшие деньги Чтобы максимально увеличить шансы на успех предприятия, следует предложить заказчику выбор из трех возможностей, о которых мы рассказываем в следующих трех разделах*

Организация данных

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

Если бы в нашем примере для создания каталога электронного магазина использовалась реляционная база данных, первым шагом по улучшению организации было бы создание отдельной таблицы для каждого вида товаров. Это помогло бы избежать очевидных потерь, связанных с тем, что в единой таблице приходится отводить целый столбец, в котором, возможно, будет заполнена только одна ячейка (например, если в столбце указывается автор книги, для всех остальных видов товаров, помимо книг, этот столбец будет пустым). Далее, если для какой-то книги указывается не автор, а редактор, то ради одной такой книги придется добавлять целый столбец. Если у какой-либо другой книги два (или более) автора, то снова придется либо создавать очередной столбец, либо создать отдельную таблицу для авторов.

На рис. 2.1 показан один из способов организации взаимоотношений между таблицами.

Рис. 2.1. Схема отношений между таблицами

На рис. 2.2 показан более подробно фрагмент приведенной выше схемы, в которую добавлены некоторые поля из таблицы Авторы.

Рис. 2.2. Отношения между таблицами и полями

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

Рис. 2.3. Отношения между таблицами, полями и данными

Что напоминают три приведенные схемы? Эти схемы фактически показывают фрагмент реляционной базы данных в виде иерархической структуры. Иерархические структуры данных (hierarchical data structures), подобные тем, что создаются с помощью XML, очень удобны для организации данных, поскольку в них имеется единая «точка отсчета». Например, в схеме, приведенной на рис. 2.3, такой точкой отсчета для всей структуры является Серия товаров «книги». В документе XML такая точка отсчета, относительно которой строится вся организация данных, называется корневым элементом (root element). Напомним, что в любом документе XML должен присутствовать корневой элемент.

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

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

<Products>

<Book>

<Тitle>Справочник по растениям</Title>

<Descnption> Bce, что вы когда-либо хотели узнать о растениях </Descnption>

<Рrice>$12 99</price>

<Author>

<Name>Вильям Смит</Name>

<Biography> Мистер Смит родился в Западной Филадельфии, а в настоящее время проживает в Бел Эйр, Калифорния. </Biography>

</Author>

</Book>

</Products>

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

Преобразование реляционной базы данных в документ XML не обязательно делать вручную. Для этой цели существует множество инструментальных средств, так же как и для решения обратной задачи (преобразование документа XML в таблицу).

Также этот процесс можно автоматизировать с помощью запросов SQL. Основной метод преобразования табличных данных в иерархическую структуру заключается в использовании внешнего соединения SQL. Внешнее соединение (outer join) объединяет две таблицы в одну, причем полностью сохраняются данные лишь одной из них. Структура получившейся в результате таблицы повторяет структуру одной из исходных. Предположим, например, что у нас имеются две таблицы, Books и Authors. Для создания иерархической структуры этих реляционных данных можно использовать что-либо подобное следующей инструкции SQL:

SELECT *

FROM Books LEFT JOIN Authors ON [Authors] [Book_ID]=[Books].[ID];

Эта инструкция SQL объединяет таблицы Books и Authors, сохраняя все строки из таблицы Books, даже если в таблице Authors нет соответствующей записи. Поскольку в таком случае главной таблицей является Books, то те строки таблицы Authors, которые не ассоциированы с какой-либо записью из таблицы Books, выбраны не будут. В получившейся таблице данные будут показаны с точки зрения Books (табл. 2.2).

Таблица 2.2. Представление Books

Название книги	Имя автора
По ком звонит колокол Электронный магазин на Java и XML Преступление и наказание	Эрнест Хемингуэй Вильям Брогден, Крис Минник Федор Достоевский

Чтобы преобразовать эту таблицу в данные XML, каждый столбец нужно сделать дочерним элементом по отношению к элементу Book, как показано в листинге 2.1 [Book — книга, title — название, author — автор. — Примеч. перев. ].

Листинг 2.1. Документ XML, получившийся в результате преобразования реляционной базы данных (BookView.xml) [Все представленные в книге тексты программ можно найти на сайте .издательства по адресу www.piter.com, — Примеч. ред. ]

<BookView>

<Book>

<Title>По ком звонит колокол</Title>

<Author>

<Name>Эрнест Хемингуэй</Nаmе>

</Author>

</Book>

<Book>

<Title>Электронный магазин на Java и XML</Title>

<Author>

<Name>Вильям Брогден</Name>

</Author>

<Author>

<Name>Крис Mинник</Name>

</Author>

</Book>

<Book>

<Title>Преступление и наказание</Title>

<Author>

<Name>Федор Достоевский</Name>

</Author>

</Book>

</BookView>

Поддержка Unicode

Допустим, что компания XMLGifts решила, помимо всего прочего, распечатать свой каталог на нескольких языках. Встроенная в Java и XML поддержка символов Unicode упрощает эту задачу.

Поскольку web-разработчики все больше и больше стремятся к тому, чтобы пользовательский интерфейс и содержимое web-страниц не были ограничены в языковом отношении, поддержка Unicode становится все более важной характеристикой любой Интернет-технологии. Поддержка Unicode была добавлена и в другие популярные языки web-программирования, такие как Perl и Tel. Однако в отличие от них язык Java был исходно рассчитан на поддержку Unicode, поэтому обработка символов различных алфавитов нисколько не усложняет структуру приложения, как это может произойти на других платформах.

Покупка готового пакета — это быстрее и дешевле

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

Если вы планируете разместить на своем сайте достаточно стандартный электронный магазин и вам нужно как можно скорее запустить его в работу, то, вероятно, вам подходит такой вариант В этом случае вам следует внимательно отнестись к своему выбору — вы должны убедиться, что выбранный вами пакет действительно будет работать так, как нужно

Такой метод можно назвать быстрее и дешевле, так как он удовлетворяет этим двум требованиям.

ВНИМАНИЕ

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

Причины

Более гибкие типы документов могут оказаться более удобными. Универсальный элемент облегчает обработку документа.

Ниже приводится пример кода шаблона:

Ниже приводится пример кода шаблона:
<Paragraph>
Повесть Алберта Камю <General
type="book">Посторонний</General>
служит примером выражения идей
экзистенциализма в литературе
</Paragraph>

Принципы разработки DTD

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

В первой главе мы говорили о двух различных языках для определения классов документов XML: язык определения типов документов, который включен в спецификацию XML 1.0, и схемы XML. В настоящее время обсуждается возможность принятия в качестве стандарта определения типа документа других методов, в том числе XML-Data и DCD (Document Content Description — описание содержимого документа).

ПРИМЕЧАНИЕ

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

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

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

Рассуждайте в терминах реальных процессов

При разработке DTD лучше рассуждать в терминах реальных бизнесс-процес- сов, а не в терминах конкретного приложения. Если вы не делаете никаких предположений о том, как и кем будет обрабатываться документ, вы составите гораздо более гибкое определение DTD. Например, хотя с большой вероятностью можно предположить, что DTD для нашего электронного магазина будет гораздо чаще обрабатываться приложением, чем изучаться людьми, это обстоятельство при разработке DTD не учитывается. Если бы мы составляли определение DTD, которое заведомо использовалось бы только программами, мы, к примеру, могли бы сэкономить значительный объем памяти за счет более коротких (но менее понятных!) имен элементов и за счет более широкого использования параметрических сущностей. Но такой подход искажает саму суть языка XML, предназначенного как раз для того, чтобы чтение документа было легким как для машин, так и для людей. Жертвуя пространством на диске и скоростью работы приложения, вы получаете гораздо более значимый выигрыш — гибкий и удобный в использовании документ XML с корректной разметкой данных.

Разработка сервера web-приложений — это быстрее и лучше

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

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

Репрезентативный образец данных

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

Следует помнить, что нельзя объять необъятное. Если стремиться к этому, вы увязнете в бесконечных спорах и обсуждениях. История показывает, что, когда люди пытаются договориться о стандартах в какой бы то ни было области, будь то языки разметки, программирование или строительство, — всегда существует вероятность углубиться в длительные дискуссии, оставляя нерешенным главный вопрос. Поэтому следует принять волевое решение и остановиться на пусть несовершенном и, возможно, слишком общем определении DTD, которое впоследствии можно будет при необходимости доработать и дополнить, вместо того чтобы продолжать бесконечные споры.

Шаблон универсального элемента создает новый

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

Сборка приложения из стандартных частей — это лучше и дешевле

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

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

Шаблоны XML

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

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

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

Для описания шаблонов имеется определенный стандарт, состоящий из нескольких разделов (краткое описание шаблона, контекст, пример и т. д.). Ниже описывается шаблон универсального элемента (generic element) для web-документов. Этот шаблон и многие другие можно найти на сайте www.xmlpatterns.com.

SOAP

SOAP — это протокол, предназначенный для удаленного вызова процедур, основанный на стандартах XML и HTTP. В декабре 1999 года протокол SOAP был предложен компаниями DevelopMentor Inc., Microsoft и UserLand Software Inc. на рассмотрение Консорциуму W3C как Интернет-проект.

Методы SOAP вызываются с помощью HTTP-запросов POST. В заголовке HTTP SoapMethodName указывается имя метода, который требуется вызвать. В следующем примере в заголовке указаны пространство имен вызываемого метода (sybex- com) и имя метода (getPrice):

POST /xmlstore.jsp HTTP/1.1

Host: www.sybex.com

SOAPMethodName: urn:sybex - com:SybexStore#getPrice

Content-Type: text/xml

Content-Length: nnnn

Содержательная часть сообщения SOAP пишется на XML:

<?xml version='1.0'?>

<SOAP:Envelope

xmlns:SOAP='urn:schemas-xmlsoap-org:soap.vl'>

<SOAP:Body>

<nsl:getPrice

xmlns:nsl=' urn:sybex-com:SybexStore '>

</nsl:getPrice>

</SOAP:Body>

</SOAP:Envelope>

Этот запрос просто передает на сервер все данные, необходимые для вызова указанного метода. Обратите внимание, что пространство имен, указанное в первом элементе внутри SOAP:Body, должно совпадать с пространством имен в заголовке SoapMethodName.

Если дальше все идет нормально (запрошенный метод реально существует и удаленный сервер принимает запросы SOAP), то будут предприняты определенные действия, соответствующие запросу. Когда эти действия будут выполнены, полученный HTTP-ответ, содержащий данные XML, будет послан обратно клиенту.

Пока что SOAP не является официальной спецификацией Консорциума W3C, но если вы хотите начать использовать этот протокол прямо сейчас, у вас имеется такая возможность — IBM и DevelopMentor создали библиотеки Java, которые реализуют технологию SOAP. Вы можете воспользоваться сайтом организации Apache (http://xml.apache.org/soap/index.htm), откуда можно загрузить все IBM-версии SOAP, a Perl- и Java-версии компании DevelopMentor можно загрузить по адресу www.develop.com/SOAP.

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

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

Многие так называемые партнерские программы в настоящее время требуют, чтобы приложение-потребитель (партнерский сайт) получило от поставщика код HTML. Недостатком такого подхода является то, что формат полученной информации предопределен. С другой стороны, с помощью XML потребитель может форматировать данные так, как ему нужно. Дополнительным преимуществом XML при обмене информацией между сайтами является то, что документ XML, в отличие от HTML, может использоваться потребителем не только для отображения информации.

Создание первого чернового варианта DID

Для создания первого чернового варианта DTD, чтобы определить класс данных, которому принадлежит приведенный выше документ XML, мы использовали редактор XML CLIP!, созданный компанией Techno2000USA, Inc. Этот редактор имеет очень удобное свойство — он позволяет создавать DTD на основе правильно оформленного документа XML. В листинге 2.5 приведено полученное таким образом определение DTD. Для автоматизации процедуры создания первого чернового варианта DTD пригодны многие редакторы XML. Например, редактор XML Spy (доступный по адресу www.xmlspy.com) может сгенерировать DTD (а также некоторые другие типы схем XML) на основе любого правильно оформленного документа XML.

Листинг 2.5. Первый черновой вариант DID

<!ELEMENT catalog (product_line)* >

<!ELEMENT product_line (product)* >

<!ATTLIST product_line

name CDATA #IMPLIED>

<!ELEMENT product(name]description|price|

quanti ty_in_stock|image|onsale_date|clip)* >

<!ATTLIST product

id CDATA #IMPLIED>

<!ELEMENT name (#PCDATA)* >

<!ELEMENT description (#PCDATA)* >

<!ELEMENT price (#PCDATA)* >

<!ELEMENT quantity_in_stock (#PCDATA)* >

<!ELEMENT image (caption)* >

<!ATTLIST image

width CDATA #IMPLIEO>

<!ATTLIST image

height CDATA #IMPLIED>

<!ATTLIST image

src CDATA #IMPLIED>

<!ELEMENT caption (#PCDATA)* >

<!ELEMENT onsale_date (#PCDATA)* >

<!ELEMENT clip (title)* >

<!ATTLIST clip

format CDATA #IMPLIED>

<!ATTLIST clip

length CDATA #IMPLIED>

<!ATTLIST clip

size CDATA #IMPLIED>

<!ATTLIST clip

src CDATA #IHPLIED>

<!ELEMENT title (#PCDATA)* >

Стандартизация DTD

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

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

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

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

Commerce One, поставщик программного обеспечения для электронной коммерции, предлагает «общую бизнес-библиотеку» — Common Business Library (CBL) — открытые спецификации XML для обмена документами между разными промышленными секторами. Такими документами могут быть заказы на приобретение, описания продуктов или схемы поставок.

Организация UN/CEFACT (The United Nations Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport — Центр по упрощению процедур и практики в управлении, торговле и на транспорте) при ООН реализует проект EbXML (XML for electronic bismess — XML для электронного бизнеса), направленный на создание «единого глобального электронного рынка», который поддерживается Организацией OASIS (Organization for the Advancement of Structured Information Standards). Согласно определению, приведенному на web-сайте www.ebxml.org, EbXML — это открытый глобальный основанный на XML стандарт для электронной коммерции.

Согласно IBM, язык BRML (Business Rules Markup Language — язык разметки для деловых операций) — это «промежуточный язык для службы Agent Communication, основанный на программах Courteous/Ordinary Logic». BRML используется совместно с CommonRules IBM — библиотекой Java, которая обеспечивает функциональность для деловых операций.

Язык traML (Trading Partner Agreement Markup Language — язык разметки для соглашений между торговыми партнерами) предложен компанией IBM как язык для организации электронных контактов между торговыми партнерами.

В настоящее время разработана спецификация ОТР (Online Trading Protocol — открытый торговый протокол), которая представляет собой структуру для осуществления деловых транзакций на основе XML, независимую от систем оплаты. Протокол ОТР был разработан несколькими банками и компаниями, занимающимися проведением коммерческих расчетов через Интернет, в том числе SET, Mondex, CyberCash, DigiCash и GeldKarte.

Гибкость и возможность многократного использования данных являются ключевыми принципами при развитии удобных в управлении приложений XML. Тщательная разработка DTD или, если возможно, соглашение о едином стандарте DTD в данной области должны стать первым шагом при разработке любого серьезного приложения XML. В следующих главах нашей книги при обсуждении вопросов манипулирования данными XML с помощью языка Java всегда будет использоваться определение DTD (хотя время от времени его придется модифицировать) для обеспечения структурированности и целостности данных.

Требования

Бизнес-требования (business requirements), или требования верхнего уровня (high- level requirements), определяют глобальные цели, которые стоят перед компанией, проектирующей свой web-сайт. После того как решение о создании такого сайта принято, следует ясно и четко изложить эти требования в специальном документе, регламентирующем политику компании.

Пользовательские требования (user requirements) — это те задачи, которые должен решать пользовательский интерфейс сайта. Предположим, для сайта XMLGifts.com бизнес-требования и пользовательские требования сводятся к следующему:

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

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

сайт должен быть исходно рассчитан на некоторое умеренное количество посещений, но следует предусмотреть возможность повышения производительности сайта (по мере роста его популярности), причем это не должно требовать его полной переделки;

сайт должен поддерживать партнерские программы, при выполнении которых на других сайтах можно располагать информацию о товарах компании XMLGifts и ссылки на сайт XMLGifts.com;

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

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

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

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

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

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

каталог, созданный для электронного магазина, должен допускать использование в качестве центральной базы данных для всей компании. Например, нужно обеспечить возможность генерации печатной версии каталога из того же источника данных, что и web-сайт;

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

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

Упрощайте DTD

Не делайте определение DTD настолько сложным, чтобы его нельзя было легко и просто прочитать. Чем легче для чтения и понимания будет ваше DTD, тем оно окажется полезнее. Если вы разрабатываете DTD для очень специализированной области применения, оно неизбежно будет сложнее, чем DTD для обычного каталога товаров. В листинге 2.8 представлены два определения DTD, причем второе выполняет те же функции, хотя гораздо проще первого [Phone call — телефонный звонок, valid phone digits — допустимые телефонные символы, from — от, to — кому, content — содержимое, phone number — телефонный номер, digit — цифра (символ), dash — тире, caller — вызывающий абонент, answerer — отвечающий абонент — Примеч. перев. ].

Листинг 2.8. Два возможных DTD для описания телефонного звонка.

<!—DTD для элемента phone_call-->

<!ENTITY % valid jihone_ch gits '"

(1|2|A|B|C|3|D|E|F|4|G|H|I|5|J|K|L|6|M|N|

0|7|P|R|S|8|T|U|V|9|W|X|Y|0)">

<'ELEMENT phone_call (from*.to*,content)>

<!ELEMENT from (phone_number)>

<!ELEMENT phone_number ((dig!t?,digit'.digit?,dash?)?,

digit, digit, digit, dash, digit, digit,digit,digit)>

<!ELEMENT digit EMPTY> <!ATTLIST digit number

%valid_phone_dlgits; #REQUIRED>

<!ELEMENT dash EMPTY>

<!ATTLIST dash

value CDATA #FIXED "-">

OELEMENT to (phone_number)> <iELEMENT content

(caller|answerer)*> <'ELEMENT caller (#PCDATA)>

<!ELEMENT answerer (#PCDATA)>

<!—упрощенное определение DTD для элемента phone_call-->

<!ELEMENT phone_call (from*,to*,content)>

<!ELEMENT from EMPTY> <!ATTLIST from

phone_number CDATA #REQUIRED>

<!ELEMENT to EMPTY>

<!ATTL1ST to phone_number CDATA #REQUIRED>

<!ELEMENT content (caller|answerer)*>

<!ELEMENT caller (#PCDATA)>

<!ELEMENT answerer (#PCDATA)>

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

Уточнение чернового варианта

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

Основная задача, стоявшая перед создателями

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