Предположим, что вас убедили в ценности расширяемого языка разметки (Extensible Markup Language, XML). Что дальше? Купить редактор XML и ждать, пока все станет на свои места? Каждый ли, кто натолкнется на ваши документы, поймет ваш язык, ведь XML является самодокументируемым форматом разметки?

Без сомнения, все документы, которые иначе были бы созданы на HTML, можно хранить как XML вместе с соcтавленными вами самими пояснительными тегами. На данном этапе развития Web вам придется использовать сервер для преобразования XML в HTML, если вы хотите, чтобы любой желающий мог просматривать документы XML как страницы Web, но это незначительное неудобство сохранится лишь до тех пор, пока все браузеры в мире не станут понимать XML. Вероятно, еще до этого момента вы сможете извлечь преимущества из следования правильной практике кодирования, в частности инструментарий поиска сможет различать разные теги, например то, что <publication> Network </publication> имеет иной смысл, нежели <marketing-strategy> Network </marketing-strategy>.

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

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

Таким образом, одна из тенденций в мире XML состоит в том, что в целях упрощения обмена информацией между отраслями описание документа стремятся сделать как можно более выразительным, с одной стороны, и как можно более предсказуемым — с другой. В этой статье мы рассмотрим, как это может быть сделано, на примере инициативы BizTalk Framework компании Microsoft и принятой ею системы XML Schema для описания своих документов.

Кроме того, XML выходит за первоначально отводимые ему пределы; он больше не ограничивается исключительно автономными документами с информационным наполнением. В настоящее время многочисленные работы ведутся над использованием XML для определения последовательностей сообщений, составленных на XML. Их результаты можно найти и в BizTalk, но, возможно, наиболее зрелым примером является протокол обмена информационным наполнением Internet (Internet Content Exchange, ICE). ICE служит отличным примером того, как отрасль может решать свои проблемы с помощью обмена сообщениями на базе XML.

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

<book> <author>Джон Милтон</author> <title>Потерянный рай</title> </book>

Если вы продемонстрируете эту формулировку во время презентации, то большинство присутствующих согласно закивают, соглашаясь, что имя автора действительно имеет смысл выделить в отдельный элемент данных и дать ему смысловой тег <author>.

Но реальная жизнь намного сложнее, даже если вы ограничиваетесь достаточно предсказуемым понятием книги. Традиционно автором «Тома Сойера» считается Марк Твен, но реальный человек получал гонорары под именем Самуэль Клеменс. Должны ли вы создать другой тег для псевдонимов? Или же использовать тег <author> с атрибутом nametype=pseudonym? Как различать разные издания? Будут ли данные об авторских правах описываться с помощью атрибутов тега <copyright> или каждый их элемент будет иметь отдельный тег внутри элемента <copyright>? Если два книжных магазина реализуют свои собственные приложения и затем решат обмениваться данными из своих каталогов, то кто будет проверять правильность соответствия?

За исключением пары случаев, не имеющих отношения к бизнесу, Консорциум World Wide Web (W3C, http://www.w3.org) четко обозначил свою позицию: он не собирается давать свое благословение каким бы то ни было приложениям XML (в терминологии XML «приложением» называется описание отраслевых терминов с помощью некоторого набора тегов XML, это не имеет никакого отношения к программным пакетам). Другими словами, конкретные вертикальные рынки должны самостоятельно согласовать внутри отрасли имена для своих объектов. Дабы способствовать открытости и предсказуемости при составлении схем XML в вертикальных отраслях, Microsoft выдвинула инициативу, названную BizTalk. По состоянию на август 1999 года эту инициативу поддержало свыше 25 компаний.

Отчасти BizTalk представляет собой не что иное, как общественный сервер Web (http://www.biztalk.org), где публикуются все схемы, предложенные для использования в различных отраслях. Маркус Шмидт, менеджер по работе с компаниями, специализирующимися в области поставок, говорит, что Microsoft и другие члены Инициативной группы BizTalk работают над рекомендациями и тегами XML для придания некоторого однообразия использованию XML в бизнесе. Однако BizTalk не ставит своей целью объединить все отрасли в попытке составить одну гигантскую схему для всех используемых в каком бы то ни было бизнесе данных. «Мы очень хорошо понимаем, что никогда не сможем заставить различные отрасли прийти к согласию даже по поводу фундаментальных вещей, например в отношении определения заказчика, так как каждой из них требуется своя информация о заказчике. Мы пытаемся добиться того, чтобы, когда производитель решит составить свою собственную схему, он имел как можно более высокие шансы, что его схема будет совместима с чьей-либо еще, если он станет следовать нашим рекомендациям и если другие будут иметь возможность без труда получить его схему, чтобы они могли установить соответствие между своей и его схемой».

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

В том, что касается отображения отраслевых данных, BizTalk исходит из бесперспективности определений типов документов (Document Type Definition, DTD). Вместо того чтобы поощрять разработку XML DTD, сторонники BizTalk описывают свои иерархии данных с помощью XML Schema (как предполагается, этот стандарт должен прийти на смену DTD). «DTD свойственны некоторые внутренние ограничения, — поясняет Шмидт. — Поэтому многие люди и группы предлагают свои решения».

В настоящее время W3C пытается согласовать различные подходы к схемам, но предложенная версия стандарта — XML Schema — дает достаточно ясное представление о том, как будет выглядеть замена DTD. XML Schema имеет значительно более широкие возможности, нежели DTD, причем описания даются с помощью непосредственно XML, без создания еще одной системы разметки, как того требует DTD (см. врезку «Новая схема»).

На общем уровне BizTalk Framework требует, чтобы издатели XML Schema придерживались определенных рекомендаций, большая часть которых основывается на общепринятой практике разработки программного обеспечения. Так, тегам предлагается давать осмысленные имена с понятным несокращенным написанием; эти имена должны соответствовать функциональному назначению информации, а не ее месту в частной структуре данных (например, “PartLocation” вместо “PartFieldFourteen”), а содержащаяся в теге информация не должна требовать специального, отличного от XML, декодирования (например, обозначение валюты денежной суммы должно храниться в виде элемента XML, а не присоединяться к сумме как в “$30US”). Эти рекомендации призваны облегчить жизнь тем, кто будет пытаться дешифровать конкретную схему.

Необходимыми составляющими BizTalk Framework являются специальные, общие для всех отраслей теги XML. Эти теги призваны освободить разработчиков от забот по поводу трех важнейших проблем взаимодействия приложений. Во-первых, от того, как данные передаются из одного приложения в другое; во-вторых, от того, как «вызвать» другое приложение — отправки приложению данных в формате XML должно быть достаточно; в-третьих, от того, в каком порядке должны следовать элементы данных.

Так что же делают эти теги? Один из них определяет код, с помощью которого принимающая данные в формате XML программа может установить, что за схема BizTalk используется. С помощью других тегов приложение может выяснить, кто является отправителем данных, что отправитель от него хочет и кому данные должны быть потом переданы. «Точно так же на основании информации на конверте почта определяет, как следует поступать с письмом, при этом ей нет никакого дела, что и в каком виде он содержит», — поясняет Шмидт.

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

<Route> <From locationID=”11111111” locationType=”DUNS” process=”” path=”” handle=”3”/> <To locationID=”222222222” locationType=”DUNS” process=”” path=”” handle=”23CF15”/> </Route>

BizTalk Framework ничего не говорит о том, какие данные должны входить в четыре атрибута тегов и , она просто устанавливает назначение каждого из них. Теги location идентифицируют сетевой узел (возможно, с помощью URL), куда направляется документ, в то время как теги process и handle определяют приложение и конкретный экземпляр (например, номер транзакции), к которому данные относятся.

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

Общий формат полного сообщения BizTalk показан во врезке «Анатомия сообщения BizTalk».

Учитывая, что эти спецификации документов являются общедоступными и любой желающий может использовать схемы BizTalk бесплатно, вы можете резонно спросить, как Microsoft собирается извлекать прибыль с помощью XML? Ответ прост — за счет продажи инструментария XML.

Как считает Шмидт, главным источником прибыли для Microsoft должен стать серверный продукт для регулирования обмена BizTalk-совместимыми сообщениями XML между партнерами по бизнесу. По его словам, бета-версия этого продукта должна появиться в конце осени 1999 года; готовый же продукт должен выйти после Windows 2000.

Возможно также, что одним из источников прибыли могут стать ориентированные на конкретные рынки оперативные службы (на таких узлах, как Microsoft MSN), где BizTalk будет использоваться производителями для сообщения рыночной службе о предложении новых продуктов и специальных скидок.

Как поясняет Шмидт, если такая оперативная служба появится, то она не будет базироваться на сервере BizTalk, поскольку он предназначен исключительно для целей создания библиотеки и общественного центра, где бы компании и разработчики могли свободно обмениваться идеями. «Мы не рассматриваем biztalk.org в качестве портала для организации сделок между компаниями», — уверяет Шмидт. В настоящее же время основные усилия BizTalk сосредоточены на том, чтобы отраслевые группы приняли BizTalk Framework в качестве общего знаменателя их усилий в области XML.

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

Необходимость в «правилах использования» (т. е. протоколах) становится очевидной в случае компаний, основная задача которых состоит в создании документов. Такой компанией является, например, агентство новостей «Рейтер». Наверняка, путешествуя по Web, вы обратили внимание, что в последнее время «шапки» «Рейтер» стали мелькать тут и там.

До появления ICE всякий раз, когда «Рейтер» заключало соглашение с каким-либо сервером Web о включении своего информационного наполнения, обеим сторонам приходилось прибегать к дополнительному программированию, чтобы заголовки и блоки новостей могли быть интегрированы в целевой узел Web.

Учитывая то, что основные затраты на распространение новостей, таким образом, приходились на переопределение соединений и преобразования, несколько игроков на рынке объединились для создания ICE — протокола базового механизма регулярной рассылки новостей. В июле 1999 года представители инициативной группы разработчиков продуктов для ICE, агентств новостей и их подписчиков собрались в Чикаго на ICE Summit. Эта встреча была организована Исследовательским институтом Ассоциации графических коммуникаций.

Встреча продемонстрировала, что ICE достиг критической массы для создания работающих на его базе продуктов и что по крайней мере несколько компаний используют данный протокол для решения своих задач (см. врезку «Три реализации ICE»). Это не тот протокол, где переопределяется все устройство вселенной (его претензии гораздо скромнее), но он удовлетворяет вполне определенные потребности бизнеса и делает свое дело с учетом всех тонкостей решаемой задачи, избегая при этом всяких излишеств. Спецификация ICE содержит DTD, определяющие, какими должны быть сообщения с различными запросами и ответами как при переговорах о новой подписке, так и при предоставлении информационного наполнения. (Пока что инициативная группа избегает использования XML Schema, поскольку та еще должна быть доработана и принята W3C.) ICE отличается от типичного приложения XML тем, что в нем XML применяется для форматирования сообщений внутри протокола, а не для определения более традиционных документов. Кроме того, в то время как XML чаще всего служит для предоставления размеченных документов клиенту (обычно браузеру Web, выполняемому на машине конечного пользователя), ICE предназначен преимущественно для межсерверных коммуникаций, где необходимость в визуальном представлении данных (и участии человека) отсутствует.

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

Таким способом ICE позволяет согласовать следующие два аспекта подписки: во-первых, как будет доставляться подписка — по запросу подписчика (pull) или по каналам агентства (push); во-вторых, каким будет график доставки.

На ICE Summit Рик Левин, архитектор Web в Sun Microsystems, отметил, что серверы согласуют только техническую, а не финансовую или информационную сторону соглашения. «Участие человека при оформлении подписки на новости по-прежнему будет необходимо. Без делового ужина обойтись не удастся». Как он отмечает, очередь ICE приходит после заключения договора. ICE — это система для доставки информационного наполнения, причем эта система понимает настройки, которые провайдер новостного информационного наполнения хотел бы применить к своей интеллектуальной собственности.

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

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

Сама полезная нагрузка также формализуется с помощью тегов XML. Кроме того, контроль над тем, как обрабатываются элементы, описываются в полезной нагрузке с помощью свойств соответствующих тегов XML. Сила протокола, по сравнению с более ранним и тривиальным форматом определения канала (Microsoft Channel Definition Format), состоит в том, что ICE вводит постоянные элементы подписки. Например, новость всегда должна иметь заголовок. Содержание заголовка может меняться, но ему отводится определенное место, где его всегда можно найти.

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

ICE является далеко не единственным предложенным стандартом, где XML применяется для определения коммуникационного протокола. К слову сказать, уже один тег , как он определен в BizTalk, помещает отраслевые множества данных на конвейер сообщений. Так, еще несколько протоколов Internet аналогично описываются с помощью XML. Это, например, Platform for Privacy Preferences (P3P) и Synchronyzed Multimedia Integration Language (SMIL, произносится как «смайл»). И не приходится сомневаться, что вскоре появятся еще.

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

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

Хотя практически в любом обзоре XML (не исключая и статью «XML: время пришло») говорится, что грамматика и синтаксис правильно составленного документа XML определяются DTD, скорее всего, дни DTD уже сочтены. На смену DTD должен прийти новый стандарт — XML Schema.

DTD вполне достаточно для базового определения документа, но они имеют несколько недостатков. Во-первых, они даются не на XML. Учитывая высокую степень адаптируемости и расширяемость XML, наличие еще одного формата для определения документов представляется излишним.

Во-вторых, элементы DTD внутри документа XML требуют полного определения всего, что находится внутри этих элементов. Другими словами, никакие подэлементы «на перспективу» не допускаются — если таковые будут присутствовать в документе, то, по определению, документ не будет являться правильно составленным. Между тем определения XML Schema используют модель открытого информационного наполнения, в которой неопределенные элементы вполне допустимы.

В-третьих, DTD ограничиваются только грамматикой и синтаксисом (т. е. отношением одного элемента к другому), тогда как XML Schema может также задавать непосредственные ограничения на тип данных, которые элемент может содержать. Это значительно упрощает реализацию передачи данных приложения по сравнению с более традиционным текстовым документом. Например, точно так же, как это делают разработчики в языках программирования, вы можете явным образом указать, что данная область хранения может содержать только целочисленные данные. Наконец, разработчикам, работающим в средах Wintel, будет весьма удобно то обстоятельство, что XML Schema легко отображается на Microsoft Document Object Model. Таким образом, работающая с документами XML программа может запросить у соответствующей схемы имеющееся определение для элемента документа по своему выбору. Код выглядит следующим образом:

var bookNode = doc.documentElement

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

<Schema name=”schema_sample_1”> ... содержание схемы </Schema>

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

<ElementType name=”PERSONA” content=”textOnly” />

определяет элемент <Inventor> как могущий содержать только текстовые данные.

Подобные схемы могут оказаться весьма трудны для чтения, но они легко поддаются разбору с помощью инструментов XML. Другими словами, вам не потребуется специальный редактор для работы с документом XML Schema, как в случае DTD.

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

На ICE Summit в Чикаго в июле 1999 года было продемонстрировано три ICE-совместимых менеджера распространения новостей.

WebExpress
Arcadia Technology
http://www.arcadiatech.com
Ввиду того, что пока webExpress имеется лишь в бета-версии, говорить о том, чем этот пакет отличается от своих конкурентов, было бы несколько преждевременно. Однако судя по тому, что было продемонстрировано на ICE Summit, это будет непосредственная реализация протокола ICE без каких-либо излишеств.

ShiftKey Syndication System
ShiftKey Software
http://www.shiftkey.com
ShiftKey решила повысить ценность своего продукта за счет добавления поддержки ряда средств преобразования информационного наполнения после его поступления на сервер подписчика. В конце концов, ICE просто доставляет информационное наполнение в стандартном формате, а он ведь может и не подходить для прямого включения данных в Web-страницы подписчика. Один из поддерживаемых ShiftKey методов трансформации — Extensible StyleSheet Language (XSL), он определяет, как теги XML должны отображаться в браузере. Необходимые преобразования описывают таблицы стилей.
Что касается серверной стороны, ShiftKeySoftware на момент публикации статьи была единственной компанией, поддерживающей распространение по запросу подписчика (pull) и по каналам агентства (push) и предоставляющей сервер ICE, не привязанный к системе управления информационным наполнением.

Vignette Syndication Server
Vignette
http://www.vignette.com
Syndication Server рассматривается как отдельный продукт, но его основное назначение состоит в упрощении достижения соглашений о рассылке новостей с помощью имеющегося продукта, а не в ориентации на рынок рассылки новостей сам по себе.
Предложение Vignette тесно привязано к Vignette Story Server, системе управления информационным наполнением Web старшего класса, используемой такими издательскими гигантами, как Time Warner, Ziff-Davis и Chicago Tribune.

Принимающее приложение узнает о том, что это сообщение BizTalk, на основании конверта (он сообщает конкретную схему, использованную для формулирования данного документа). Оно понимает формат ваших специфических данных, потому что тег <MsgType> указывает на схему, которую вы используете внутри для форматирования своих данных:

<BizTalk xmlns=”urn:shemas- biztalk-org:BizTalk/biztalk-0.81.xml”> <Route>

Теги маршрута

</Route> <Body> <MsgType xmlns= ”urn:ваше-пространство-имен”>

Ваш документ

Вся информация о BizTalk, в том числе полная спецификация тегов BizTalk, имеется на http://www.biztalk.org.

Полная спецификация Internet Content Exchange (ICE) доступна интерактивным образом на http://www.w3.org/TR/NOTE-ice.

Дополнительную информацию о XML Schema можно найти на http://www.w3.org/TR/xmlschema-1/ и http://www.w3.org/TR/xmlschema-2/.