Диалектическая спираль Web

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

Простые правила разметки таковыми выглядят только на первый взгляд. Тим Бернерс Ли описывал HTML с помощью другого языка - SGML. Изначально большинство авторов и разработчиков Web не придало большого значения такому способу описания языка. Но на самом деле эта особенность была отправной точкой для всей Web-технологии. В SGML предусмотрена возможность описания документа как набора контейнеров, которые вставляются друг в друга. В первых версиях HTML Бернерс Ли задействовал пришедший из SGML термин "элемент", но позже в документации все чаще стал появляться другой термин - "контейнер". Каждый из контейнеров имеет свои свойства, которые, вообще говоря, можно изменять, причем так, что заново форматировать отображаемую на экране страницу не приходится.

Первыми эти возможности оценили в Netscape, разработав концепцию объектного представления Web-документов LiveWare. В отличие от Netscape, Microsoft не "прониклась" логикой Web. Следствием этого стали неудачи корпорации при попытке внести изменения в стандарт HTML, "внедрив" в язык свои теги, поскольку нововведения Microsoft шли вразрез с основными идеями, определившими суть технологии. Это был набор эклектично собранных технологических решений, подобранных на основе опыта, накопленного корпорацией при разработке офисных систем. Попытка их переноса на совсем другую почву не могла принести ожидаемого результата. Чтобы добиться чего-то в этой области, необходимо придумать нечто принципиально новое и при этом вполне органично вписывающееся в технологию.

Пока же Microsoft только повторяет решения Netscape и Sun. И речь идет не о том, что ActiveX лучше или хуже чего-то другого. Просто данная технология представляет собой альтернативу решениям от Sun и Netscape; эта альтернатива появилась позже технологий этих компаний, свидетельствуя о потере темпа корпорацией Microsoft. К слову сказать, в Microsoft это прекрасно осознают. И сотрудничество с консорциумом W3C, который возглавляет Бернерс Ли, относительно каскадных описателей стилей тоже не случайно. Стили - это логическое продолжение современных средств разметки, следовательно это сфера, которая наверняка окажется жизнеспособной и, возможно, позволит обойти конкурентов.

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

С другой стороны, природа первых версий языка HTML была такова, что сами HTML-документы получались модульными. До описания контейнеров в виде объектов оставался всего один шаг, и Nescape его сделала. К этому решению толкала и логика развития гипертекстовых систем в целом. Если рассматривать подход, называемый академическим, который пропагандирует все тот же Тим Бернерс Ли, гипертекстовая система состоит из множества информационных узлов, множества связей между ними и аппарата отображения множества связей на множество информационных узлов. Если аппарат отображения называть в привычных для технологии программирования терминах, то в этом случае мы должны иметь возможность программировать сценарии просмотра Web-страниц. При этом желательно, чтобы язык программирования позволял реализовать рекурсивные процедуры просмотра и процедуры, которые корректируют сценарий по мере его реализации (свойство автокоррекции). Таким образом, для реализации языка идеально подходит интерпретатор. Следовательно, "Паутине" как гипертекстовой системе для функциональной полноты нужен интерпретируемый язык управления сценариями просмотра.

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

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

Таким образом, данное средство вполне отвечает современным требованиям, предъявляемым к Web-страницам. Но этот же язык естественным образом соответствует и логике развития Web. Основной объект манипулирования в JavaScript - это контейнеры HTML. Собственно, все крутится вокруг того, что называется объектом Navigator. Правда, сами разработчики в качестве "корневого" объекта древа наследования выбрали окно программы-браузера, и весь отчет они ведут именно от него. Тем не менее, если попытаться строить систему объектов логически более стройно, то придется признать, что естественнее было бы выбрать в качестве самого старшего объекта Navigator. Правда, при этом нарушается наглядность JavaScript.

Объектно-ориентированное программирование в JavaScript опирается на объекты, которые можно наблюдать на экране. Эти объекты осязаемы и интуитивно понятны авторам страниц. Чтобы программировать на JavaScript, разработчику нужно лишь иметь перед глазами Netscape Communicator и представлять себе принципы HTML-разметки.

Все контейнеры HTML наделяются свойствами, которыми можно управлять при помощи функций-методов, "привязывающихся" к каждому объекту-контейнеру. При этом изменяемые и неизменяемые свойства легко опознаются по принципу переформатирования текста. Если при изменении какого-либо свойства требуется перерисовать весь документ, то это свойство изменять нельзя; если же не требуется (как, например, в случае с атрибутом src графической картинки), то программист имеет возможность его изменить. Все одновременно и просто и сложно, как сама система World Wide Web.

Язык JavaScript позволил говорить о реализации контейнеров HTML в виде объектов с определенными свойствами. Но сами контейнеры появляются только в момент загрузки документа браузером. Объектно-ориентированный подход включает еще понятие класса как обобщенного описателя множества типовых объектов. Вот тут снова пригодились идеи Бернерса Ли относительно использования каскадных таблиц стилей - стандартных описателей контейнеров HTML.

Описатели стилей естественно вытекали из языка SGML, на котором было построено описание HTML. Но кто же из прагматиков задумывается о вечном? В стандарте HTML 2.0 вообще предлагалось отказаться от строгой структуризации документов. Развитие технологии Web продемонстрировало непродуктивность такого подхода. Наряду с JavaScript в HTML появились фреймы и конструкции, которые развивают именно структурные особенности построения языка. Это необходимо для управления частями документа и правилами их отображения.

Любопытно, что стили в определенном смысле похожи на секции данных в традиционных языках программирования. Это и понятно - одинаковая организация труда и сходная область применения требуют одинаковых технологических решений. Сегодня в состав языка библиотеки компонентов HTML входят библиотеки скриптов JavaScript и библиотеки описателей стилей. Чего нам еще не хватает для полного счастья (построения полной системы аналогий с индустрией программирования), так это абстрактных типов данных и классов объектов.

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

Объекты в Java не привязаны к конкретной программе или интерфейсу. Они позволяют реализовать любой экранный интерфейс. Собственно, Java начинался как язык программирования компьютерных систем, встроенных в бытовую технику. Наследница этого компонента, библиотека оконных классов AWT (Abstract Windowing Toolkit) до сих пор остается одной из наиболее развитых. На мой взгляд, она представляет собой обобщение опыта разработки интерфейсов, накопленного многими поколениями программистов, выраженное в виде предельно сжатого и предельно простого набора примитивов.

Первоначально в рекламе технологии Java компания Sun делала акцент на возможности динамического Web: эпоха статики прошла, статический узел Web умер, переходите к динамике! Но оказалось, что не все так просто. Статические документы были, есть и будут. Тогда Java без лишнего шума переместилась в нишу разработки распределенных приложений. Уже есть полностью написанные на Java браузеры, но в большинстве случаев Java-апплету в документе отводится лишь небольшое окно, в котором этот апплет может работать. Кардинальных изменений не произошло - программировать HTML-страницы на Java никто не стал. Да это и понятно: уровень абстракций в Java слишком высок, чтобы его можно было легко нести в массы. Тем не менее вопрос по-прежнему не закрыт, он может снова встать на повестку дня, но уже в новом качестве.

В настоящее время идет развитие тех компонентов языка, которые связаны с обменом данными по Сети. Недостатки протокола передачи гипертекстовых документов HTTP (HyperText Transfer Protocol) достаточно очевидны, поэтому ему постоянно ищут замену. Светлое будущее Web - это, по-видимому, возможность динамического изменения протокола в течение сеанса работы. И здесь у Java есть все шансы на успех.

Если немного "подняться" над HTML и взглянуть на Web-технологию чуть шире, то мы увидим, что стройность картины постоянно нарушают попытки использования различных новых типов данных для построения в Web "живых" объектов. Первоначально это были просто картинки. Для их просмотра браузер запускал специализированные программы, которые не были его компонентами (так была реализована схема, например, для файлов формата JPEG). Потом то же самое стали делать для файлов видеоформата MPEG. Затем появился язык моделирования виртуальной реальности VRML, который сначала по аналогии с HTML называли не "Modelling", а "Markup".

Для работы с VRML потребовались специализированные браузеры, так как при современном состоянии вычислительной техники (главным образом ПК) совместить в одной программе интерпретацию языков HTML и VRML нельзя - может не хватить оперативной памяти или ресурсов процессора. В результате появился динамический обмен данными между двумя программами. Реально все это выглядело (да и сейчас выглядит) как довесок к Web - опять появляется набор приложений с разной логикой интерфейсов, как в пакете MS Office.

Появились модули pасшиpения - программы, которые, не будучи частью браузера, тем не менее общаются с ним. Раз общаются, значит, кроме всего прочего, могут получать и параметры области, в которую должны отображаться данные. Окно программы размещается внутри страницы HTML и "продергивается" при скроллинге вместе со всем документом. Итак, мы получили еще один объект браузера. Снова контейнерный подход себя полностью оправдал. Таким образом, мы опять оказываемся внутри браузера, дополненного новыми контейнерами и новыми возможностями.

Отметим попутно, что Microsoft следует тем же путем, что и остальные фирмы, но пока слегка запаздывает. Сначала появился динамический обмен данными между Interent Explorer и другими приложениями Office. Логика этого шага понятна: есть существующий Office, дополняем его еще одной программой для работы с Web - и получаем новый Office. Но технология plug-in позволяет браузер сделать универсальной офисной оболочкой. И что мы видим? Microsoft заявляет, что новый Interent Explorer заменит интерфейс операционной системы Windows 95. Любопытное решение, если учесть, что Windows NT - самая перспективная операционная система, выпускаемая Microsoft - только что "примерила" на себя пользовательский интерфейс Windows 95 в версии 4.0. Имея в руках самые популярные операционные системы, с которыми работает подавляющее большинство пользователей, компания заинтересована в том, чтобы технология оказалась привязана к этим решениям. Но "Паутина" построена таким образом, что она не зависит от платформы. Это было заложено изначально. Бернерс Ли объединял разные среды, а не строил информационную систему для одной конкретной ОС. Если это качество Web удастся сохранить, то решения от Microsoft никогда не будут доминировать в Сети.

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

Последнее обстоятельство чрезвычайно важно для внедрения XML в практику Web. Первоначальная спецификация SGML не нашла широкого применения, так как для большинства авторов Web-страниц она оказалась слишком сложна. Упрощенная версия SGML - язык XML - имеет шансы закрепиться, если ее поддержат разработчики браузеров.

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

Итак, подведем итоги. Контейнерная концепция HTML позволила постепенно, на протяжении последних пяти лет, наращивать технологические возможности Web. Начав с описания языка на SGML, Тим Бернерс Ли определил логику развития своего детища на все эти пять лет. Сегодня круг замыкается, и все вновь обсуждают вопрос о языке SGML и возможностях его применения для разметки документов "Паутины".

XML-производители поддерживают Гейтса

Похоже, производители программного обеспечения верят, что не за горами тот день, когда технология позволит вести более точный и полезный поиск в документах, опубликованных в Web. Это станет возможным благодаря развитию стандарта XML, о поддержке которого публично заявил глава компании Microsoft Билл Гейтс. На недавней конференции в Сан-Франциско Гейтс участвовал в демонстрации приложения, опирающегося на XML. Для проведения презентации он использовал браузер Internet Explorer, а также ориентированное на XML ПО компании ArborText, с помощью которого осуществлялся доступ к интерактивной версии журнала The Wall Street Journal.

Как известно, формат XML, представляющий собой подмножество давно утвержденного языка разметки Standard Generalized Markup Language, обеспечивает простой доступ через Web к SGML-документам. Есть все основания полагать, что модель данных XML позволит более гибко организовывать взаимодействие между Web-приложениями и получать более точные, чем при использовании стандарта HTML, результаты поиска в Web.

По словам Дона Тьема, вице-президента GCA по маркетингу и коммуникациям, "в отрасли наблюдается немалый интерес к XML. Можно твердо надеяться, что XML станет расширением SGML, обеспечивающим большую интероперабельность с HTML и Web". "В первую очередь XML будет способствовать сокращению затрат на создание более функциональных, более интерактивных, более мощных и в конечном итоге более критически важных бизнес-приложений на Web", - считает П. Дж. Барлетт, вице-президент по маркетингу компании ArborText.

Что касается поддержки XML в наиболее популярных браузерах, то сейчас Internet Explorer 4.0 этот формат подерживает в ограниченном масштабе. Корпорация Netscape Communications обещает реализовать ее в будущей версии своего Web-браузера Navigator. "Мы будем поддерживать XML в новых продуктах, - отметил Эскарт Уолтер, менеджер по маркетингу компании Netscape. - Это действительно большое дело". Уолтер убежден, что Netscape не опоздает со своими XML-продуктами, поскольку, по его словам, "сейчас просто не существует информационного наполнения на XML". По его мнению, сейчас важно понять, что может и чего не может XML. "Если вы рассматриваете XML как замену HTML, то не стоит обольщаться, поскольку роль XML в этом случае будет отнюдь не главной", - считает он.