Круг задач

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

Популярность мобильных устройств растет с каждым днем, число пользователей мобильных устройств увеличивается стремительно. В странах, где число мобильных устройств достигает 80% на 100% населения (Япония, Ю.Корея, Тайвань, Гонконг, Индонезия), веб-мастера и веб-разработчики уже столкнулись с этой проблемой.

Использование мобильных устройств - это не дань моде или престижу, это в первую очередь дань удобству. В Европе и Америке пользователей пока останавливает только цена и сложность в работе этих устройств, а также - разброд в стандартах и методах представления информации. Именно благодаря решению этих проблем популярность мобильных устройств так высока в Азии. Опыт Азии уже начинает применяться в Европе и в Америке. Следовательно скоро и там веб-мастерам придется решать проблему, которая уже стоит перед веб-мастерами Азии.

В мобильном Web-е пока еще нет единого стандарта представления информации. Практически каждый производитель мобильного устройства, начиная от мобильного телефона и кончая наладонными компьютерами, поддерживает какой-то свой собственный стандарт представления информации, например, WML (для WAP), MML (J-Phone), HDML (для EZweb), CHTML (для DoCoMo), упрощенный HTML (для PDA). Почти все эти форматы несовместимы друг с другом - WAP-телефон не может показать страницу, написанную в CHTML, а PDA iPAQ не может показать страницу, написанную на WML для WAP-телефона. А некоторые родственные варианты - MML и CHTML - имеют небольшие специфические отличия. Преобразование одного формата в другой весьма трудоемкий процесс. А если учесть то, что мобильные устройства, использующие одну и ту же технологию представления информации, могут еще отличаться размерами экрана, глубиной цвета и форматом графических файлов, то число комбинаций различных вариантов страниц, которые вам придется писать вручную, достигает астрономической величины. Еще большие трудности возникают при поддержке всей этой кучи вариантов страниц. Для внесения изменения в содержание текста вам придется менять ВСЕ варианты страниц, что может превратиться в кошмар.

Есть множество подходов к решению этой проблемы, но одним из самых привлекательных является XML/XSL-технология. Состоит она в том, чтобы отделить данные (содержание) от их визуального представления (формы и формата).

XML/XSL

Схема работы XML/XSL-приложения может выглядеть так:

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

Теперь давайте рассмотрим более подробно весь процесс, состоящий из трех шагов:

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

   Как правило, эта часть цикла выполняется с помощью обычных текстовых редакторов, хотя имеются и специализированные редакторы XML-кода, несколько упрощающие работу. Некоторые поставщики СУБД оснастили свои продукты функцией непосредственной генерации XML-кода в ответ на ввод оператора select.

2. Создание XSL-таблиц.

   Вся логика обработки и вывода XML-документа заключается здесь. Задача создания XSL-таблицы не тривиальная, поэтому XSL-таблицы создаются администратором-программистом и после создания меняются уже редко.

3. Наложение стилевых таблиц XSL.

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

Химия XML/XSL

Химия на стороне клиента

Последний процесс - процесс преобразования - может выполняться на стороне клиента: новейшие броузеры понимают xml и стили для них, умеют подключать стили к xml-документам и формировать окончательный документ. Принцип работы похож на то, что происходит с html-файлом и прилинкованным к нему css-файлом. В настоящее время xml/xsl-преобразование могут выполнять IE 5+, Netscape 6, Mozilla.

Вариант преобразования на стороне клиента весьма привлекателен. Современные компьютеры достаточно мощны, чтобы справиться с такой задачей. При этом существенно сокращается нагрузка на сервер, да и стилевая таблица загружается только один раз. Однако сейчас еще рано публиковать XML-документы в Интернете "просто так" - для Web есть HTML, значит его и надо отдавать пользователю. И кроме того, что делать в случае тех броузеров, которые не понимают полноценный HTML и не могут сами выполнять xml\xsl-преобразования? Для этого приложение стиля к XML-документу осуществляется на сервере.

Химия на стороне сервера

Делаться это может двумя способами: вручную, либо автоматически.

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

Система занимается тем, что, работая на web-сервере, делает требуемое преобразование xml-документа автоматически до того, как отдать его пользователю. Технически размещение подобной системы на web-сервере ничем не отличается от установки SSI или PHP3 процессоров. При этом ресурсы у пользователя не отбираются и, что самое главное, пользователю не требуется браузер, способный выполнять xsl-преобразования. Также, если нам захочется воспользоваться самым новейшим и быстрым xml-парсером и xsl-преобразователем - нам его достаточно установить на сервере и не беспокоиться о том, например, обновил ли владелец IE5 свой парсер, что шел в комплекте с броузером, до самой свежей версии, которая соответствует стандартам W3C.

Web-сервер в этом варианте превращается в систему публикации (Publishing Framework). В отличие от обычных серверов, которые в ответ на запрос выдают файл, хранящийся на сервере, publishing web-сервер выдает "опубликованную" версию файла, которая соответствует параметрам запроса, броузеру посетителя, его настройкам и/или предпочтениям. Например, если запрос делается программой Acrobat Reader, то публикуемая страница придет к посетителю в формате PDF. WAP-устройства (Wireless Application Protocol) получат WML-старницу (Wireless Markup Language), а обычный Web-браузер - HTML-страницу, более продвинутый - XHTML-страницу.

В случае с Web-браузером можно даже выбирать между различными вариантами и даже версиями программы. И выдавать различный документ в зависимости от того, пришел ли запрос от браузера Lynx, который может показывать только текст, от Netscape Navigator 3/4.7/6.2 или от Microsoft Internet Explorer. Посетитель сайта не видит исходной версии файла (хранящейся в xml), она ему и не требуется, но в то же время он не указывает явно, что xml-файл нужно преобразовать в какую-то версию. Все это делается полностью автоматически.

Разумеется нагрузка на сервер из-за этого возрастает, но и преимущества в этом тоже есть. Один и тот же xml-документ с легкостью может быть подан как супернавороченному броузеру (IE), так и простейшему варианту (Lynx, Netscape 3), либо их микрособратьям - броузерам, встроенным в мобильные телефоны (WAP/i-mode), либо вообще таким экзотическим вариантам, как голосовым броузерам или броузерам для слепых (код Брейля). Более того с использованием особых библиотек и небольших ухищрений можно реально отделить содержание документа от его представления и подать его в виде pdf-файла или Excel-файла, gif/png/jpeg/svg - картинки.

Назад к постановке задачи

Я не веду речь о платформе для публикации любого контента для любого броузера, хотя в теории и это возможно. Контент для мобильных телефонов и для полноценных броузеров должен быть разным. Отличия заключаются в объеме подаваемой информации, в порядке и логике ее представления, в оформлении и навигации. Создателям текстов для сайта всегда придется писать разные тексты, предназначенные для обычных броузеров и для их усеченных собратьев. Если кто-то приходит к вам и говорит, что "купив наш продукт, вы сможете написать текст один раз, и он автоматически будет переделан под любой известный броузер", знайте, вам просто вешают лапшу на уши. Я могу сохранить текст "Божественной комедии" данте в HTML и вывесить на сайте, и пользователи IE и Netscape, хоть и скрипя зубами, но смогут загрузить и прочитать 200 страниц текста. А теперь представьте каково будет читать этот текст в броузере, чье окно по размеру равно спичечному коробку.

Поэтому наша цель - подать однотипный контент для разнотипных броузеров одного порядка. Либо мы создаем сайт, который сможет давать одно и то же содержание для всех полноценных броузеров (IE, Netscape, Mozilla, Opera, Lynx и проч.), либо сайт, который выдает одно и то же содержание для всех "усеченных" броузеров (различные мобильные телефоны, PDA, голосовые броузеры и проч.).

...между прочим

Кроме задач визуального представления информации, XML-технология может с успехом использоваться в решении задач обмена и хранения данных. XML может быть использован, например, для хранения конфигурационной информации. Это обеспечивается тем, что функции парсера (интерпретатора) XML встроены во многие средства разработки приложений. А самое главное, тем, что XML-документ может быть отредактирован с помощью самого обычного текстового редактора. Т.е. данные, хранящиеся в XML-документе могут передаваться из программы в программу и оставаться при этом понятными человеку (human readable).