«Золотая лихорадка» XML

Рoмантика золотой лихорадки, похоже, не утрачивает своей привлекательности и в наше, более чем прагматичное время. Все так же столбятся участки, все так же в цене умение быстро "вытащить кольт" (предъявить судебный иск или скупить "на корню"). Конкретность этого процесса разительно контрастирует с абстрактностью "золота", ради которого затеяна жестокая битва, — несмотря на то что информация "залегает" повсюду, разведать ее запасы, добыть и продать — катастрофически трудно. И, в соответствии с канонами жанра (ну как же, золотоискатели бывают только в вестернах), количество жертв растет на глазах: e-компании рушатся, едва успев выбросить на рынок свои акции…

Это невеселое, но зрелищное и динамичное представление неразрывно связано с предметом данной статьи. Действительно, XML сегодня играет роль волшебного талисмана, по сходной цене предлагаемого предприимчивыми людьми падким до e-золота e-старателям. Талисмана, без которого золота вообще никогда не найти. Доказательства? Более 2,5 млн. ссылок на Web-страницы, содержащие ключевое слово "XML", находятся в Сети разными поисковыми машинами (AltaVista, Google, Yahoo…). И почти 2 млн. из них содержат и ключевые слова "e-business" или "e-commerce".

Тернист путь познания

Человеку, посвятившему несколько месяцев изучению XML, весь этот продолжительный процесс может показаться мучительной попыткой плавания в густом киселе — и утонуть трудно, и доплыть непросто. Судя по пресс-релизам и статьям с типовыми названиями "Why XML" ("Почему XML"), она является "ключевой технологией, позволяющей решить основные проблемы интеграции и построения гибких Web-приложений…", "дающей Web-базированным приложениям такие мощь и гибкость, что это открывает непревзойденные возможности перед разработчиками и пользователями". Для самых отъявленных скептиков есть более детальные пояснения: XML позволяет сделать поиск в Web более информативным (meaningful), интегрировать данные от различных источников и приложений, упростить локальные операции и осуществить согласование между одним представлением данных и множеством запросов к нему со стороны потенциальных пользователей (multiple views), улучшить "гранулярные обновления" ПО, увеличить масштабируемость и компрессию информации, распространяемой в Web…

Естественно, что самым удобным для автора было бы просто увеличить и без того не поддающийся исчислению сонм подобных "объяснений" (переведенных с сайтов ведущих идеологов XML), привести в качестве примера фрагмент XML-описания "ну очень важного документа", перечислить несколько доступных программ для работы с XML, да и дело с концом. Но, увы, такой простой и изящно салонной беседы у нас с вами не получится. И вот почему: стандарту XML 1.0 уже два года. Консорциум W3C полным ходом ведет работу над его следующей версией. А "плавание через кисельное море" к золотым e-берегам продолжается: конференция XML 2000 открывается докладом "Getting started with XML" (что-то вроде "XML для начинающих"), главное событие этого e-года (конференция XML-разработчиков "XML DevCon 2000") также начинается "Введением в XML" ("Introduction to XML"). На фоне этакого познавательного характера конференций разработчиков распространяемые консорциумом W3C документы с названиями "Четыре мифа об XML" кажутся уже симптоматичными. Ну и, наконец, последнее — реальное использование XML даже в Web-применениях оставляет желать лучшего (точнее, его почти не наблюдается).

Когда не видно деревьев

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

Когда речь заходит о любом формальном представлении некоторых объектов, обладающих структурой, математический аппарат теории графов является претендентом # 1 на роль главного инструмента. Слава Богу, что для ознакомления с необходимым минимумом этой теории не требуется слишком серьезных математических знаний: граф — это "всего-лишь" некоторое подмножество произведения двух множеств (тавтологии в математике не избежать). Под "произведением" в этом определении понимается так называемое декартово произведение, т. е. множество, образованное всеми парами элементов множителей.

Например, для множеств V = itc_drupal_a, b, c и W = itc_drupal_i, j, k результирующее декартово произведение

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

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

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

Языки, деревья, машины

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

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

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

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

Как видно из этого примера, разрыв между формально правильным (т. е. распознаваемым машиной) синтаксисом и имеющей смысл семантикой бесконечен. Но важность БНФ от этого не становится меньше — ведь описание на метаязыке используется не только при создании нового языка, но и для распознавания пригодных к "пониманию" высказываний этого языка. Такая процедура "понимания" называется грамматическим разбором, а результатом ее обычно является… дерево разбора, восстанавливающее структуру предложения в соответствии с грамматикой.

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

Звездам несть числа…

Разумный вопрос, возникающий при осознании одновременной семантической ограниченности при относительной простоте формализации синтаксиса компьютерных языков, — о чем это говорит рядовому разработчику (программисту) или пользователю? Ну, во-первых, лишних знаний не бывает, во-вторых… Именно этот факт привел к тому, что в сегодняшней информационной индустрии используется более 1700 специализированных языков, обеспечивающих обмен формализованной информацией в 700 прикладных областях. Кроме того, четкое понимание пропасти (gap), разделяющей синтаксис и семантику языков, подсказывает, что языковая оболочка, предназначенная для описания некоторых объектов, состоит из двух практически независимых частей, одна из которых отвечает за удобство правильного синтаксического описания объекта, вторая — за представление функциональности этого объекта (вот почему не бывает языков "всего" — даже если мы используем порождающую бесконечное количество описаний грамматику, создание программы с бесконечной функциональностью кажется весьма проблематичным).

Вдумчивый читатель наверняка догадался и об еще одной стороне этой медали — несмотря на то что синтаксис некоторого языка может быть любым (лишь бы допускал описание с помощью одной из известных грамматик), существует очень трудноуловимая в теории, но прекрасно ощущаемая на практике зависимость между эффективностью применения этого языка и соответствием его синтаксиса семантике. Любящие побаловаться программисты хорошо знают созданные как будто специально для подтверждения этого высказывания языки (Befunge и BrainF*), да и невысокая популярность "чистых" математических языков в реальных проектах свидетельствует только в пользу его справедливости. Отсюда следует один единственный, но крайне важный вывод: существование если не всех 1700 языков, то значительного их подмножества в какой-то мере оправдано — это действительно удачные и нужные разработки.

Языки разметки — немного истории

Этот класс языков занимает главные позиции в области моделирования одного обширного класса объектов, размыто именуемых понятием "документ". "Документ вообще" — абстракция слишком высокого уровня, и, вероятно, поэтому первая попытка создать "вообще язык" для "документов вообще" породила монстра — SGML. Опубликованный в 1986 г. стандарт ISO 8879 на язык SGML только в части описания синтаксиса занимал более 500 страниц. И неудивительно, в 1986 г. ISO-стандартизации SGML предшествовала фактически 30-летняя история. В шестидесятых годах дизайнер, специализирующийся на оформлении книг, Стэнли Райс (Stanley Rice) предложил идею универсального каталога параметризованных меток для "редакторской структуры" книги. Плодотворную идею подхватил Норман Шарф (Norman Scharpf), директор влиятельной тогда организации с любопытным названием Ассоциация графических коммуникаций (Graphic Communications Associations — GCA), и незамедлительно организовал программный проект, целями которого было создание средств описания структуры и оформления документа, максимально отделенных друг от друга. В начале семидесятых в GCA была создана концепция GenCode, в которой утверждалось, что для описания структуры документа требуется определенный класс специальных кодов, не пересекающийся с классом кодов, определяющих представление документа.

Приблизительно в это же время в IBM начали исследовательский проект интегрированной информационной системы для адвокатских контор. В его рамках под руководством Чарльза Голдфарба (Charles Goldfarb) был изобретен GML — Generalized Markup Language, ориентированный на редактирование, форматирование и совместное использование документов. Главной особенностью GML был формальный синтаксис, допускающий проверку правильности разметки документа и очень близкий к современным языкам SGML-семейств. На основе GML IBM была создана издательская система промышленного уровня для мэйнфреймов, получившая в свое время заслуженное признание.

e-фокус XML

Разметка (markup), несмотря на общность понятия, заключается в определении структуры. Самый распространенный на сегодняшний день язык разметки — HTML — ограничивает перечень возможных структур документов комбинациями встроенных в язык конструкций (тегов) — заголовком документа (<HEAD>), его телом (<BODY>), заголовками шести уровней (<H1>…<H6>), списками (неупорядоченными, упорядоченными и определениями), таблицами, фреймами и формами. Для разделения структурной разметки от форматирования используются CSS — каскадные таблицы стилей. В идеале любая HTML-страница, встречающаяся в Сети, должна содержать хорошо структурированный документ, форматирование которого полностью отделено от описания структуры (на практике, увы, создатели большинства Web-страниц этим правилом пренебрегают для достижения большего визуального эффекта).

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

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

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

Каждый представленный таким образом элемент определяет важнейшую синтаксическую конструкцию — теговую пару (в приведенном в качестве примера случае — <КНИГА>,</КНИГА> и <ГЛАВА>,</ГЛАВА>). Теперь мы имеем "новые" языковые конструкции, представляющие собой контейнеры, — после грамматического разбора ограниченные этими элементами объекты (например, текст и другие, вложенные, контейнеры) будут идентифицированы как принадлежащие к данному классу.

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

А вот теперь настало время вспомнить о графах и деревьях. Вооружитесь карандашом и попробуйте изобразить приведенный выше "документ" в виде графа, вершины которого соответствуют открывающим тегам контейнеров, а соединяющие линии условно обозначают слово "содержит" (подсказка — начните с <КНИГА> и заметьте, что "<КНИГА> содержит <АВТОР>"). Если у вас получилось, то нарисованный граф является деревом. Более того, для XML (как и для HTML и практически всех языков разметки) любой правильно размеченный документ представляется графом. Собственно говоря, на этом синтаксические возможности по описанию структуры с помощью языков разметки заканчиваются. Фактически же этот синтаксический фокус означает одно — вы вводите новые имена для вершин дерева. Все, не больше и не меньше.

А семантика — это уже не по части языков разметки, так что реализация кода, как-либо оперирующего определенным содержанием ваших "принципиально новых" контейнеров — личное дело каждого, становящееся куда более увлекательным, когда вы сталкиваетесь с определенным кем-то DTD. Вопрос "Что значит <!ELEMENT NcatBsQ235 #REQUIRED>" может поставить в тупик любого XML-гуру, потому как ответ на него заключается вовсе не в знании XML, а зависит от предметной области, для которой DTD разрабатывался.

И вот здесь напрашивается совершенно очевидный вопрос: если синтаксис языка все-таки должен быть хоть в какой-то мере согласован с его семантикой, если существует мощная теоретическая, алгоритмическая и программная база формальных языков, допускающих автоматическую трансляцию в древовидные структуры (деревья разбора), то все-таки, "Why XML"?

"Матрешки"

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

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

Панацеи нет

По мнению ученых из Bell Labs, "XML — это не окончание наших проблем. Это только начало". Являющийся по сути языком описания древовидных структур с расширяемым пространством имен XML оставляет открытой проблему реализации семантической поддержки (того, что мы называем программами) для каждого нового семейства имен. В этом заключается главная слабость самой концепции, лежащей в основе языка. Данную проблему если не устраняют, то переводят в другой класс программы—конверторы XML-документов в объекты Java или иных интерпретируемых языков программирования (существует даже мнение, высказываемое очень уважаемыми в IT-индустрии персонами, о том, что "XML — это единственная возможность реализовать потенциал Java").

Такая, на первый взгляд резкая, формулировка убедительно подтверждается крайне неудачными примерами "перспективного применения XML", часто встречающимися в учебниках. Так, XML-решение ставшей уже канонической задачки об объединении двух хранилищ данных разных компаний, после малейшего приложения умственных усилий выглядит далеко не так симпатично, как хотелось бы. Идея принципиально проста — специалисты обеих фирм создают XML-описания форматов записей, предназначенных для обмена, и на основе программы разбора XML (парсера) строят "шлюз данных". Все вроде бы очень красиво, кроме… Если известны форматы данных (A и B) компаний, то зачем нужна промежуточная и очень сложная прослойка, когда можно разработать программу преобразования A<->B непосредственно? Сторонники XML утверждают, что в таком случае при изменении формата A придется переписывать программу, а при XML-реализации достаточно изменить только, например, DTD и XML-описания. Тем, кто безоговорочно верит таким "ультра-" заявлениям, следует сразу вспомнить об отсутствии какой-либо семантической поддержки в любом языке разметки, в том числе и XML. Так что изменять программы придется и во втором варианте. Что проще — вопрос технологии и квалификации разработчиков.

Крайне неприятна и потенциальная угроза сегментации Internet в случае массового перехода в Web на XML (к слову, несмотря на почтительный по Internet-меркам возраст, наступления XML в ближайшее время не предвидится). Так как новые имена в XML, с одной стороны, очень легко создавать, а с другой — для них слишком сложно реализовывать программную поддержку, вполне возможна угроза монополизации Internet "от броузера". Кроме того, выбор самих имен остается на совести разработчика — и кто сможет гарантировать, что в 2005 г. ваш любимый броузер будет понимать тег <1Zdfq895sxcXX3>, без которого "ну никуда". Единственный спасательный круг — подгружаемые из сети апплет-реализации семантической поддержки "новых" тегов — вообще грозит полным обвалом самых совершенных систем безопасности.

Так что, прислушиваясь к шумихе вокруг XML, не вредно вспомнить недавнюю шумиху вокруг Java. И та и другая технология не являются панацеей и хороши там, где они действительно хороши. Но не более того.