Сегодня, кажется, уже всем объяснили: XML - вот волшебная палочка, с помощью которой будет наведен порядок в хаосе форматов данных. Язык разметки XML - одна из наиболее динамично завоевывающих внимание разработчиков и пользователей Интернет-технологий. Слово "завоевывающая" в предыдущем предложении появилось не случайно, так как реклама XML хотя и менее настойчива, чем реклама сотовых телефонов, но уже переплюнула клинское пиво. Однако до последнего времени реальная польза, как и смысл изучения и использования этой технологии, были сомнительны. Международная организация W3C утвердила спецификацию "Extensible Markup Language(XML) 1.0" еще в начале февраля 1998 года, но только теперь становится ясно, для чего этот самый XML употребить, и каким именно образом.
Дело в том, что сам по себе язык XML ничего особенного не представляет, и никаких задач решить не может. Посудите сами - вам предоставляется замечательная возможность самим определить теги и использовать их по собственному разумению, подчиняясь немногочисленным и несложным правилам. Да, таким образом можно создать структурированный документ или хранить небольшие количества информации, но, во-первых, ничего нового в этом нет, а, во-вторых, результат ваших трудов будет понятен только вам, никакой браузер этот документ понять не сможет. Мало того, поступающая извне информация может включать элементы с такими же названиями, что и использованные вами, но с совершенно другим смыслом и типом данных. Это может легко привести к ошибкам в интерпретации и отображении информации. Таким образом, сам по себе XML дает вам максимум свободы, и никакой возможности этой свободой разумно распорядиться. Еще в Windows 3.х существовал формат ini-файлов, который на порядок примитивнее XML, зато по количеству применений до сих пор его превосходит - потому, что изначально существовал простой и доступный в любой версии Windows API.
К счастью, на сегодняшний день вокруг XML уже создано огромное количество технологий и, если можно так выразиться, различной "оснастки". Все они имеют одну простую и ясную цель - сделать XML применимым в реальных задачах. Поэтому говорить имеет смысл не об XML, а о способах и технологиях его преобразования и использования, таких, как XSL/XSLT, XPath, XDR, XML DOM и так далее.
Пользователь, знающий об XML только по рекламным воплям, может удивиться, но XML можно применять не везде. XML-документы обычно длиннее замещаемых ими бинарных форматов. Они требуют большей полосы пропускания сети, больше места для хранения, и уж точно больших затрат процессорного времени. Разбор XML медленнее, чем разбор оптимизированных бинарных форматов, да к тому же требует больше памяти (особенно если учесть, что бинарные форматы можно сохранять и загружать в виде, пригодном для немедленного использования). Но у XML есть несколько важных достоинств:
Теоретически XML может использоваться в любых приложениях, которым нужна структурированная информация - от сложных систем с гигантскими объемами передаваемой информации до обычных "однокомпьютерных" программ, использующих этот язык для описания или хранения служебной информации. При внимательном взгляде на окружающий нас информационный мир можно выделить множество задач, связанных с созданием и обработкой структурированной информации, для решения которых может использоваться XML:
На практике примеры использования XML не столь многочисленны, поскольку для хранения и обработки больших объемов информации традиционно используются СУБД, более эффективные для этой задачи. Большая же часть Web-сайтов обходится форматом HTML и скриптами, поскольку ни в чем другом не нуждается.
В качестве средства хранения данных XML действительно располагает некоторыми преимуществами перед традиционными РСУБД (впрочем, и множеством недостатков тоже). Скорее всего, отказываясь в свое время от иерархического представления данных, отцы-основатели реляционной модели БД не подозревали, что наступит время, когда такое представление окажется необходимым. Как известно, иерархическая модель была одной из первых моделей БД. Единственной альтернативой ей была сетевая модель. Сетевая модель - это модель графов, как известно, не имеющая высокопроизводительных алгоритмов. Иерархическая же позволяла достаточно легко реализовать производительные СУБД. Когда была предложена реляционная модель, многие поддались на достаточно абстрактные рассуждения о её неоспоримых преимуществах. В качестве главных рекламных лозунгов звучало следующее - полностью систематизированная модель, имеющая хорошее математическое основание и четкие алгоритмы. В отличие от иерархической модели, она гипотетически позволяла стоить модели данных любой сложности, а язык SQL, придуманный специально для этой модели, окончательно определил её победу. Однако ни программист, ни, тем более, нормальный человек не думают понятиями реляционной алгебры. Да и конкретные реализации серверов столкнулись с тем, что красивые и эффективные математические методы не так просто превратить в эффективные и быстрые алгоритмы. Даже сегодня, через несколько десятков лет после появления концепции реляционной модели БД, серверы, обладающие эффективным и быстрым оптимизатором запросов, можно пересчитать по пальцам одной руки. Теперь, с покупкой IBM фирмы Informix, их станет еще меньше. В программировании же незаметно появилась объектно-ориентированная парадигма. Она оказалось удобна в практическом применении, и не требовала сложных алгоритмов обработки. Что перечислять достоинства этого подхода - сейчас почти все средства разработки стали объектно-ориентированными.
Если вдуматься, объектно-ориентированное представление данных является ничем иным, как деревом, но со ссылками на другие объекты. Получается дурацкая ситуация - программист, работая с объектами, данные вынужден по-прежнему хранить в реляционной модели. Несоответствие налицо. Поэтому XML со своим представлением данных, похожим на ООП, подвернулся как нельзя кстати. Усилия, затраченные на проработку концепции данных в XML, привели к тому, что сейчас XML-представление данных превосходит то, что сейчас называют "объектно-ориентированными" и "объектно-реляционными" СУБД. По логике вещей, в ближайшие несколько лет должны появиться СУБД, в качестве представления (но не хранения!) данных использующие парадигму XML.
В качестве преимущества XML можно рассматривать и текстовое представление информации. XML-файл можно редактировать с помощью любого текстового редактора - от Notepad до Emacs. Данные, хранящиеся в виде XML, как правило, доступны для человеческого понимания без преобразования. Это положение в корне отличается от бинарного представления данных, требующего программной трансформации в пригодный для использования человеком вид. Разумеется, хранение информации в текстовом виде более расточительно (как с точки зрения объема, так и по требуемым для обработки ресурсам), чем бинарное. Но зачастую удобство использования стоит затрачиваемых ресурсов. Следует заметить, что XML хранит только данные и элементы, определяющие их структуру. Представление этих данных может быть любым, оно полностью отдается на откуп разработчику (подробнее об этом будет рассказано ниже).
Если же вспомнить эталонный пример внесения мусора в документ - я имею в виду HTML-документы, создаваемые MS Office - то станет ясно, что HTML-документ с помощью несложных ухищрений можно раздуть до размеров двух исходных документов Word. Из-за наличия большого количества форматирования реальное содержание HTML-документа может составлять всего несколько процентов от общего объема документа. В таких условиях сокращение размера документа (особенно с учетом пораженных сложным букетом хворей отечественных линий связи) действительно имеет значение. Кстати, о документах. Структура документов, как правило, достаточно сложна, и их хранение в РСУБД - непростая задача. Многие системы документооборота хранят документы, не разбирая их - в том виде, как они поступили в систему. В то же время практически все документы имеют некоторую объектную структуру, что позволяет хранить их в XML-формате. Причем к таким документам можно применять программные алгоритмы, из них можно выбирать нужную информацию, основываясь на жестких критериях, задаваемых тегами, программно изменять их или конвертировать. У документа появляется функциональность, ранее присущая только программным объектам и СУБД.
Есть и еще один момент, важный для разработчика. Сложное форматирование, неизбежно присутствующее в HTML-документе, может стать препятствием для обмена данными и их программной обработки. Кроме этого, сама структура HTML-документов не слишком подходит для хранения и описания данных, этот язык изначально не планировалось использовать в этих целях, и в нем практически отсутствуют механизмы для этого.
XML же довольно критичен к синтаксису (по сравнению с HTML), но безразличен, когда речь заходит об определении значений элементов в XML-документах. Если HTML - это один словарь, в смысле - набор заранее определенных значений (тег <b> значит одно и то же для любого браузера), то в XML можно либо выбрать готовый словарь из уже существующих, либо создать собственный, наиболее точно соответствующий потребностям вашего предприятия или проекта. Создать и описать такой словарь, или пространство имен XML, позволяют схемы и определения типов документов (DTD - Document Type Definition).
Такой подход требует совершенно другой архитектуры браузеров, чем HTML-браузеры. Разработчик не может полагаться на способность браузера разобраться в смысле разметки и способе ее интерпретации. Современные браузеры могут выводить XML-документы, но как это убого выглядит! Без использования соответствующих шаблонов XSL Transformations (XSLT) такой вариант просмотра годится исключительно для служебных (диагностических или отладочных) целей. Пользователю (тем паче заказчику) этого показывать нельзя.
Кроме этого, как уже говорилось выше, реальное содержание сильно уступает в размерах посылаемому браузеру HTML-документу. Было бы очень здорово передавать клиенту только данные в формате XML, а само форматирование осуществлять уже в браузере! XSLT позволяет сделать это, но пока имеются серьезные проблемы совместимости браузеров.
К сожалению, продвижение XML и связанных с ним технологий не избежало обычных в таком случае перегибов. Практически любую вновь появляющуюся технологию продвигающие ее фирмы и организации стремятся объявить (см. начало статьи) всемогущей панацеей, лечащей всё, включая проблему последней мили и головную боль. Этим грешит практически любая крупная софтверная фирма. Так было с Java, так сейчас обстоят дела с Linux. Но действительность, к сожалению, часто вносит свои коррективы. Все изложенные выше достоинства XML несомненны, но и недостатков хватает.
Сама концепция хранения данных в текстовом виде далеко не универсальна. Прежде всего, далеко не все типы данных можно (и имеет смысл) хранить в текстовом виде. Кроме всего прочего, текстовое представление (мягко говоря) не повышает производительности. При заверениях некоторых вполне уважаемых средств массовой информации в том, что работа через XML, например, с SQL Server, быстрее, чем традиционный обмен бинарными данными, так и хочется спросить - "Как вы измеряли?". Если и впрямь спросить, выясняется, что никак. Переписали пресс-релиз, и успокоились.
XML, как и любое другое средство или технологию, нужно использовать разумно, то есть там, где это действительно необходимо. Например, не стоит бежать переделывать работающее приложение или Web-сайт на XML. Но если вам потребовалось сериализовать какой-то объект или сохранить документ, не стоит изобретать собственный формат и писать не универсальный разбор - проще воспользоваться XML-технологиями.
Рассмотрим некоторые из них.
С точки зрения разработчика, XML-парсеры - это мост между XML-документами, выглядящими как длинные цепочки байтов, и приложениями, обрабатывающими этот XML. Практически все приложения, работающие с XML, построены на базе парсеров.
Парсер отвечает за разбор синтаксиса XML и, если нужно, за проверку соответствия содержания документа правилам и ограничениям, накладываемым DTD или XML-схемой. Приложение должно понимать, как обрабатывать или отображать информацию. Приложение изолировано от деталей XML-документа, а создатели документа могут использовать ненужные приложению детали в своих целях. Создатель документа по-прежнему должен предоставлять приложению корректно структурированную информацию, но это можно делать, используя стандартные средства вместо создания новых интерфейсов для каждой нового действия.
Спецификации XML 1.0 оговаривает, что XML-парсеры могут проверять синтаксис, а могут и не проверять корректность структуры документа. Не следует путать проверку корректности документа с точки зрения XML как такового и проверку корректности документа с точки зрения соответствия DTD или XML-схеме.
Проверяют синтаксис документа и сообщают обо всех нарушениях ограничений формы документа. Непроверяющие парсеры могут добавлять информацию к документу, основанному на декларациях DTD. MSXML читает DTD, включая внешние источники, и действует на основе этой информации.
Делают то же, что и непроверяющие, но, кроме этого, сравнивают структуру документов с правилами DTD или XML-схемы.
Использование того или иного вида парсера определяется потребностями приложения. Если строится общее XML-приложение, не рассчитывающее встретить конкретную структуру документа, непроверяющий парсер позволит использовать документы, не отвечающие какой-то конкретной структуре. По умолчанию Microsoft Internet Explorer использует именно непроверяющий режим работы для отображения наибольшего числа документов.
Но если вы создаете систему обмена информацией между организациями, и согласовали формат и содержание этого обмена, использование DTD (или XDR-схем) и проверяющих парсеров становится вполне обоснованным. Это дает вам еще один слой обработки, позволяющий удалить из приложения массу кода, проверяющего структуру документа, и, в то же время, обеспечить соответствие структуры документа оговоренному формату.
Рисунок 1. Отображение XML в Internet Explorer 5.5.
В Internet Explorer можно открыть любой документ, помеченный как XML. Если в документе не указано иного, Internet Explorer выведет документ, используя встроенный алгоритм преобразования (рис. 1). Если документ неверно сформирован, Internet Explorer сообщит об ошибке. Если документ содержит несколько ошибок, вам придется устранить ошибку, открыть документ заново и устранить следующую ошибку.
В состав Internet Explorer входит DOM-парсер, который можно заставить работать в проверяющем режиме. Для этого перед загрузкой документа следует переключить парсер в проверяющий режим.
Это можно сделать с помощью несложного VBScript-кода:
Set xmldoc = CreateObject("msxml2.DOMDocument")
xmldoc.ValidateOnParse = true
xmldoc.Load(url)
|
|
 |
