Что происходит с XML

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

Питер Флинн играл ведущую роль в разработке стандарта и не остается равнодушным к судьбе XML и сейчас, когда этот язык пытается найти свое место в этом мире.

Что происходит с XML сейчас?

Какова ситуация сейчас?

Сейчас наступил момент «стабильности», но нельзя сказать, что XML «широко используется». Это во многом объясняется тем, что особой активности не проявляют производители программного обеспечения. Крупные компании, работающие с SGML (Standard Generalized Markup Language) могли бы без особых усилий добавить XML в свои продукты, поскольку они понимают, что необходимо и при этом обладают достаточным опытом. Но прошло два года, прежде, чем появился предварительный вариант приличного типографского редактора XML - XMetal. И это в компании, которая специализируется на SGML! Многие другие предложения абсолютно не оправдывают ожиданий пользователей. Существуют сотни инструментальных средств и пакетов разработки, но практически ни одно из этих решений нельзя назвать полноценным XML-пакетом.

Кто использует XML?

Его используют все и каждый, кто обладает техническими «ноу-хау», позволяющими в нем разобраться. Каждый студент-первокурсник колледжа пишет синтаксический анализатор XML на Java (хотя никто из них, похоже, не создает действительно реальные анализаторы). И каждая торговая ассоциация и NGO, где мне приходилось бывать, создают DTD (определение типа документа) для своей области деятельности. Специалисты по электронной коммерции утверждают, что применяют XML, но пока я не вижу доказательств его широкого распространения. Возможно XML делает именно то, что и должен делать: остается скрытым под другими сетевыми уровнями. В результате, эта технология, предназначенная для разметки данных, пока не продемонстрировала все, на что способна. Такое впечатление, что каждому программисту баз данных на планете его шеф твердит, что «нужно, чтобы она работала с этим XML», поскольку все они спрашивают, а как «программировать» на XML.

Какие компании и отрасли могут с наибольшей для себя пользой применять XML?

С наибольшей пользой применять XML могут компании, которые намерены реализовывать его рационально. Потенциально XML может оказаться очень полезной технологией, но его нужно реализовывать с пониманием; в противном случае все закончиться также, как и с HTML, когда спецификация нарушалась столь грубо, что сам по себе язык стал совершенно бесполезным. Я уже видел синтаксические анализаторы, написанные с нарушением спецификации, поскольку программист, на самом деле, совершенно не понимал, в чем состоят ее требования.

Вы считает, что XML способен весьма пригодиться для электронной коммерции?

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

Вы считаете, что обычные администраторы Web перейдут на XML?

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

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

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

Механизмы поиска должны нести свою часть вины за то, что сейчас в Web мы двигаемся на ощупь. Если бы они располагали страницы в соответствии с достоверностью индексации, основываясь на смысле разметки и на метаданных, а не на частоте случайной выборки, и объясняли бы это тем, кто заказывает поиск, это стимулировало бы авторов создавать более достоверные страницы. Сейчас, они вынуждены сообщать о том, что их страницы посещает множество пользователей, чтобы убедить людей еще раз обратиться на эти узлы и удовлетворить амбиции рекламодателей. Разработчики страниц не могут быть уверены в том, был ли выбран их узел осмысленно или по ошибки до тех пор, пока пользователи еще раз не посетят его. Поэтому в результатах поиска по запросу мы обычно получаем 99% всякого мусора. А мы вынуждаем авторов добиваться того, чтобы их страницы отличались от других, вплоть до размещения прекрасных метаданных, но механизмы поиска никак не реагируют на надежность. Это плохо.

Будущее XML

Какой из стандартов менее всего соответствует представлению о зрелом стандарте?

Ближайший родственный стандарт - это XSL (Extensible Stylesheet Language), и он достаточно неплох, но в нем есть несколько белых пятен, в частности то, что касается «форм». Самым важным упущением можно назвать отсутствие приличного редактора таблиц стилей для XML, который имел бы приемлемый интерфейс. Прекрасным примером был Panorama (для SGML), чей интерфейс был поразительно удобен и который можно было бы адаптировать к XSL. К сожалению, этот пакет был продан компании Interleaf, которая не обладала достаточным знанием SGML или XML, чтобы поддерживать Panorama или развивать его, и, по-видимому, обязанности Interleaf в любом случае возьмет на себя другая компания. Но пока еще рано говорить об этом; это вопрос будущего.

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

Какие из стандартов наиболее приемлемы?

WAP (Wireless Application Protocol) производит неплохое впечатление и, скорее всего, его ожидают прекрасные перспективы, когда появятся сотовые телефоны, в которых он будет реализован «с нуля» и без дополнительной оплаты.

MathML (Mathematical Markup Language) - прогрессирует, но математики в Web по-прежнему страдают от категорического нежелания производителей браузеров его реализовывать, причем без убедительных объяснений, учитывая наличие огромных рынков бизнеса, науки и инжиниринга, не говоря уж об образовании.

Может ли кто-нибудь (такой как Microsoft) поддержать XML с помощью своей собственной технологии?

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

У меня как раз есть рекламная листовка с описанием системы работы с документами одной из компаний, которая, как утверждается, позволяет контролировать право собственности, версии и редактировать у себя «HTML»-документы, в то же время предоставляя возможность обслуживания через Web. Этот продукт, без сомнения. придется по нраву менеджерам, которые не понимают, что ровно то же самое вы можете делать с помощью уже существующего свободно распространяемого программного обеспечения. Так что пусть себе тешутся с дорогим белым слоном. Руководство компаний должно понять огромную выгоду, которая достигается заменой необязательных расходов на навыки и знания.

Развитие XML

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

Пользователи SGML давно жалуются на отсутствие в браузерах поддержки общего SGML. Производители браузеров отказываются добавить такую поддержку, поскольку по сути они не понимают SGML и считают эту работу слишком сложной и не очень важной. Тем не менее уже созданы два подключаемых модуля (Panorama и MultiDoc Pro, которые используют одно и то же ядро браузера Synex).

Была принята идея создания некого упрощенного SGML - SGML-Lite, который обладал бы теми же функциями работы с документами, но не имел более редко используемых возможностей, которые и делают программирование SGML таким сложным. Эта идея возникла, при встрече в 1996 году Джона Босака из Sun и Джина Паоли из Microsoft. К моменту проведения в том же году конференции Boston SGML Conference к ним присоединилось немало ведущих специалистов, занимающихся разработкой SGML в бизнесе и научной деятельности, чтобы под эгидой консорциума W3C создать рабочую группу по XML. Приглашенные эксперты присоединились к ним, создав специальную группу (SIG), которая разрабатывала спецификации. К конференции SGML 1997 года, которая состоялась в Вашингтоне, спецификации были готовы.

Ядро специальной группы очень напоминает по составу рабочую группы IETF по HTML, которая по сути прекратила свое существование. Это чревато повторением ситуации с HTML. Это были люди, которые старались сделать HTML более формальным и легко управляемым, но были погребены под лавиной тегов, добавленных производителями браузеров.

Джон Босак возглавил SIG. (Он предлагал это мне, но я отказался, согласившись принять на себя лишь некоторые дополнительные обязанности). Само по себе членство в рабочей группе было, конечно, ограниченным для представителей W3C, которые рассматривали предложения SIG и формулировали фрагменты спецификаций данных. Затем в SIG обсуждали материал, комментировали его и так постепенно создавался текст.

Вы сожалеете о чем-нибудь, связанном с эволюцией XML?

На самом деле есть несколько вещей, на которых я настаивал.

Если вы используете XML вместе с внешними DTD или другими файлами, на них сразу же должны быть организованы ссылки с помощью URL, и все прекрасно до того момента, пока эти ссылки не порушены (в результате перемещения или просто стали недоступными). SGML имеет концепцию Formal Public Identifier (FPI), которая представляет собой не зависящую от платформы метку для внешнего ресурса, такого как DTD, или интегрированного файла (в HTML они выглядят, как « -//W3C//DTD HTML 4.0//EN»). FPI в XML являются дополнительными и требуется каталоговая системы для того чтобы преобразовать их в URL или имя файла, но их независимость и присущая им большая гибкость делают их более устойчивыми, чем URL. FPI и разрешение с помощью размещенного в сети каталога было бы значительно лучшим подходом. В этой области работа продолжается.

«» и «/IMG>» в XML эквивалентны, что, как мне кажется, довольно расковано. Поскольку XML может использоваться и без DTD, должен существовать способ определить элементы, которые предполагаются пустыми - EMPTY (как «» в HTML), не зная об этом заблаговременно (это одна из тех вещей, которую вам может сообщить DTD); в противном случае программы могут дойти до конца программы в поисках тега-конца, который так никогда и не будет найден. Использование Null End-Tag - это соответствующий SGML способ сообщить об этом XML в отсутствие DTD, используя оконечный слеш (/) (поэтому «» мог бы стать «»), но возражение состояло в том, что для согласованности должно быть «» (тег-начала и тег-конца не должны содержать никакого текста). И то, и другое может быть корректным в XML, и на самом деле они абсолютно эквиваленты. Опасность состоит в том, что по-прежнему очень многие вещи пишутся вручную и пользователь-новичок может добавить текст в элемент, продекларированный как EMPTY, в силу чего файл станет некорректным.

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

Питер Флинн является членом рабочей группы, которая занимается формализацией HTML для Internet Engineering Task Force, и членом специальной группы, которая консультирует консорциум W3C по вопросам, связанным с XML. Флинн - автор книги «Объяснение SGML и инструментальных средств XML» (Understanding SGML and XML Tools (Kluwer Academic Publishers, 1998) и соавтор XML FAQ. С ним можно связаться по адресу peter@silmaril.ie.

Об авторе

Ричард Виггинс - ведущий специалист по информационным технологиям государственного университета штат Мичиган. С ним можно связаться по адресу wiggins@mail.com.