XML: время пришло

Джонатан Эйнджел
LAN/ЖУРНАЛ СЕТЕВЫХ РЕШЕНИЙ #11/99

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

Если вы являетесь разработчиком для Web, то вам приходится иметь дело со множеством технологий — подключаемые модули Netscape, элементы управления ActiveX, Dynamic HTML, Cascading Style Sheets (CSS) и т. д. — для расширения, как утверждается, возможностей ваших страниц. В немногих случаях вы действительно получали обещанное, но в основном эти технологии только серьезно усложняли вам жизнь из-за их несогласованного поведения в разных браузерах.

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

Однако расширяемый язык разметки (Extensible Markup Language, XML) — это совсем иное дело. Хотя, как и любая новая технология, он требует освоения, это не должно вызывать у вас мигрень. XML пришел всерьез и надолго. Главное же, он должен сделать вашу жизнь легче, а не тяжелее.

Наиболее важная особенность XML и сопутствующей ему технологии расширяемого языка таблицы стилей (Extensible Stylesheet Language, XSL) состоит в отделении форматирования от информационного наполнения. Это может показаться знакомым всем, кому приходилось работать с CSS или таблицами стилей в Microsoft Word. Однако если стандартный HTML уподобить фотоснимку здания, то CSS будут соответствовать инструкциям для фотолаборатории о том, как следует обрабатывать фотографию. Все двери можно сделать красными, все стены — розовыми, а крышу — серой. Однако без доступа к светокопии здания никаких фундаментальных изменений внести нельзя. XML, в отличие от HTML, позволяет экспонировать данные и манипулировать ими.

HTML В КОНЦЕ ПУТИ

Всю красоту XML можно понять только при сравнении его с HTML. Формализованный в RFC 1866 в 1995 году (хотя, естественно, использоваться он начал раньше), HTML является наиболее популярным языком разметки во всем мире. Термин «разметка» применительно к документу означает обычно все, что не относится к его информационному наполнению. Например, когда эта статья готовилась к печати, редакторы Network Magazine размечали ее (с помощью старой доброй «аналоговой» красной авторучки), вставляя замечания для автора и инструкции для верстальщиков о том, как следует форматировать различные элементы.

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

Главной особенностью разметки HTML является, конечно, возможность вставки ссылок на внешние документы или на внутренние разделы того же самого документа. Стоит заметить, что, хотя HTML чаще всего предоставляется серверами по HTTP, он также может использоваться на CD-ROM или в локальной сети. Универсальные языки разметки не привязаны к какому-либо конкретному транспорту.

HTML преуспел не только как адаптируемый язык разметки, но и в качестве промежуточного программного обеспечения (см. статью Д. Эйнджела «Промежуточное программное обеспечение» в этом номере LAN). Благодаря своей дешевизне и распространенности браузеры Web представляют собой отличных клиентов; при посредничестве HTML они могут общаться с самыми разнообразными серверами.

Однако HTML столкнулся с определенными трудностями. Его ограниченные возможности форматирования пытались преодолеть с помощью CSS, инициативы TrueDoc от Bitstream и конечно же множества специфических расширений для браузера; а его ограниченные возможности в качестве промежуточного ПО — с помощью Java, ActiveX и т. п. Тем не менее все это не устраняет его фундаментальные недостатки.

ТО, ЧТО ВЫ ВИДИТЕ, — ЭТО ВСЕ, ЧТО ВЫ ПОЛУЧАЕТЕ

По сути, HTML — это технология представления информации, он описывает то, как браузер должен скомпоновать текст и график на странице. В результате «то, что вы видите, — это все, что вы получаете». Нет никакого способа описать данные независимо от отображения этих данных (за исключением чрезвычайно слабой системы ключевых слов в заголовке страницы Web). Это главная причина, почему так трудно найти нужную информацию с помощью механизма поиска.

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

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

Другая проблема с HTML в том, что это «плоский» язык, т. е. авторы не могут использовать его для предоставления информации об иерархии данных. Далее, он непоследователен и поэтому затрудняет разбор текста программным обеспечением. Например, хотя большинство открывающих тегов (такие, как <B> или <H1>) имеет соответствующие закрывающие теги, некоторые (например, <P>) их не имеют.

Простым решением для некоторых из перечисленных проблем было бы введение дополнительных тегов HTML, таких, как <NAME>, <DATE> или <PRICE>. С их помощью клиент мог бы определить, что собой представляют данные, и отображать их по-разному или экспортировать по запросу пользователя. История, однако, показывает, что введение дополнительных тегов для HTML может занять годы; консенсуса по поводу того, что они должны значить, редко когда удается достичь быстро, если он вообще возможен. Если же вы решите не дожидаться изменения стандарта, то имейте в виду, что вы создаете нечто свое, нестандартное и тем самым отказываетесь от одного из главных преимуществ HTML.

Поэтому в 1996 году члены рабочей группы Консорциума World Wide Web (W3C, http://www.w3.org) вернулись к рассмотрению стандартного обобщенного языка разметки (Standard Generalized Markup Language, SGML), сильно упрощенным потомком которого является HTML. Предложенный в 1974 году Чарльзом Голдфарбом, SGML представляет собой метаязык — систему для описания других языков. При всех своих возможностях он слишком сложен для большинства браузеров Web: одна спецификация SGML занимает свыше 500 страниц.

Упростив SGML для использования с Web, группа предложила XML (рекомендация W3C по статусу на февраль 1998 года). XML представляет собой подмножество SGML, причем любой действительный документ XML является действительным документом SGML. И, как и SGML, XML — это метаязык, определяющий другие языки разметки для специфических целей. Например, язык синхронизированной интеграции мультимедиа (Synchronized Multimedia Integration Language, SMIL) базируется на XML.

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

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

НАЗЫВАТЬ ВЕЩИ СВОИМИ ИМЕНАМИ

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

Вот фрагмент HTML:

<H1>Еditor Сontacts</H1>
<H2>Имя: Джонатан Эйнджел</H2>
<P>Должность: старший редактор</P>
<P>Издание: Network Magazine</P>
<P>Улица и дом: Гариссона, 600 </P>
<P>Город: Сан-Франциско</P>
<P>Штат: Калифорния</P>
<P>Индекс: 94107</P>
<P>Электронная почта: 
jangel@mfi.com</P>

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

В случае XML тот же самый фрагмент будет представлен следующим образом (и сохранен в файле EDITORS.XML).

<?xml version = “1.0” ?>
<editor_contacts>
  <editor>
    <first_name>Джонатан</first_name>
    <last_name>Эйнджел</last_name>
    <title>старший редактор</title>
    <publication>Network 
    Magazine</publication>
    <adress>
      <street>Гариссона, 600 </street>
      <city>Сан-Франциско</city>
      <state>Калифорния</state>
      <zip>94107</zip>
    </address>
    <e_mail>jangel@mfi.com</e_mail>
  </editor>
</editor_contacts>

XML, лишь несколько более «многословный», чем HTML, намного упрощает определение того, что собой представляют и где находятся поля данных. В XML теги не могут накладываться, как в HTML (что не поощряется, но допускается большинством программ разбора HTML). Однако они могут быть вложены в друг друга. На самом деле, вложение даже поощряется как способ создания иерархии данных (подчиненные или равноправные отношения). Как видно из приведенного примера, такие элементы, как <first_name> и <e_mail>, содержат данные, в то время как другие (<address>) присутствуют только в целях структурирования.

Теги начала и конца элемента являются основными используемыми в XML разметками, но ими дело не исчерпывается. Например, элементам могут быть присвоены атрибуты. Эта возможность аналогична имеющейся в HTML, где, например, элементу <table> может быть присвоен атрибут align=”center”. В XML элемент может иметь один или более связанных с ним атрибутов, причем при составлении документа вы можете выдумать их столько, сколько пожелаете, например <publication topic=”networking” circulation=”controlled”>.

Документы XML могут содержать ссылки на другие объекты. Ссылки представляют собой строку, начинающуюся с амперсанта и заканчивающуюся точкой с запятой. Эти ссылки позволяют, в частности, вставить в документ специальные символы, включение которых самих по себе могло бы сбить с толку программу разбора. Например, чтобы поместить в документ знак «меньше, чем» (<) вы должны вставить ссылку <, а чтобы вставить сам амперсант — ссылку &, и т. д. До сих пор все так же, как и в HTML. Однако ссылки XML на объекты предоставляют гораздо больше возможностей, так как они могут ссылаться на определенные автором разделы текста в том же самом или в другом документе.

Например, ссылки на объекты позволяют применить объектно-ориентированный подход при создании журнальной статьи:

<article>
&introduction;
&body;
&sidebar;
&conclusion;
&resources;
</article>

Другими видами разметки XML являются комментарии (они выделяются точно так же, как в HTML) и инструкции по обработке. Инструкциям по обработке предшествует знак вопроса. Они описывают, что именно программа разбора должна использовать для интерпретации конкретного документа или его раздела. Например, инструкция <?xml version = 1.0”?> сообщает программе разбора XML, что обрабатываемый документ действительно составлен с помощью XML. С другой стороны, инструкция <?rtf \page?> служит для вызова программы разбора RTF и вставки символа конца страницы.

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

<![CDATA[

Этот текст, даже если он содержит элементы кода HTML, такие, как <B>жирныйшрифт</B> или <H1>заголовок</H1>, не подвергается грамматическому разбору. Вместо этого он отображается как есть.

]]>

ТАБЛИЦЫ СТИЛЕЙ

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

Ответ лежит в использовании таблиц стилей. Пользующиеся умеренной популярностью в Web каскадируемые таблицы стилей (Cascading Style Sheet, CSS) позволяют изменять форматирование известных тегов HTML и определять новые теги. В частности, на Web-сервере Network Magazine таблицы стилей CSS используются для стандартизации представления типичных элементов, таких, как <H1>, и для введения новых, таких, как врезки.

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

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

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

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

<?xml version = “1.0” ?>
<xsl:stylesheet xmlns:xsl=“http://www.w3.org/TR/WD-xsl”>
<!–декларация, что документ является таблицей стилей и что он связан с xsl: namespace –>
<xsl:template match=”/”>
<!–Применить шаблон ко всему в исходном документе XML –>
<HTML>
<BODY>
<H1>Editor Contacts</H1>
<xsl:for-each select=”editor_contacts/editor”>
<H2>Name: <xsl:value-of select=”first_name”>
<xsl:value-of select=”last_name”/></H2>
<P>Title: <xsl:value-of select=“title”/></P>
<P>Publication: <xsl:value-of select=”publication”/></P>
<P>Street Address: <xsl:value-of select=”address/street”/></P>
<P>City: <xsl:value-of select=”address/city”/></P>
<P>State: <xsl:value-of select=”address/state”/></P>
<P>Zip: <xsl:value-of select=”address/zip”/></P>
<P>E-Mail: <xsl:value-of select=”e_mail”/></P>
</xsl:for-each>
</BODY>
</HTML>
</xsl:template>
</xsl:stylesheet>

При сохранении на диск под именем EDITORS.XSL (или любым другим) этот шаблон будет применен к EDITORS.XML при добавлении в него следующей строки после первой:

<?xml-stylesheet
 type=”text/xsl” href=
“editors.xsl” ?>

В конечном итоге текст на экране браузера будет выглядеть точно так же, как представленный ранее фрагмент HTML. Однако XSL может действовать как функция текстового процессора merge-print. Определенный как неотъемлемая часть пространства имен XSL, элемент xsl:for-each сообщает процессору о том, что он должен циклически обрабатывать все узлы в исходном файле XML. Атрибут xsl:value-of вставляет значение узла XML в элемент HTML. Таким образом, если вам придется вернуться к EDITORS.XML и вставить десятки или сотни контактных адресов, то они без каких-либо изменений будут отображаться в таблице стилей. Благодаря тому, что информацию о форматировании требуется передать только один раз, XML и XSL экономят пропускную способность.

Таблицы стилей XSL имитируют функцию merge-print еще и в том, что они позволяют избирательно опускать поля данных при отображении. Кроме того, вывод может быть отсортирован по любому конкретному полю данных. Для сортировки базы данных контактных адресов по фамилии редактора в прямом алфавитном порядке элемент xsl:for-each следует изменить следующим образом:

<xsl:for-each select=
“editor_contacts/editor” 
order-by=”+last_name”>

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

Значительный потенциал XML в качестве промежуточного программного обеспечения подкрепляется объектной моделью документа (Document Object Model, DOM), версия 1.0 которого была принята в качестве рекомендации W3C в октябре 1998 года. DOM возникла как спецификация для обеспечения переносимости сценариев JavaScript и программ на Java между браузерами Web и позднее эволюционировала в API для документов HTML и XML. Она определяет логическую структуру документов, способы доступа и манипулирования ими. Программисты могут создавать документы, управлять их структурой и добавлять, модифицировать или удалять элементы и содержимое.

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

ПРОВОЗГЛАШЕНИЕ СТРУКТУРЫ ДОКУМЕНТА

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

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

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

<!ELEMENT имя_элемента 
(тип_данных)>

Например, декларация определяет элемент с именем publication, содержащий символьные данные (т. е. текст). Декларация определяет элемент с именем special_report, содержащий подэлементы article_1, article_2 и article_3 в указанном порядке, например:

<special_report>
<article_1>XML: 
время пришло</article_1>
<article_2>XML превосходит 
самое себя</article_2>
<article_3>Управление сетями и 
системами с помощью XML</article_3>
</special_report>

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

<!ATTLIST car manufacturer 
(AudiлVolvoлVolkswagen)>

!ATTLIST позволяет управлять атрибутами и многими другими способами: задавать значения по умолчанию, подавлять пробелы и т. д. DTD могут также содержать декларации !ENTITY, где определяются ссылки на объекты, а также декларации !NOTATION, указывающие, что делать с двоичными файлами не в формате XML.

Серьезное и несколько удивительное ограничение DTD состоит в том, что они не допускают типизации данных, т. е. ограничивают данные конкретным форматом (таким, как дата, целое число или число с плавающей точкой). Как вы, вероятно, уже заметили, DTD используют иной синтаксис, нежели XML, и не очень-то интуитивно понятны. По названным причинам DTD будут, видимо, заменены на более мощные и простые в использовании схемы XML, работа над которыми ведется в настоящее время. Дополнительную информацию о схемах XML можно почерпнуть из рабочего проекта, ссылка на который приведена в Таблице, и из врезки «Что в имени твоем?».

Возможно, вам приходилось слышать определения «правильно составленный» (well-formed) и «действительный» (valid) применительно к документам XML. Документ является правильно составленным, если для каждого открывающего тега имеется соответствующий закрывающий тег, а накладывающиеся теги отсутствуют. (Таким образом, большая часть документов HTML составлена неправильно.) Документ является действительным, если он содержит DTD и соответствует его правилам.

XML ПРИСТУПАЕТ К РАБОТЕ

XML будет пользоваться все возрастающей популярностью как открытый и эффективный стандарт для сотрудничества между компаниями и электронной коммерции. Данные XML будут перемещаться преимущественно с помощью HTTP, но они могут также распространяться с помощью технологий организации очередей сообщений, таких, как MQSeries компании IBM или Message Queue Server компании Microsoft.

Однако для того, чтобы это стало возможным, требуется определить и согласованно внедрить специфические схемы. W3C совершенно правильно решил, что он не должен в это вмешиваться; в результате десятки отраслевых организаций по стандартизации занимаются определением XML, DTD и схем. Среди них RosettaNet (ориентированная на поставки в области ИТ — см. подробности на http://www.rosettanet.org), CommerceNet (http://www.commercenet.com), XML/EDI Group (http://www.geocities.com/WallStreet/Floor/5815/), Open Applications Group (http://www.openapplications.org), XML.ORG (http://www.xml.org) и BizTalk (http://www.biztalk.org).

Наибольшее число споров вызывает BizTalk компании Microsoft: сторонники компании рассматривают это как альтруистическую попытку помочь становлению XML, в то время как противники считают это еще одной попыткой подчинить себе отрасль. (Дополнительную информацию о BizTalk читайте в статье «XML превосходит самое себя».)

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

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

XML пришел всерьез и надолго — и он обладает массой достоинств. Кстати, как утверждают в W3C, под маской недавно принятого «бостонского» дополнения к Synchronized Multimedia Integration Language (SMIL), XML может стать ключевым элементом цифрового телевизионного вещания.

Возможно, пока еще рано полностью переделывать свой сервер Web под XML. Однако начинать работать с ним уже пора, тем более что необходимый инструментарий уже имеется. С точки зрения конечного пользователя, Internet Explorer 5.0 компании Microsoft поддерживает XML, XSL, DTD и схемы XML, а Netscape Navigator/Mozilla 5.х будет это делать после своего выхода.

Ресурсы Internet

Если вы хотите быть в курсе событий в области XML, то посетите http://www.xml.com, публикуемый Seybold Publications и O-Reilly.

Что в имени твоем?

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

Обращаясь к популярному примеру с книжным магазином, почти наверняка и Know Knew Books, и Amazon.com будут использовать теги с такими именами, как author (автор), title (название), isdn и price (цена). В то же время маловероятно, что они станут использовать те же самые DTD. Это прямой путь к проблемам.

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

Вот, например, фрагмент кода XML с использованием пространств имен:

<inventory xmlns:storea=
“http://www.knowknew.com/
books.dtd” xmlns:storeb=
“http://www.amazon.com/schema”>
<storea:magazine>
<storea:title>Network 
Magazine</storea:title>
</storea:magazine>
<storeb:magazine>
<storeb:magazine storeb:title=
“Data Communications”>
</storeb:magazine>
</inventory>

В определении DTD магазина А название книги является подэлементом журнала. В схеме магазина Б название является атрибутом журнала.

Благодаря различению имен с помощью разных префиксов пространств имен они могут применяться вместе. Местонахождение DTD и схемы указывается в данном примере с помощью URL, но оно может также определяться с помощью Uniform Resource Name (URN, см. RFC 2141) или Uniform Resource Identifier (URI, см. RFC 2396).