Введение в XML
         

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


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

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

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

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

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

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



Банк 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, мы не могли быть уверены, что наша распределенная инфраструктура сможет развиваться, чтобы удовлетворять требованиям нашей постоянно растущей массы потребителей."



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




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

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

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



DOM


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

Ядро DOM определяет саму DOM, структуру дерева, виды узлов и исключения, которые ваш код может получать при движении по дереву. Полная спецификация находится на . События определяет события, которые могут происходить на дереве, и как эти события обрабатываются. Эта спецификация также пытается примирить различия между объектными моделями, поддерживаемыми Netscape и Internet Explorer до версий 4 этих браузеров. Эта спецификация находится на . Стиль определяет, как можно из программы обратиться к таблицам стилей XSLT и таблицам стилей CSS. Эта спецификация находится на . Прохождение и порядок определяет интерфейсы, которые позволяют программе проходить по дереву и определять порядок узлов в дереве. Вы найдете полную спецификацию на . Представления определяются как интерфейс AbstractView для самого документа. См. дополнительную информацию в .



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


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

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



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


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

Комментарии: Комментарии могут появляться где угодно в документе; они могут даже появляться перед корневым элементом. Комментарий начинается с <!-- и заканчивается -->. Комментарий не может содержать двойного дефиса (--) нигде, кроме как в конце; за этим исключением, комментарий может содержать что угодно. Самое важное, что любая разметка внутри комментария игнорируется; если вы хотите удалить большой раздел из XML-документа, просто заключите этот раздел в комментарий. (Чтобы восстановить закомментированный раздел, просто удалите теги комментария.) Вот некоторая разметка, содержащая комментарий:

<!-- Это PI для Cocoon: --> <?cocoon-process type="sql"?>

Инструкции обработки: Инструкция обработки является разметкой предназначенной для определенного кода. В примере выше это инструкция обработки (иногда называемая PI) для Cocoon, библиотеки обработки XML от Apache Software Foundation. Когда Cocoon обрабатывает XML-документ, он ищет инструкции обработки которые начинаются с cocoon-process, а затем обрабатывает XML-документ в соответствии с ними. В данном примере атрибут type="sql" сообщает Cocoon, что the XML-документ содержит оператор SQL.

<!-- Это сущность: --> <!ENTITY dw "developerWorks">

Сущности: Приведенный выше пример определяет сущность для документа. Везде, где XML-процессор находит строку &dw;, он заменяет сущность на строку developerWorks. Спецификация XML также определяет пять сущностей, которые вы можете использовать вместо различных специальных символов. Эти сущности такие:

&lt; для символа меньше &gt; для символа больше &quot; для двойной кавычки &apos; для одинарной кавычки (апострофа) &amp; для амперсанда.



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


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

<!-- 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 определяет все элементы, используемые в примере документа. Оно определяет три основные вещи:

Элемент <address> содержит <name>, <street>, <city>, <state> и <postal-code>. Все эти элементы должны присутствовать и именно в таком порядке. Элемент <name> содержит необязательный элемент <title> (знак вопроса означает, что <title> является необязательным), за которым следует элемент <first-name> и элемент <last-name>. Все другие элементы содержат текст. (#PCDATA обозначает разбираемые символьные данные; вы не можете включать другие элементы в эти элементы.)

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

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



Hewitt Associates LLC



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

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

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

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

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

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

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

При помощи Secure Participant Mailbox авторизированные пользователи могут запрашивать отчеты, содержащие персонифицированную информацию о сотрудниках. При помощи With the Retirement Access B2B Connection авторизированные пользователи могут получать подробности финансовой информации клиента.

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

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



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


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

Чтобы получить дополнительную информацию о практических примерах, свяжитесь с Sam Thompson из IBM по адресу . Вы можете найти дополнительную информацию на Web-сайтах провинции Манитоба - , First Union - и Hewitt Associates - .



Изучение


XML-зона developerWorks является вашим круглосуточным магазином для XML-ресурсов. Все, что вы когда-либо хотели знать об XML см. на . developerWorks имеет статьи "Fill your XML toolbox", которые описывают программные средства XML для разных языков:

C/C++: см. статью Rick Parrish на (developerWorks, сентябрь 2001). Perl: см. статью Parand Tony Darugar на (developerWorks, июнь 2001).

Кроме этих статей см. Обзор David Mertz's инструментов XML для Python в его статье "Charming Python: Revisiting XML tools for Python" на . Учебники XML: На developerWorks доступно множество учебников по темам XML, см. самый свежий их список на < a href=http://www.ibm.com/developerworks/views/xml/libraryview.jsp?type_by=Tutorials> www.ibm.com/developerworks/views/xml/libraryview.jsp?type_by=Tutorials. Команда IBM jStart: Команда jStart работает по очень низким ценам, чтобы помочь потребителям строить решения, с использованием новых технологий (например, XML и Web-сервисы). Взамен потребитель соглашается разрешить IBM публикацию его проектов как практических примеров. Дополнительную информацию см. на . Стандарты XML: Вот алфавитный список всех стандартов XML, упомянутых в этом учебнике.

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

Спецификация Core: Спецификация Events: Спецификация Style: Спецификация Traversal and Range: Спецификация Views:

HR-XML.org, консорциум Human Resources XML: JAXP, Java API для XML: JDOM, который не специализируется для чего-либо: SAX, Простой API для XML: SMIL, Синхронизированный Язык Интеграции Мультимедиа: SOAP, который используется для Простого Протокола Доступа к Объекту, но официально не специализируется для чего-либо: SVG, Масштабируемая Векторная Графика: UDDI, Универсальный Протокол Описания, Обнаружения и Интеграции: WSDL, Язык Описания Web-сервисов: (без закрывающей косой черты) XLink, Язык Связывания XML: XML, стандарт, с которого все начинается: XML Digital Signatures (цифровые подписи): XML Encryption (шифрование): XML Namespaces (пространства имен): XML Repository - репозиторий DTD и схем: XML Schema:

Часть 0 - Пример: Часть 1 - Структуры документа: Часть 2 - Типы данных:

XPath, Язык Маршрутов XML: (без закрывающей косой черты) XPointer, Язык Указателей XML: XSL-FO, Расширяемый Язык Стилей для Форматирования Объектов: XSLT, Расширяемый Язык Стилей: (без закрывающей косой черты)

Дополнительную информацию о JDOM, см. в статьях developerWorks:

Simplify XML programming with JDOM на (developerWorks, май 2001) Converting from DOM на (developerWorks, апрель 2001) Converting from SAX на (developerWorks, апрель 2001) Using JDOM and XSLT на (developerWorks, март 2001)



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-документа.



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 не делает ничего, но для большинства разборов, которые вы будете делать, это, возможно, то, что нужно.



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


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

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



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


Элементы 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-браузеров будут принимать обе.



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


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

XML упрощает обмен данными. Поскольку разные организации (или даже разные части одной организации) редко используют единый стандартизированный набор инструментов, для приложений соединение может требовать некоторого объема работы. При использовании XML каждая группа создает свою утилиту, которая преобразует ее внутренние форматы данных в XML и наоборот. Лучше всего, если производители программного обеспечения уже обеспечили инструменты для преобразования из записей базы данных (или каталогов LDAP, или заказов на покупки и т.д.) в и из XML. XML создает возможность изящного кода. Поскольку XML-документы могут быть структурированы для идентификации каждой важной части информации (а также и отношений между частями), возможно написать код, который может обрабатывать эти XML-документы без участия человека. То, что производители программного обеспечения вкладывают большие объемы времени и денег в построение средств разработки XML, означает, что написание такого кода - относительно простой процесс. XML создает возможность "умного" поиска. Хотя поисковые машины с годами неуклонно совершенствуются, все еще трудно получить результаты поиска без ошибок. Если вы ищете страницы HTML для чего-то, под названием "Chip", вы можете найти страницы про шоколадные плитки (chocolate chips), компьютерные чипы (computer chips), древесно-стружечные плиты (wood chips) и много других бесполезных образцов. Поиск XML-документов по элементам <first-name>, которые содержат текст Chip, даст вам значительно лучший набор результатов.

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



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


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

Будет ли ваше приложение написано на Java? JAXP работает с DOM, SAX и JDOM; если вы будете писать код на Java, вы должны использовать JAXP, чтобы изолировать ваш код от подробностей реализации различных парсеров. Как ваше приложение будет разворачиваться? Если вы собираетесь разворачивать ваше приложение как аплет Java и хотите минимизировать объем выгружаемого кода, имейте в виду, что парсеры SAX меньше, чем парсеры DOM. Также помните, что использование JDOM требует очень маленького объема кода в дополнение к парсеру SAX или DOM. После того, как вы разобрали XML-документ, нужно ли вам будет обращаться к данным много раз? Если вам нужно возвращаться к разобранной версии XML-файла, возможно, DOM является правильным вариантом. Когда генерируется событие SAX, то от вас (разработчика) зависит сохранение чего-либо, что может понадобиться позже. Если вам нужно обратиться к событию, которое вы не сохранили, вам придется разобрать файл заново. DOM сохраняет все данные автоматически. Не нужно ли вам всего несколько вещей из источника XML? Если вам нужно всего несколько вещей из источника XML, возможно, SAX является правильным вариантом. SAX не создает объектов для всего в исходном документе, вы можете сами решить, что является важным. При помощи SAX, вы можете просматривать каждое событие и определять, относится ли оно к тому, что вам нужно, и соответствующим образом его обрабатывать. Даже лучше, если вы нашли то, что искали, ваш код может сгенерировать исключение, чтобы остановить и парсер SAX. Работаете ли вы на машине с очень маленькой памятью? Если так, SAX является наилучшим для вас вариантом, хотя вы можете рассмотреть и все другие факторы.

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



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


Вы не можете опускать какие-либо закрывающие теги. В первом примере, приведенном выше, разметка неправильна потому, что нет закрывающего тега параграфа (</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 должен содержаться в единственном элементе. Этот единственный элемент называется корневым элементом и содержит весь текст и любые другие элементы документа. В следующем примере 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. Если разработчик определил правила для документа, которые могут содержаться в DTD или в схеме, и документ не следует этим правилам, такой документ также является неправильным. ( См. введение в DTD и схемы для XML-документов в Определение содержимого документа.) Правильные документы следуют синтаксическим правилам XML и правилам, определенным в их DTD или в схеме. Правильно-форматированные документы следуют синтаксическим правилам XML, но не имеют DTD или в схемы.



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


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

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

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



Об авторе


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



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


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



Объявления 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-объявлениях.



Обработка HTML


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

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

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



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


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

Одним методом является использование Document Type Definition или DTD (Определение Типа Документа). DTD определяет элементы, которые могут появляться в XML-документе, порядок, в котором они могут появляться, как они могут быть вложены друг в друга и другие основные детали структуры XML-документа. DTD являются частью исходной спецификации XML и они очень похожи на DTD в SGML. Другим методом является использование XML Schema (схема XML). Схема может определить все то в структуре документа, что вы можете поместить в DTD, и может также определить типы данных и более сложные правила, чем DTD. W3C разработала спецификацию XML Schema через пару лет после исходной спецификации XML.



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


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

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



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


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



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


Этот вводный учебник не слишком вдается в подробности о том, как работают 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 при помощи элемента <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-документ.



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


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


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



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


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

Решите, какие данные вы хотите преобразовать в XML. Обычно это те данные, которые нужно перемещать из одной системы в другую или данные, которые должны быть преобразованы в разные форматы. Посмотрите, не ли уже существующих стандартов XML. Если вы ищите весьма общие данные, такие, как заказы на покупки, медицинские записи или расход сырья, имеются хороший шанс найти уже определенный для этих данных стандарт XML. Посмотрите, поддерживают ли ваши существующие инструменты XML. Если вы используете последние версии пакетов СУБД, табличных процессоров или каких-то других инструментов управления данными, то, похоже, ваши существующие инструменты (или их модификации) могут использовать XML как формат входных и выходных данных. Изучите, как строятся приложения на базе XML. Вам нужно понимать, как хранятся ваши данные сейчас, как их нужно преобразовать и как интегрировать ваши усилия в разработке XML с вашими существующими приложениями. Колонка Benoit Marchal Working XML является хорошим местом для начала, вы можете найти текущий список его колонок на . Присоединитесь к соответствующей группе стандартов. Рассмотрите возможность присоединения к группам, таким, как World-Wide Web Consortium (W3C), а также к группам отраслевых стандартов, таким, как HR-XML.org. Членство в группах поможет вам следить за тем, что происходит в отрасли, и дает вам шанс повлиять на будущее стандартов XML. Избегайте нестандартных ухищрений. Важно, чтобы вы в своих действиях по разработке использовали только технологии, базирующиеся на стандартах, сопротивляйтесь предложениям производителей, которые предлагают так называемые усовершенствования для вас. Одно из преимуществ XML - то, что вы имеете полный контроль над вашими данными. Если же вы становитесь заложником нестандартного формата данных, вы теряете значительную часть контроля. Свяжитесь с командой jStart. Если вы считаете, что ваше предприятие может работать по модели соглашения jStart, свяжитесь с командой, чтобы увидеть, что можно сделать. Оставайтесь на связи с developerWorks. Наша XML-зона содержит тысячи страниц информации, посвященных различным темам XML, включая разработку DTD и схем, XML-программирование и создание таблиц стилей XSLT.



схемы 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 вы можете назначить некоторое значение тегам в документе. Что еще более важно, эту информацию также легко обработать для машины. Вы можете выделить почтовый код из этого документа просто найдя содержимое, обрамленное тегами <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 имеет грандиозный потенциал для того, чтобы революционизировать способы работы электронного бизнеса. А поскольку потенциал большой, мы имеем реальные результаты на рынке. В этом разделе обсуждаются три практических примера, в которых организации использовали XML для усовершенствования своих бизнес-процессов и улучшения их результатов.

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

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



Проблемы DOM


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

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

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

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



Проблемы SAX


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

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



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


Мощность 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 или схему, он просто использует этот текст как строку. Это несколько сбивает с толку, но именно так работают пространства имен.



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



Рисунок 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-команда имеет большую гибкость в разработке новых интерфейсов и методов доступа. Самое лучшее, что системы на стороне сервера не изменились вообще.



SAX, JDOM и JAXP


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

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

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

Вы найдете все, что известно о JAXP на .



Схемы XML


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

Схемы XML используют синтаксис XML. Другими словами, схема XML является XML-документом. Это означает, что вы можете обрабатывать схему так же, как и любой другой документ. Например, вы можете написать таблицу стилей XSLT, которая преобразует схему XML Web-форму вместе с автоматической генерацией кода JavaScript, который будет проверять данные по мере их ввода. Схемы XML поддерживают типы данных. Хотя DTD выполняет поддержку типов данных, оно рассматривает эти типы данных только с точки зрения публикации. Схемы XML поддерживают все исходные типы данных DTD (такие, как ID и ссылки ID). Они также поддерживают целые и вещественные числа, даты и времена, строки, URL и другие типы данных, полезные для обработки и проверки данных. Схемы XML являются расширяемыми. Кроме типов данных, определенных в спецификации XML schema, вы можете также создавать собственные типы и можете создавать типы-наследники на базе других типов данных. Схемы XML имеют более мощные выражения. Например, при помощи схем XML вы можете определить, что любое значение атрибута <state> не может быть длиннее двух символов или что любое значение элемента <postal-code> должно соответствовать регулярному выражению [0-9]{5}(-[0-9]{4})?.

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



Simple API for XML


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

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

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



Символы в DTD


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

<!ELEMENT address (name, city, state)>

Элемент <address> должен содержать элементы <name>, <city> и <state> в таком порядке. Все элементы являются обязательными. Запятая показывает список элементов.

<!ELEMENT name (title?, first-name, last-name)>

Это означает, что элемент <name> содержит необязательный элемент <title>, за которым следуют обязательные элементы <first-name> и <last-name>. Знак вопроса показывает, что элемент является необязательным; он может появляться один раз или не появляться вообще.

<!ELEMENT addressbook (address+)>

Элемент <addressbook> содержит один или более элементов <address>. Вы можете иметь столько элементов <address>, сколько вам нужно, но должен присутствовать хотя бы один. Знак плюс показывает, что элемент появляется хотя бы один раз, но может появляться и сколько угодно раз.

<!ELEMENT private-addresses (address*)>

Элемент <private-addresses> содержит ноль или более элементов <address>. Звездочка показывает, что элемент может появляться сколько угодно раз, включая ноль.

<!ELEMENT name (title?, first-name, (middle-initial | middle-name)?, last-name)>

Элемент <name> содержит необязательный элемент <title>, за которым следует элемент <first-name>, за которым, возможно следует элемент <middle-initial> или элемент <middle-name> , за которым следует элемент <last-name>. Другими словами, оба элемента <middle-initial> и <middle-name> являются необязательными, и вы можете иметь только один из этих двух. Вертикальная черта показывает список вариантов; вы можете выбрать только один элемент из списка. Также заметьте, что этот пример использует скобки для группирования определенных элементов и он использует знак вопроса применительно к группе. <!ELEMENT name ((title?, first-name, last-name) | (surname, mothers-name, given-name))>

Элемент <name> может содержать одну из двух последовательностей. Необязательный <title>, за которым следуют <first-name> и <last-name>; или <surname>, <mothers-name> и <given-name>.



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


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

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



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


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

XLink, XML Linking Language, определяет различные способы связать вместе различные ресурсы. Вы можете делать обычные связи точка-в-точку (как в элементе HTML <a>) или расширенные связи, которые могут включать в себя множественные связи, связи через третьи точки и правила, которые определяют, что означает следование по данной связи. Стандарт XLink находится на . XPointer, XML Pointer Language, использует XPath как способ ссылаться на другие ресурсы. Он также включает в себя некоторые расширения XPath. Вы найдете эту спецификацию на .



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


Есть три общих термина, используемых для описания частей 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>

Тег - это текст между левой угловой скобкой (<) и правой угловой скобкой (>). Есть начальные теги (такие, как <name>) и конечные теги (такие, как </name>) Элементом является начальный тег, конечный тег и все, что есть между ними. В примере выше элемент <name> содержит два дочерних элемента: <title>, <first-name> и <last-name>. Атрибут - это пара имя-значение внутри начального тега элемента. В данном примере state является атрибутом элемента <city>; в предыдущем примере <state> был элементом. (См. Пример документа XML).



XML или Extensible Markup Language


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.


Web-сервисы


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

SOAP: Исходный Simple Object Access Protocol, SOAP определяет формат XML-документа, который описывает, как вызвать метод на удаленной части кода. Мое приложение создает XML-документ, который описывает метод, вызываемый мною, передавая ему все необходимые параметры, а затем оно посылает этот XML-документ по сети в эту часть кода. Код получает XML-документ, интерпретирует его, вызывает метод, запрошенный мною, а затем посылает назад XML-документ, описывающий результаты. Версия 1.1 спецификации SOAP находится на . Посетите , чтобы познакомиться с деятельностью W3C, связанной с SOAP. WSDL: Web Services Description Language - это словарь XML, который описывает Web-сервисы. Есть возможность написать код, который принимает документ WSDL и вызывает Web-сервис, который никогда раньше не видел. Информация в файле WSDL определяет имя Web-сервиса, имена его методов, аргументы этих методов и другие подробности. Вы можете найти последнюю спецификацию WSDL на (без закрывающей косой черты). UDDI: Протокол Universal Description, Discovery, and Integration определяет интерфейс SOAP для реестра Web-сервисов. Если вы имеете код, который вы хотите развернуть как Web-сервис, спецификация UDDI определяет, как добавить описание вашего сервиса в реестр. Если вы ищете код, который обеспечивает определенную функцию, спецификация UDDI определяет, как запросить реестр, чтобы найти то, что вы хотите. Источником всего, связанного с UDDI является .



XML Schema


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

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

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



XSL, XSLT и XPath


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

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

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



Зачем нам нужен 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-документ в браузере, вы и я можем понять, что это чей-то почтовый адрес. (В частности, это почтовый адрес в Соединенных Штатах; даже если вы незнакомы с компонентами почтового адреса в США, вы, возможно, догадаетесь, что здесь представлено.)

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



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


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

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