КаталогИндекс раздела


© IBM deweloperWork
© А.С.Деревянко (перевод)

Введение в XML

Doug Tidwell

07 августа 2002

Содержание

  1. Об этом учебнике
  2. Что такое XML?
  3. Правила XML-документа
  4. Определение содержимого документа
  5. Программные интерфейсы XML
  6. Стандарты XML
  7. Практические примеры
  8. Рекомендации

XML, Extensible Markup Language (Расширяемый Язык Разметки), превратился за рекордное время из модного словечка в неотъемлемую технологию электронного бизнеса. В этом заново пересмотренном учебнике обсуждается, что такое XML, почему он был создан, и как он формирует электронную коммерцию. Здесь также рассматриваются разные программные интерфейсы XML и стандарты, и заканчивается учебник двумя практическими примерами, показывающими, как компании используют XML для решения задач бизнеса.

Раздел 1. Об этом учебнике

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

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

В этом учебнике вы изучите:

 

Раздел 2. Что такое XML?

Введение

XML или Extensible Markup Language (Расширяемый Язык Разметки), является языком разметки, который вы можете использовать для создания ваших собственных тегов. Он был создан в World Wide Web Consortium (W3C) для преодоления ограничений языка HTML, Hypertext Markup Language (Гипертекстовый Язык Разметки), который является основой всех Web-страниц. Как и HTML, XML базируется на SGML - Standard Generalized Markup Language (Стандартный Обобщенный Язык Разметки). Хотя SGML десятилетиями использовался в издательском деле, он представляется сложным, что отпугивает многих людей, которые могли бы его использовать (SGML также расшифровывается как "Sounds great, maybe later" - "Звучит великолепно, может быть, позже"). XML был разработан с прицелом на Web.

Зачем нам нужен XML?

HTML - наиболее успешный язык разметки всех времен. Вы можете просмотреть простейшие теги HTML практически на любом устройстве от PDA до мейнфрейма и вы можете даже преобразовать разметку HTML в голос и в другие форматы при помощи соответствующих инструментов. При таком успехе HTML, почему же W3C создал XML? Чтобы ответить на этот вопрос, взглянем на такой документ:

<p><b>Mrs. Mary McGoon</b>
<br>
1401 Main Street
<br>
Anytown, NC 34829</p>

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

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

Отображение HTML

Чтобы отобразить HTML, браузер просто следует инструкциям в HTML-документе. Тег параграфа (<p>) сообщает браузеру, что нужно отобразить новую строку, обычно, с пропуском строки перед ней, а два тега разрыва (<br>) сообщают браузеру, что нужно перейти на новую строку без пропусков между строками. Браузер прекрасно форматирует документ, но машина все же не знает, что это адрес.


Рисунок 1 Адрес HTML

Обработка HTML

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

Если вы нашли параграф с двумя тегами <br>, почтовый код является вторым словом после первой запятой после второго тега разрыва.

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

Пример XML-документа

Теперь давайте рассмотрим пример XML-документа. В XML вы можете назначить некоторое значение тегам в документе. Что еще более важно, эту информацию также легко обработать для машины. Вы можете выделить почтовый код из этого документа просто найдя содержимое, обрамленное тегами <postal-code> и </postal-code>, называемое элементом <postal-code>.

<address>
 <name>
  <title>Mrs.</title>
  <first-name>
   Mary
  </first-name>
  <last-name>
   McGoon
  </last-name>
 </name>
 <street>
  1401 Main Street
 </street>
 <city>Anytown</city>
 <state>NC</state>
 <postal-code>
  34829
  </postal-code>
</address>

Теги, элементы и атрибуты

Есть три общих термина, используемых для описания частей XML-документа: теги, элементы и атрибуты. Вот пример документа, иллюстрирующего эти термины:

<address>
 <name>
  <title>Mrs.</title>
  <first-name>
   Mary
  </first-name>
  <last-name>
   McGoon
  </last-name>
 </name>
 <street>
  1401 Main Street
 </street>
 <city state="NC">Anytown</city>
 <postal-code>
  34829
 </postal-code>
</address>

Как XML изменяет Web

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

Мы также обсудим реальные применения XML в Практические примеры.

 

Раздел 3. Правила XML-документа

Обзор: правила XML-документа

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

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

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

Неправильные, правильные, и правильно-форматированные документы

Есть три вида XML-документов:

Корневой элемент

Документ XML должен содержаться в единственном элементе. Этот единственный элемент называется корневым элементом и содержит весь текст и любые другие элементы документа. В следующем примере XML-документ содержит единственный элемент, элемент <greeting>. Заметьте, что документ содержит комментарий вне корневого элемента, который является вполне допустимым.

<?xml version="1.0"?>
<!-- Правильно-форматированный документ -->
<greeting>
 Hello, World!
</greeting>

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

<?xml version="1.0"?>
<!-- Неправильный документ -->
<greeting>
 Hello, World!
</greeting>
<greeting>
 Hola, el Mundo!
</greeting>

От XML-парсера требуется забраковать этот документ независимо от его содержания.

Элементы не могут перекрываться

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

<!-- Неправильная разметка XML -->
<p>
<b>I <i>really
love</b> XML.
</i>
</p>

Если вы начинаете элемент <i> внутри элемента <b>, вы должны его там же и закончить. Если вы хотите, чтобы текст XML появлялся в наклонном шрифте, вам нужно добавить в разметку второй элемент <i>:

<!-- Правильная разметка XML -->
<p>
<b>I <i>really
love</i></b>
<i>XML.</i>
</p>
XML-парсер будет принимать только эту разметку; HTML-парсеры в большинстве Web-браузеров будут принимать обе.

Конечные теги являются обязательными

Вы не можете опускать какие-либо закрывающие теги. В первом примере, приведенном выше, разметка неправильна потому, что нет закрывающего тега параграфа (</p>). Хотя это приемлемо для HTML (и, в некоторых случаях, для SGML), XML-парсер это забракует.

<!-- Неправильная разметка XML -->
<p>Yada yada yada...
<p>Yada yada yada...
<p>...

Если элемент вообще не содержит разметки, он называется пустым элементом; HTML-элементы разрыва (<br>) и изображения (<img>) являются примерами этого. В пустом элементе XML-документа вы можете поместить закрывающую косую черту в начальный тег. Следующие два элемента разрыва и два элемента изображения являются для XML-парсера одним и тем же:

<!-- Два эквивалентных элемента разрыва -->
<br></br>
<br />
<!-- Два эквивалентных элемента изображения -->
<!-- Two equivalent image elements -->
<img src="../img/c.gif"></img>
<img src="../img/c.gif" />

Элементы чувствительны к регистру

Элементы XML чувствительны к регистру. В HTML <h1> и <H1> - одно и то же; в XML - нет. Если вы попытаетесь закончить элемент <h1> тегом </H1>, вы получите ошибку. В примере ниже заголовок вверху неправильный, а внизу - правильный.

<!-- Неправильная разметка XML -->
<h1>Elements are
case sensitive</H1>
<!-- Правильная разметка XML -->
<h1>Elements are
case sensitive</h1>

Атрибуты должны иметь значения в кавычках

Есть два правила для атрибутов в XML-документах:

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

<!-- Неправильная разметка XML -->
<ol compact>
<!-- legal XML markup -->
<ol compact="yes">

Вы можете использовать одинарные или двойные кавычки, но только согласованно.

Если значение атрибута содержит одинарные или двойные кавычки, вы можете использовать другой вид кавычек, чтобы заключить значение (как в name="Doug's car"), или использовать сущности &quot; для двойной кавычки и &apos; для одинарной. Сущность - это символ, такой, как &quot;, который XML-парсер заменяет на другой текст, такой, как ".

Объявления XML

Большинство XML-документов начинаются с XML-объявления, которое обеспечивает базовую информацию о документе для парсера. Употребление XML-объявления рекомендуется, но не является обязательным. Если оно есть, оно должно быть первым, что есть в документе.

Объявление может содержать до трех пар имя-значение (многие называют их атрибутами, хотя технически они таковыми не являются). version - используемая версия XML; в настоящее время она должна быть 1.0. encoding - набор символов, используемый в этом документе. Набор символов ISO-8859-1, на который ссылается данное объявление, включает в себя символы, используемые в большинстве западноевропейских языков. Если encoding не указан, XML-парсер предполагает набор UTF-8, стандарт Unicode, который поддерживает почти все символы и иероглифы всех языков мира.

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>

Наконец, standalone, который может быть либо yes, либо no, определяет, может ли этот документ быть обработан без чтения каких-либо других файлов. Например, если XML-документ не ссылается на другие файлы, вы должны указать standalone="yes". Если же XML-документ ссылается на другие файлы, который описывают, что документ может содержать (больше об этих файлах - через минуту), вы должны указать standalone="no". Поскольку по умолчанию предполагается standalone="no", вы редко видите standalone в XML-объявлениях.

Другие вещи в XML-документах

Есть несколько других вещей, которые вы можете найти в XML-документе:

Пространства имен

Мощность XML происходит от его гибкости, из того факта, что вы и я, и миллионы других людей можем определять наши собственные теги, чтобы описывать наши данные. Помните пример XML-документа для имени и адреса человека? Этот документ включает в себя элемент <title> для вежливого именования человека, вполне подходящий выбор для элемента имени. Если же вы работаете с онлайновым книгохранилищем, вы можете создать элемент <title> для названия книги. Если же вы работаете с онлайновой закладной компанией, вы можете создать элемент <title> для части закладного документа. Все это разумные варианты, но все они создают элементы с одним и тем же именем. Как вы сообщите, что данный элемент <title> относится к человеку, книге или части закладной? При помощи пространств имен.

Чтобы использовать пространство имен, вы определяете префикс пространства имен и отображаете его на определенную строку. Вот так вы можете различить префиксы пространства имен для наших трех элементов <title>:

<?xml version="1.0"?>
<customer_summary
    xmlns:addr="http://www.xyz.com/addresses/"
    xmlns:books="http://www.zyx.com/books/"
    xmlns:mortgage="http://www.yyz.com/title/"
    >
... <addr:name><title>Mrs.</title> ... </addr:name> ...
... <books:title>Lord of the Rings</books:title> ...
... <mortgage:title>NC2948-388-1983</mortgage:title> ...

В этом примере три префикса пространства имен: addr, books, и mortgage. Заметьте, что определение пространства имен для определенного элемента означает, что все его дочерние элементы принадлежат к тому же пространству имен. Первый элемент <title> принадлежит к пространству имен, поскольку к нему принадлежит его родительский элемент, <addr:Name> .

Одно последнее замечание: Строка в определении пространства имен является только строкой. Да, эти строки выглядят как URL, но ими не являются. Вы можете определить xmlns:addr="mike", и это также будет работать. Только одно важно в отношении строки пространства имен: она должна быть уникальной; вот почему большинство пространств имен выглядят как URL. XML-парсер не обращается к http://www.zyx.com/books/, чтобы найти DTD или схему, он просто использует этот текст как строку. Это несколько сбивает с толку, но именно так работают пространства имен.

 

Раздел 4. Определение содержимого документа

Обзор: Определение содержимого документа

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

DTD - Определение Типа Документа

DTD позволяет вам задать основную структуру XML-документа. Следующая пара разделов рассматривает фрагменты DTD. Прежде всего, вот DTD, которое определяет основную структуру примера документа адреса из раздела Что такое XML?:

<!-- address.dtd -->
<!ELEMENT address (name, street, city, state, postal-code)>
<!ELEMENT name (title? first-name, last-name)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT first-name (#PCDATA)>
<!ELEMENT last-name (#PCDATA)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT postal-code (#PCDATA)>

Это DTD определяет все элементы, используемые в примере документа. Оно определяет три основные вещи:

Хотя DTD простое, оно проясняет, какие комбинации элементов являются допустимыми. Документ адреса, который имеет элемент <postal-code> перед элементом <state>, не является правильным, как и документ, который не имеет элемента <last-name>.

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

Символы в DTD

Есть несколько символов, используемых в DTD для индикации того, как часто (или когда) что-либо может появляться в XML-документе. Вот некоторые примеры и их смысл:

Замечание по поводу гибкости

Прежде, чем двигаться дальше, сделаем маленькое замечание о разработки типов XML-документа для обеспечения гибкости. Рассмотрим пример типа документа имени и адреса; я, понятно, писал его, имея в виду почтовые адреса США. Если вам нужно DTD или схема, которые определяют другие типы адресов, вы должны будете сделать их значительно более сложными. Обязательность элемента <state> может иметь смысл в Австралии, но не в Соединенном Королевстве. Канадский адрес может быть обработан DTD из примера в Определение Типа Документа, но лучше будет добавить элемент <province>. Наконец, во многих частях света такие концепции, как именование, первое имя и последнее имя не имеют смысла.

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

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

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

Предположим, вы хотите изменить DTD, чтобы сделать state атрибутом элемента <city>. Вот как это сделать:

<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA #REQUIRED>

Здесь элемент <city> определяется, как и прежде, но пересмотренный пример также использует объявление ATTLIST для перечисления атрибутов элемента. Имя city в списке атрибутов сообщает парсеру, что эти атрибуты определяются для элемента <city>. Имя state является именем атрибута, а ключевые слова CDATA и #REQUIRED сообщают парсеру, что атрибут state содержит текст и является обязательным (если он не обязательный, это обеспечится при помощи CDATA #IMPLIED).

Чтобы определить много атрибутов для элемента, запишите ATTLIST, подобный такому:

<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA #REQUIRED
postal-code CDATA #REQUIRED>

Этот пример определяет и state, и postal-code как атрибуты элемента <city>.

Наконец, DTD позволяют вам определять значения по умолчанию для атрибутов и перечислять все допустимые значения для атрибута:

<!ELEMENT city (#PCDATA)>
<!ATTLIST city state CDATA (AZ|CA|NV|OR|UT|WA) "CA">

Этот пример показывает, что поддерживаются только адреса из штатов Аризона (AZ), Калифорния (CA), Невада (NV), Орегон (OR), Юта (UT) и Вашингтон (WA), в штат по умолчанию - Калифорния. Таким образом, вы можете обеспечить весьма ограниченную форму проверки данных. Хотя это и полезная функция, но это лишь малое подмножество того, что вы можете проделать при помощи схем XML.

Схемы XML

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

Ничего из этого вы не можете сделать при помощи DTD.

Пример схемы XML

Вот схема XML, которая соответствует исходному DTD имени и адреса. В ней добавлено два ограничения. Значение элемента <state> должно состоять точно из двух символов, а значение элемента <postal-code> должно соответствовать регулярному выражению [0-9]{5}(-[0-9]{4})?. Хотя схема значительно длиннее, чем DTD, она выражает больше ясности в том, на что похож правильный документ. Вот эта схема:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="address">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="name"/>
    <xsd:element ref="street"/>
    <xsd:element ref="city"/>
    <xsd:element ref="state"/>
    <xsd:element ref="postal-code"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="name">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="title" minOccurs="0"/>
    <xsd:element ref="first-Name"/>
    <xsd:element ref="last-Name"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="title" type="xsd:string"/>
 <xsd:element name="first-Name" type="xsd:string"/>
 <xsd:element name="last-Name" type="xsd:string"/>
 <xsd:element name="street" type="xsd:string"/>
 <xsd:element name="city" type="xsd:string"/>
 <xsd:element name="state">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:length value="2"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>
 <xsd:element name="postal-code">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>
</xsd:schema>

Определение элементов в схемах

Схема XML в Пример схемы XML определяет несколько элементов XML при помощи элемента <xsd:element>. Первые два определенных элемента, <address> и <name>, состоят из других элементов. Элемент <xsd:sequence> определяет последовательность элементов, которая содержится в каждом. Вот пример:

 <xsd:element name="address">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="name"/>
    <xsd:element ref="street"/>
    <xsd:element ref="city"/>
    <xsd:element ref="state"/>
    <xsd:element ref="postal-code"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>

Как и версия с DTD, пример схемы XML определяет, что <address> содержит элементы <name>, <street>, <city>, <state> и <postal-code> в таком порядке. Заметьте, что схема определяет новый тип данных при помощи элемента <xsd:complexType>. Большинство элементов содержит текст, их определение простое. Вы только объявляете новый элемент и даете ему тип данных xsd:string:

 <xsd:element name="title" type="xsd:string"/>
 <xsd:element name="first-Name" type="xsd:string"/>
 <xsd:element name="last-Name" type="xsd:string"/>
 <xsd:element name="street" type="xsd:string"/>
 <xsd:element name="city" type="xsd:string"/>

Определение содержимого элемента в схемах

Пример схемы определяет ограничения для содержимого двух элементов: Содержимое элемента <state> должно иметь длину в два символа, а содержимое элемента <postal-code> должно соответствовать регулярному выражению [0-9]{5}(-[0-9]{4})?. Вот как это сделано:

 <xsd:element name="state">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:length value="2"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>
 <xsd:element name="postal-code">
  <xsd:simpleType>
   <xsd:restriction base="xsd:string">
    <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/>
   </xsd:restriction>
  </xsd:simpleType>
 </xsd:element>

Для элементов <state> и <postal-code> схема определяет новые типы данных с ограничениями. В первом случае используется элемент <xsd:length>, а во втором - элемент <xsd:pattern> для определения регулярного выражения, которому этот элемент должен соответствовать.

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

 

Раздел 5. Программные интерфейсы XML

Обзор: Программные интерфейсы XML

В этом разделе рассматривается ряд программных интерфейсов для XML. Эти интерфейсы дают разработчикам целостный интерфейс для работы с XML-документами. Существует много доступных API; в этом разделе рассматриваются четыре из них, наиболее популярные и наиболее часто используемые: Объектная Модель Документа (Document Object Model - DOM), Простой API для XML (Simple API for XML - SAX), JDOM и Java API для Разбора XML (Java API for XML Parsing - JAXP). (Вы можете найти значительно больше информации по этим API через ссылки в Ресурсы.)

Объектная Модель Документа

Объектная Модель Документа, обычно называемая DOM, определяет набор интерфейсов для разобранной версии XML-документа. Парсер читает весь документ и строит дерево в памяти, так что ваш код может использовать интерфейсы DOM для манипулирования деревом. Вы можете двигаться по дереву, чтобы увидеть, что содержал исходный документ, вы можете удалять части дерева, вы можете переупорядочить дерево, добавлять новые ветви и т.д. DOM была создана W3C, и это - Официальная Рекомендация консорциума.

Проблемы DOM

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

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

Это только спорные вопросы, возникшие при проектировании DOM; несмотря на это, API DOM является очень удобным способом для разбора XML-документов.

Simple API for XML

Чтобы обойти проблемы DOM, участники XML-DEV (возглавляемой David Megginson) создали интерфейс SAX. SAX имеет несколько характеристик, направленных на преодоление недостатков DOM:

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

Проблемы SAX

Чтобы быть честными, парсеры SAX также имеют проблемы, которые могут вызывать опасения:

JDOM

Разочарованные трудностями в выполнении определенных задач при помощи моделей DOM и SAX, Jason Hunter и Brett McLaughlin создали пакет JDOM. JDOM - проект с открытым кодом на основе технологии Java, в который старается следовать правилу 80/20: распределитель, который нужен 80% пользователей, и 20% функций DOM и SAX. JDOM работает с парсерами SAX и DOM, так что он реализован, как относительно небольшой набор Java-классов.

Главным свойством JDOM является то, что он значительно уменьшает объем кода, который вам приходится писать. Хотя этот вводный учебник не обсуждает программные темы подробно, приложения JDOM обычно по размеру в три раза меньше, чем приложения DOM и примерно вполовину меньше, чем приложения SAX. (Сторонники DOM, конечно, считают, что изучение и использование DOM является хорошим и дисциплинирующим делом, которое окупает себя со временем.) JDOM не делает ничего, но для большинства разборов, которые вы будете делать, это, возможно, то, что нужно.

Java API for XML Parsing

Хотя DOM, SAX и JDOM обеспечивают стандартные интерфейсы для наиболее общих задач, есть все же несколько вещей, на которые они не рассчитаны. Например, процесс создания объекта DOMParser в программе Java отличается от парсера DOM в другой. Для решения этой проблемы фирма Sun реализовала JAXP, Java API for XML Parsing. Этот API обеспечивает общие интерфейсы для обработки XML-документов с использованием DOM, SAX и XSLT.

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

Какой интерфейс подходит для вас?

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

Разумеется, API XML существуют и для других языков, в частности, сообщества Perl и Python имеют очень хороший инструментарий XML.

 

Раздел 6. Стандарты XML

Обзор: Стандарты XML

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

Спецификация XML

Эта спецификация, находящаяся на w3.org/TR/REC-xml, определяет базовые правила для XML-документов. Все правила XML-документа, обсуждавшиеся ранее в этом учебнике, определены здесь.

Вдобавок к базовому стандарту XML, другой важной частью XML является спецификация Namespaces. Вы можете найти стандарт на пространства имен также в W3C: w3.org/TR/REC-xml-names/.

XML Schema

Язык XML Schema определен в трех частях:

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

XSL, XSLT и XPath

Расширяемый Язык Таблиц Стилей (Extensible Stylesheet Language - XSL) определяет набор элементов (называемых объектами форматирования), которые описывают, как данные должны форматироваться. Для ясности этот стандарт часто называют XSL-FO, чтобы отличать от XSLT. Хотя он первоначально разработан для генерации высококачественных печатаемых документов, вы также можете использовать объекты форматирования для генерации аудиофайлов из XML. Стандарт XSL-FO находится на w3.org/TR/xsl/.

Extensible Stylesheet Language for Transformations, XSLT является , словарем XML, который описывает, как преобразовать XML-документ во что-то еще. Стандарт находится на w3.org/TR/xslt (без закрывающей косой черты).

XPath, XML Path Language, - синтаксис, который описывает местонахождения в XML-документах. Вы используете XPath в таблицах стилей XSLT для описания того, какую часть XML-документа вы хотите преобразовать. XPath используется также и в других стандартах XML, вот почему от отделен от XSLT в отдельный стандарт. XPath определен на w3.org/TR/xpath (без закрывающей косой черты).

DOM

Document Object Model определяет, как XML-документ преобразуется в структуру дерева в памяти. DOM определена в нескольких спецификациях в W3C:

SAX, JDOM и JAXP

Simple API for XML определяет события и интерфейсы, используемые для взаимодействия с SAX-совместимым парсером XML. Вы найдете полную спецификацию SAX на www.saxproject.org.

Проект JDOM был создан Jason Hunter и Brett McLaughlin и живет на jdom.org/. На сайте JDOM вы найдете коды, примеры программ и другие инструменты, которые помогут вам начать. (Статьи developerWorks о JDOM см. в Ресурсы.)

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

Вы найдете все, что известно о JAXP на java.sun.com/xml/jaxp/.

Связывание и ссылки

В мире XML есть два стандарта для связывания и ссылок: XLink и XPointer:

Безопасность

Есть два значимых стандарта, которые относятся к безопасности XML-документов. Один - стандарт XML Digital Signature (w3.org/TR/xmldsig-core/), который определяет структуру XML-документа для цифровых подписей. Вы можете создать цифровую подпись XML для любого вида данных, будь это XML-документ, HTML-файл, обычный текст, двоичные данные и т.д. Вы можете использовать цифровую подпись для проверки того, что определенный файл не был модифицирован после подписания. Если подписанные вами данные являются XML-документом, вы можете встроить XML-документ в сам файл подписи, что делает обработку данных и подписи очень простой.

Другой стандарт относится к шифрованию XML-документов. Хотя замечательно, что XML-документы могут быть написаны так, что их может читать и понимать человек, могут возникнуть неприятности, если документ попадет в плохие руки. Стандарт XML Encryption (w3.org/TR/xmlenc-core/) определяет, как части XML-документа могут быть зашифрованы.

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

Web-сервисы

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

Другие стандарты

Существует много других стандартов XML, о которых мы не говорим здесь. Вдобавок к стандартам широкого применения, подобным Scalable Vector Graphics (www.w3.org/TR/SVG/) и SMIL, Synchronized Multimedia Integration Language (www.w3.org/TR/smil20/), есть много стандартов, относящихся к отдельным отраслям. Например, консорциум HR-XML определил несколько стандартов XML для трудовых ресурсов, вы можете найти эти стандарты на hr-xml.org.

Наконец, хорошим источником стандартов XML является XML Repository на xml.org/xml/registry.jsp. Этот сайт представляет сотни стандартов для широкого спектра отраслей.

 

Раздел 7. Практические примеры

Примеры из реальной жизни

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

Все практические примеры, обсуждаемые здесь, пришли из программы IBM jStart. Команда jStart существует, чтобы помогать потребителям использовать новые технологии для решения проблем. Если потребитель соглашается с условиями jStart, он получает консультации и сервис разработки от IBM со скидкой, с пониманием того, что результирующий проект может быть использован как практический пример. Если вы хотите увидеть больше практических примеров, включая примеры Web-сервисов и других новых технологий, посетите Web-страницу jStart ibm.com/software/jstart.

Знайте, что команда jStart больше не заключает соглашений по проектам XML; сейчас команда фокусируется на соглашениях по Web-сервисам. Web-сервисы используют XML специфическим образом, обычно через стандарты SOAP, WSDL и UDDI, упомянутые выше.

Провинция Манитоба


Рисунок 2. Провинция Манитоба

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

Разработка приложения

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

Как и в любом приложении, пользовательский интерфейс приложения был чрезвычайно важен. Чтобы упростить первую реализацию, необходимые XML-данные преобразовывались в HTML. Это давало пользователь возможность использовать браузер для интерфейса приложения. Реестр был построен с помощью VisualAge for Java, в частности, компонента Visual Servlet Builder. Он также использовал Enterprise Java Beans (EJB), включая бины сеанса и бины сущности.

Генерация различных пользовательских интерфейсов при помощи XML

Кроме интерфейса HTML, планируется также интерфейс Java-клиента и электронный интерфейс B2B. Для всех этих интерфейсов структурированные данные XML преобразуются в соответствующие структуры и документы. Начальная выгрузка сервиса позволяет одному бизнес-партнеру, Canadian Securities Registration Systems, посылать данные транзакции XML, используя Secure Sockets Layer. Данные транзакции XML преобразуются в соответствующий формат для транзакций на стороне сервера.

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

Банк First Union на XML


Рисунок 3. Банк First Union на XML

First Union National Bank, один из самых больших банков в США, находится в процессе реинжениринга многих своих приложений при помощи Java и XML. Как и у большинства больших компаний, его среда гетерогенна с серверами OS/390, AIX, Solaris, HP/9000 и Windows NT и клиентами Windows NT, Windows 98, Solaris и AIX. Имея такую среду, First Union выбрал Java для платформенно-независимых кодов и XML для платформенно-независимых данных.

Система на базе сообщений

Распределенное приложение банка построено на инфраструктуре обмена сообщениями с использование для доставки сообщений IBM's MQSeries для системы OS/390. Содержание сообщение базируется на спецификации, называемой Common Interface Message (CIM), собственном стандарте First Union. И клиентские, и серверные компоненты приложения зависят от формата сообщения. К протоколу обмена сообщениями добавлено использование XML, как формата данных, изолирующего обе стороны приложения от будущих изменений.

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

При разработке этого приложения на базе XML First Union и команда IBM создали службу, которая конвертирует CIM в XML-документ. Другая часть приложения конвертирует XML-запрос в определенный формат серверных систем обработки. Наконец, третья служба конвертирует описания на COBOL в DTD. Раз описания конвертированы в DTD, First Union может использовать DTD и парсер XML4J для автоматической проверки правильности XML-документа, банк, следовательно, может быть уверен, что XML-документ соответствует структуре данных COBOL, чего ожидает OS/390. Использование технологии Java и XML оказалось очень успешным для First Union. По словам Bill Barnett, менеджера Группы Интеграции Распределенных Объектов в First Union, "Комбинация Java и XML действительно спасительна для нас. Без такой платформенно-независимой среды, как Java, и независимости протокола обмена сообщениями, полученной от использования XML, мы не могли быть уверены, что наша распределенная инфраструктура сможет развиваться, чтобы удовлетворять требованиям нашей постоянно растущей массы потребителей."

Hewitt Associates LLC


Рисунок 4. Hewitt Associates LLC

Hewitt Associates LLC - глобальная консультативная фирма по менеджменту, которая специализируется на решениях по трудовым ресурсам. Компания имеет более 200 корпоративных клиентов во всем мире; эти компании реально имеют более 10 млн. сотрудников.

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

Спасение в Web-сервисах!

Чтобы решить эти проблемы, Hewitt и команда jStart работали вместе для создания Web-сервисов для нужд потребителей Hewitt. Web-сервисы являются новым видом приложений, которые используют XML несколькими интересными способами:

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

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

"Мы видим в Web-сервисах средство обеспечит открытый, неспециализированный доступ к нашим бизнес-сервисам через вездесущую сеть данных," - говорит Tim Hilgenberg, Главный Стратег по Технологиям в Hewitt. Конечный результат: Hewitt разработал более гибкие приложение быстрее и дешевле, клиенты получили лучший доступ к их данным, а существующие унаследованные приложения Hewitt не изменились.

Итог по практическим примерам

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

Чтобы получить дополнительную информацию о практических примерах, свяжитесь с Sam Thompson из IBM по адресу thompsam@us.ibm.com. Вы можете найти дополнительную информацию на Web-сайтах провинции Манитоба - www.gov.mb.ca, First Union - firstunion.com и Hewitt Associates - hewitt.com.

 

Раздел 8. Рекомендации

Полный вперед!

Теперь, я надеюсь, вы убедились, что XML является наилучшим способом перемещать структурированные данные и манипулировать ими. Если вы еще не используете XML, как вам начать? Вот некоторые соображения:

 

Ресурсы

Изучение

 

Об авторе

Старший Программист Doug Tidwell является в IBM ведущим авторитетом по Web-сервисам. Он был докладчиком на первой конференции по XML в 1997 году и более десятилетия работал с языками разметки. Он получил степень бакалавра английского языка в Университете Джорджии и степень магистра компьютерных наук в Университете Вандербильда. Его адрес: dtidwell@us.ibm.com. Вы можете также увидеть его Web-страницу на ibm.com/developerWorks/speakers/dtidwell/.


КаталогИндекс раздела