Чего мы ждем от XML

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

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

SGML

Язык XML представляет собой подмножество SGML (Standardized General Markup Language - стандартизованный обобщенный язык разметки) - обобщенного языка разметки, в 80-е годы принятого ISO в качестве стандарта. SGML дает возможность задавать элементы языка не непосредственно, а с помощью правил и ограничений.

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

Например, определение элемента Customer (заказчик) некоего документа на SGML могло бы выглядеть так, как показано в листинге 1.

Для проверки корректности разметки, использованной в определении структуры этого документа, потребовалось бы связать с ним DTD-описание, содержащее операторы вида:

В этом (предельно упрощенном и сокращенном) DTD-определении грамматика документа записывается в нотации, известной как расширенная форма Бэкуса-Наура.

Благодаря тому что определения написаны на стандартном метаязыке, анализаторы SGML оказываются способны вычленять в документе отдельные единицы (entities), подобные только что описанной customer, а также связанные с ними атрибуты и содержание. Полученной информацией прикладная программа сможет воспользоваться для решения ряда задач, включая следующие:

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

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

HTML

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

Вот как выглядит определение элемента HTML "ненумерованный список" в DTD-описании из спецификаций HTML 4.0 (в списке должны быть открывающий и закрывающий тег и хотя бы один элемент):

Эта запись в расширенной нотации Бэкуса-Наура означает, что UL является элементом, два дефиса соответствуют требованию наличия открывающего и закрывающего тегов, и элемент состоит как минимум из одного и, возможно, более чем одного пункта списка (LI). Анализируя элемент HTML, пользовательский агент (например, браузер) будет искать открывающий и закрывающий теги UL и по меньшей мере один элемент LI между ними.

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

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

Чтобы отделить в HTML структуру элемента от его представления, W3C издал рекомендации по CSS1 (Cascading Style Sheets Level 1 - иерархические стилевые таблицы, уровень 1) - спецификацию, обеспечивающую информацию о визуальном представлении для элементов HTML.

Реальное преимущество HTML состояло в сравнительной легкости как написания документов, так и интерпретации их браузером. С простотой HTML прямо связан лавинообразный рост Web. Если бы доступ к документам Web начался сразу с XML, то, возможно, вы не читали бы сейчас эту статью (журнал Netscape Enterprise Developer, где опубликован оригинал статьи, чисто электронный. - Прим. ред.), а с Web работали бы только представители научного сообщества. Чтобы начать, нам был необходим простой механизм создания Web-документов, и HTML оказался как раз таким механизмом. Даже негибкость оказалась сильной стороной языка.

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

XML: введение

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

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

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

Среди основных формальных правил, определяющих корректный документ XML, есть следующие:

• в начале документа может стоять корректное объявление XML (пролог);
• в документе имеется ровно один элемент, выступающий в роли корневого и родительского по отношению ко всем остальным элементам;
• элемент либо не пуст, либо пуст и содержит закодированное указание (hint) для анализатора XML;
• непустой элемент должен иметь открывающий и закрывающий теги;
• любой элемент, кроме корневого, содержится внутри некоторого другого элемента, который называется его родительским элементом; элементы, содержащиеся в другом, называются его дочерними элементами;
• элементы могут содержать символьную информацию, другие элементы, секции CData, инструкции по обработке и комментарии;
• каждый проанализированный элемент в документе формально правилен;
• символьные данные, которые могут обрабатываться как текст на языке XML, помещаются в секции CData;
• документы могут содержать комментарии, пустое место и инструкции по обработке.

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

document::= prolog element Misc*

Результирующий документ может быть очень простым:

Он состоит из секции пролога, содержащей объявление XML ("

Документ, рассмотренный нами в качестве примера, является формально правильным, но не корректным, поскольку DTD-описания, необходимого для проверки корректности, у нас нет. Этот пример демонстрирует также простоту XML. Можно было бы написать и еще проще:

Чтобы сделать документ корректным, DTD-описание элементов вставляется непосредственно в документ либо в нем делается ссылка на внешний DTD-файл:

XML в действии

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

Язык XML уже используется на практике. Например, специалисты Microsoft написали на XML определение формата CDF (Channel Definition Format - формат определения каналов). CDF-файлы содержат единицы, описывающие содержимое активного канала. В соответствии с принятой для XML техникой в этих файлах нет ссылок на внешнее DTD-описание, а использованы описания, вставляемые внутрь элементов, и определения тегов, обеспечивающие XML-анализатор необходимой информацией для продвижения по документу.

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

В листинге 2 приведен CDF-файл, который я определила для своего собственного Web-узла. Корневым в нем является элемент CHANNEL, родительский для еще нескольких элементов, таких как ITEM и ABSTRACT. Каждый элемент в документе может иметь или не иметь атрибуты, и дочерний элемент может, в свою очередь, быть родительским для некоторого другого элемента.

Первая строка нашего документа содержит объявление языка XML, номера версии и кодировки. Главной единицей является элемент CHANNEL, содержащий в себе другие элементы - TITLE, ITEM, ABSTRACT и LOGO. Все они соответствуют определению элемента XML:

element ::= EmptyElemTag | STag content ETag
EmptyElemTag ::= '<" Name (S Attribute)* S? '/>'
STag :: = '<" Name (S Attribute)* S? '>'
ETag::= ''
content ::= (element | CharData | Reference | CDSect | PI | Comment )*

Если не продолжать развертывание нетерминальных символов, то данная запись означает, что каждый элемент либо пуст, и тогда заканчивается косой чертой и угловой скобкой ('/>'), либо имеет открывающий и закрывающий теги, между которыми находится содержимое. На открывающий и закрывающий теги накладывается формальное ограничение, состоящее в том, что в обоих используется одно и то же имя элемента (Name). Содержимое элемента может включать другие элементы, комментарии, инструкции по обработке, другие формально правильные единицы XML. Как пустой, так и непустой элемент может иметь или не иметь атрибуты, например:

 ...
или

В Internet Explorer 4.0 есть встроенный анализатор XML, извлекающий из документа информацию об элементе. Используя полученную информацию, IE 4.0 создаст для нашего Web-узла канал с двумя подканалами.

При обращении из IE 4.0 к нашему CDF-файлу откроется диалоговое окно, в котором пользователь сможет определить способ подписки, а также расписание и способ получения информации на свою машину.

Другие применения XML

В дополнение к CDF корпорация Microsoft и компания Marimba предложили основанный на XML формат открытого описания программ (Open Software Description - OSD), который можно использовать для управления получением программного обеспечения по электронным каналам и его установкой в локальной сети предприятия. Установка и обслуживание программ на настольных компьютерах служащих - самая трудоемкая из обязанностей сотрудников информационных отделов крупных фирм, особенно имеющих отделения в разных местах. Планирование крошечной модернизации какой-либо популярной программы может потребовать нескольких дней, а ее реализация (т. е. хождение от машины к машине и установка на каждой из них новой версии) - нескольких недель. Пока происходит обновление, у сотрудников будут разные версии программы, а это в определенных случаях создает проблемы. Формат OSD позволяет автоматически производить модернизацию при помощи push-технологии, что одновременно и сокращает объем работы информационного отдела, и уменьшает число проблем, связанных с совместимостью.

На основе SGML и XML был разработан химический язык разметки (Chemical Markup Language - CML). С помощью словаря CML в документе можно определять струкуру молекул; информация либо посылается (post), либо передается (transmit). Анализаторы XML способны вычленять элементы CML и передавать их программам, выполняющим такие операции, как подготовка данных к печати в текстовой или графической форме или создание трехмерной экранной модели с помощью технологии VRML или ей подобной.

Компании Netscape, Apple и другие предложили язык MCF (Meta Content Framework - метаструктура содержания, или "контента"), позволяющий строить представление структуры Web-узлов для перемещения по ним и их интерактивного изучения. MCF можно применять для решения таких задач, как построение трехмерной карты узла для публикации и администрирования, и он уже сейчас используется в разработанном Apple браузере ProjectX/HotSauce. Информацию в формате Xspace позволяет также просматривать дополнительный модуль к браузерам, созданный в Apple.

На XML можно определить и метаязык реляционных баз данных (РБД), чтобы затем описывать на нем документы, содержащие реляционные данные. Такие документы легко порождаются из словарей РБД, которые представляют собой хранилища информации об информации, хранящейся в базе. В результате появляется возможность отказаться от нейтрального с точки зрения контекста формата баз данных и создавать с помощью XML документы, определяемые в первую очередь контекстом, такие как "вся информация, относящаяся к любым покупкам, сделанным между 16 и 23 января". Дополнительно в документ можно "втянуть" информацию, не являющуюся частью базы данных, например иллюстрации или справочный материал.

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

select customer_name, customer_address, city, state, zip_code from customer, purchase_orderwhere purchase_order.order_id = 32245 and customer.customer_id = purchase_order.customer_id;

пользователь будет входить в трехмерный VRML-мир через подъезд purchase_order (заказ) и пролистывать виртуальную картотеку в поисках требуемого номера заказа. Найдя его, он перейдет в другую комнату, где на одной двери будет написано Purchase Order items (заказанные товары), а на другой - Customer (заказчик), и, открыв ее, попадет в ту комнату, где должна храниться нужная ему информация (данные о заказчике). А лучше всего то, что документы, содержащие контекстно-зависимую информацию, генерируются, обрабатываются и выводятся автоматически, и, следовательно, все изменения, вносимые в базу, попадают в эти документы тоже автоматически.

Если идея базы с трехмерным интерфейсом вас не особенно вдохновляет, подумайте об использовании XML-определений для преобразования баз данных, скажем, из реляционных в объектные. Нереально? В действительности вполне реально: в списке источников я даю ссылку на рабочий вариант XML-представления реляционной базы данных.

С появлением работающих анализаторов XML решена самая сложная техническая задача - извлечение из документа составляющих его единиц.

Возвращаясь к примеру с CDF, добавлю, что к единицам XML-документа можно обращаться не только из Internet Explorer 4.0, но и из программы, написанной на Java, JavaScript или C++ и решающей совершенно другие задачи. Например, листинг 3 содержит функции JavaScript, которые открывают CDF-файл, извлекают из него информацию об элементах и выводят ее во вновь открытое окно (те, у кого есть IE 4.0, могут посмотреть демонстрацию работы примера по адресу http://www.yasd.com/cdfelems.htm).

Создание документа на XML

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

В последнем примере я, воспользовавшись способностью Internet Explorer анализировать XML-документы, создала страницу, на которой выводится список входящих в состав заданного документа единиц с атрибутами и определенным содержимым. Это интересно, но вряд ли пригодится на практике. Но что если определить собственный XML-документ со своими единицами и атрибутами, а затем воспользоваться встроенным в IE анализатором XML для программы, управляющей графическим меню Web-страницы? Это оказалось довольно легко - на все у меня ушло часа два.

Сначала я взяла свой CDF-файл и создала для него собственные единицы (см. листинг 4).

Я переопределила элемент ITEM, создала новый корневой элемент DOCUMENT и добавила элементы IMAGE, STYLESHEET и ALT. Все формальные требования были соблюдены - при открытии документа для анализа в IE 4.0 ошибок не возникает.

Затем я написала программу, которая строит окно, разделенное на два кадра. В верхнем кадре, используя изображения, связанные с элементами документа, программа создает графическое меню, а ссылки настраивает так, чтобы соответствующие документы открывались в нижнем кадре. При запуске программы окно содержит форму для обращения к CDF-файлу и обработки его содержимого, которая затем заменяется результатами этой обработки (см. листинг 5).

Таким образом, в XML-документах можно - в той степени, в какой это не противоречит формальной правильности, - определять любые элементы, а результаты их анализа обрабатывать практически как угодно. И все это уже реализовано (я использовала IE 4.01 под управлением Windows 95).

Ссылки и стили

В дополнение к уже готовым спецификациям XML сейчас разрабатываются и некоторые другие. Одна из них, XML 2, определяет работу со ссылками, другая, XSL (Extensible Style Language, расширяемый язык стилей) - стилевые таблицы для XML.

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

Спецификации XSL следует написать на XML, и они должны обеспечивать способ определения визуальных элементов, аналогичных тем, которые используются сейчас в HTML. Имеющиеся примеры элементов, отвечающих за способ представления текста, - это Emphasis ( - ), Strong ( - ) и некоторые другие. Но с помощью XSL можно будет составить рекомендации по визуальной интерпретации единиц XML. Считается, что XSL станет третьей частью спецификаций XML.

О недостатках XML

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

Недавно я снова обратилась к своему примеру CDF-файла и написала несложную программу на JavaScript, которая одновременно открывает в разных кадрах главную страницу канала и страницы, связанные с ней. Главная страница открывается вверху, а отдельные элементы ITEM - в маленьких кадрах, на которые поделена нижняя половина экрана.

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

Итак, я взяла общедоступный файл (CDF-файл IDG.net) и вывела элементы XML в форме, которой не предполагали разработчики ни в Microsoft, ни в IDG.net. И даже если применять новый язык XSL (который пока существует лишь в виде предложения W3C), нет гарантии, что информация, представленная на XML, будет использоваться хотя бы приблизительно так, как планировал создатель исходного документа.

Еще одна группа проблем связана со спецификациями CDF. Этот формат обладает огромным потенциалом - с его помощью можно построить основанный на XML документ, который в реализации разных поставщиков push-технологий даст приблизительно одинаковые результаты. Ну а если кто-то поддерживает каналы, но обходится без CDF? Не окажется ли так, что мы в конце концов будем иметь дело с разными "оттенками" каналов? И не придется ли тогда W3C обеспечивать наличие только одного стандарта для каждой предметной области, создавая спецификацию отдельно для каналов, отдельно для химии, отдельно для математики, отдельно для финансов и т. д? А может быть, мы начнем разрабатывать средства для перевода одних XML-определений в другие?

Все это действительно проблемы, хотя степень их серьезности еще предстоит выяснить.

Заключение

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

На прошедшей в декабре прошлого года в Вашингтоне конференции по XML и SGML язык XML получил статус предполагаемой рекомендации (proposed recommendation) W3C. Теперь всего одна ступенька отделяет XML от того, чтобы стать настоящей рекомендацией (W3C утвердил XML в качестве стандарта 10 февраля. - Прим. ред.), и, возможно, превращение его в такой же общеупотребительный язык, каким сейчас является SQL, - лишь вопрос времени.

Источники

Листинг 1. Определение элемента (SGML)





Item ID: 14453
Item Desc: некое описание

Листинг 2. Пример файла определения канала (CDF)



    
    YASD+ pages, using the newest technologies
    
    
    
    
        
        
        
    
    
        
        YASD Code Byte
    
    
        
        Cheap Page Tricks
    

Листинг 3. Обработка XML-документа (JavaScript)

Листинг 4. Управление графическим 
меню страницы (XML)




    
    
    
        
        YASD+ Main Page
        
    
    
        
        YASD Code Byte
        
    
    
        
        YASD Cheap Page Tricks
        
    

Листинг 5. Форма и ее обработка (JavaScript)