Конечно, многим дизайнерам с преимущественно визуальным мышлением совсем не просто перестроиться на "ортогональный стиль" разметки. Так же как нельзя уви–деть бестелесную душу, вам, возможно, трудно вообразить себе, как будет выглядеть документ, размеченный толь–ко логически, равно как и представить себе идеальную ортогональность - независимость такого "дистиллированного" содержимого от хранящегося отдельно оформления. Если даже примитивные "именованные стили" в текстовых процессорах считаются прерогативой "профессиональных пользователей", что уж говорить о более последовательных системах ортогональной разметки. Я думаю, что если бы умение воспринимать и создавать аспекты информации по отдельности было врожденным и не требовало обучения, язык SGML уже давно стал бы основным средством хранения и распространения текстов.
Режем по живому. Даже если не учитывать несовершенство HTML, в котором логический и визуальный аспекты оказались смешанными по причинам скорее историческим, соблюдение ортогональности - как и любая реализация некоей абстрактной идеи на практике - сталкивается и с вполне объективными трудностями. Бывают случаи, в которых разделительная линия между содержанием и оформлением может быть проведена по–разному: более того, иногда неудачное рассечение на аспекты документа, изначально (в сознании его автора) целостного, приводит к частичной потере информации и к невозможности в дальнейшем удовлетворительно состыковать получившиеся половинки.
Приведу пару примеров. В двумерных композициях с текстом и изображениями часть информации о связях между элементами может передаваться не последовательностью их расположения или какими–нибудь видимыми стрелками или рамками, а менее очевидными визуальными средствами - выравниванием, цветовыми перекличками, контрастом. Если композиция эта создавалась изначально в графической среде, ее автор, возможно, просто не осознает некоторые из этих связей и, соответственно, не сможет "вербализовать" их при выделении структурной основы композиции. С другой стороны, некоторые фрагменты текста относятся не к содержательной основе, а к оформительской надстройке документа: например, номер главы и само слово "Глава" в заголовке, постоянная часть перекрестных ссылок (т. е. сокращения типа "стр." или "гл."), любые повторяющиеся элементы, такие как колонтитулы на странице книги или панель навигации на веб–странице. Вынеся все это из текстовой основы документа в стилевые спецификации, вы не только упростите процедуру глобального изменения этих элементов во всем документе, но и приблизитесь к искомому идеалу ортогональности: ведь все, что при внимательном рассмотрении не принадлежит к уникальной информации документа, а лишь помогает воспринимать ее, правильнее отнести к аспекту представления, а не содержания.
Сборно–панельный сайт. Однако вернемся к HTML. Поскольку в случае этого языка одна и та же технология ответственна за оба аспекта разметки, необходимо придерживаться определенных правил, которые позволят если не разделить содержание и оформление, то по крайней мере сделать их хоть сколько–нибудь независимыми друг от друга.
На любом сайте, превышающем по размеру страницу и содержащем хотя бы одну серию повторяющихся или однотипных элементов, форматирующие коды HTML удобно собирать в унифицированные модули, или блоки, играющие роль своеобразных "тегов логической разметки", параметры оформления которых хранятся в них же самих. Внутреннее устройство таких блоков может быть в принципе любым - в частности, в них можно как угодно смешивать логические и визуальные теги HTML. Однако, чтобы построенный таким образом логический план разметки действительно облегчал создание и поддержку сайта, нужно придерживаться нескольких несложных правил:
• Экземпляры одного блока должны быть абсолютно идентичны, за исключением вставок изменяемого содержимого (например, текста заголовка в блоке заголовка).
• Общее количество разновидностей блоков должно быть минимальным, и после того как дизайн сайта устоялся, новые блоки могут вводиться в виде исключения - только когда на сайте появляется принципиально новое содержимое, не лезущее в старые "болванки".
• За пределами блоков не должно оставаться никаких "висячих" тегов, за исключением самых необходимых средств оформления текста (тег Р и логические теги типа ЕМ и STRONG).
• Каждый блок должен быть помечен в HTML-коде стандартным комментарием, который позволит легко опознать этот блок как при ручном редактировании, так и при автоматическом поиске.
Работа с таким модульным сайтом происходит в одном из двух режимов, соответствующих двум ортогональным аспектам его разметки. В "режиме содержания" можно как угодно редактировать существующий текст или добавлять новый, копируя при необходимости нужные блоки, но ни в коем случае не залезая внутрь этих блоков. Эта повседневная работа по обновлению и расширению сайта не требует никакой дизайнерской квалификации, и создатель сайта вполне может перепоручить ее обслуживающему персоналу сайта.
Наоборот, редактирование "плана представления" после того, как сайт создан и запущен, в идеале должно быть событием исключительным, осуществляющимся только под контролем дизайнера. (Например, если вдруг выяснилось, что какой–то заголовок ведет себя неправильно, когда его текст превышает по длине некую заранее планировавшуюся величину, может понадобиться изменить устройство заголовочного блока.) Это можно делать только глобальным поиском и заменой во всех файлах сайта - ведь если вы поправите вручную одну из копий блока, ее уже не найдет следующий автоматический поиск, и рассинхронизация поползет по сайту, как раковая опухоль. Программа, которой вы пользуетесь для редактирования HTML-кода, должна уметь искать и заменять многострочные блоки текста и пользоваться регулярными выражениями (regular expressions) в тех случаях, когда блок содержит вставки, изменяющиеся от одной копии блока к другой. Обе эти возможности поддерживает, например, редактор HomeSite (www.allaire.com).
Например. Описанные выше принципы были взяты за основу в дизайне сайта www.oi.com. Этот корпоративный сайт по объему и частоте обновления своего материала близок к контент–сайтам (стр. 182), и возможность свободно редактировать содержимое, оставляя нетронутым дизайн, для него особенно важна. Вот, к примеру, как выглядит блок, создающий стандартный внутритекстовый заголовок:
<! - framed heading ->
<table border=0 cellpadding=0 cellspacing=0><tr>
<td bgcolor=ffaf60<img alt="" src="e.gif" width=15 height=4></td>
<td bgcolor=ffaf60ximg alt="" src="e.gif" width=350 height=4></td>
<td bgcolor=d8d8d8 align=right valign=top rowspan=2>
<img width=16 height=26 alt="" src="zak–gob.gif"></td>
</tr><tr>
<td bgcolor=d8d8d8ximg alt="" src="e.gif" width=15 height=22></td>
<td bgcolor=d8d8d8 valign=bottom><small>THE COAD METHOD</small></td>
</tr></table>
</trx/table>
В начале блока ставится комментарий–идентификатор, а в предпоследней его строке мы видим единственный фрагмент, изменяющийся от одного заголовка к другому, - его текст (в данном случае "THE COAD METHOD"). Между собой блоки удобно разделять пустыми строками. Вся страница, показанная на рис. 1, состоит из следующих блоков (приведены только строки с комментариями):
<! - top navigation ->
<! - solid heading ->
<! - open text block ->
Peter Coad is perhaps … Reach him at pc@oi.com.
<! - close text block ->
<! - framed heading ->
<! - open text block ->
The Coad Method focuses on … frequent, tangible, working results.
<! - close text block ->
<! - decorated close ->
Модульный HTML - не только имитация имеющегося в других языках программирования структурного подхода и не только единственная реальная возможность приспособить этот язык к созданию объемных и часто обновляемых сайтов. Это еще и необходимый промежуточный этап будущей миграции к языку XML (о котором мы будем говорить чуть ниже): тем же самым глобальным поиском вы в любой момент можете заменить "псевдотеги" структурных блоков HTML на настоящие структурные теги XML, разработав для них соответствующие стилевые спецификации. Такая конверсия гораздо полнее отвечает целям и духу XML, чем приходящий в голову первым буквальный, "тег в тег" перевод HTML в формально корректный, но совершенно бессмысленный XML (стр. 51), - ведь большинству визуально–ориентированных тегов HTML в структурном языке XML нет и не может быть никаких соответствий.
XML
Как мы только что видели, модульный подход позволяет достичь в HTML определенной ортогональности структуры и представления. Конечно, гораздо удобнее было бы хранить повторяющиеся блоки визуального кода в отдельном, общем для всего сайта "стилевике", а документы размечать только ссылками на тот или иной блок - то есть, по сути, тегами логической разметки, говорящими лишь о том, что стоит в данном месте документа, а не о том, как оно выглядит.
Именно такое естественное, а не насильственно насаждаемое разделение аспектов содержания и представления предлагает язык XML (extensible Markup Language, "Расширяемый язык разметки") - компактное упрощенное подмножество языка SGML, разработанное Консорциумом W3 в расчете на постепенное вытеснение из Интернета языка HTML. Этот "HTML будущего", как его нередко называют, уже активно осваивается ведущими производителями программ, причем не только броузеров - вероятно, поддержка XML через какое–то время появится в большинстве текстовых процессоров, баз данных, систем подготовки документации, а некоторые предрекают встраивание этого языка даже на уровне операционных систем.
Итак, язык XML впервые открывает перед многомиллионной интернетовской аудиторией дверь в мир настоящей структурной разметки и подлинной ортогональности аспектов содержания и представления. В конечном итоге эта новая технология должна резко увеличить производительность труда авторов, сняв необходимость утомительного, зачастую ручного перевода информации из одного визуально–ориентированного формата в другой. Однако не обойтись на этом пути и без трудностей "перепривыкания" и ломки сложившихся стереотипов. Перейти с HTML на XML - это совсем не то же самое, что обновить версию вашего любимого текстового процессора Может показаться, что идеология ортогональности языка SGML, прекрасно работающая для устоявшихся типов документов с годами отлаживавшимися DTD, не справляется со слишком разнообразным и зачастую нелогичным содержимым современного Интернета. Вспомним, однако, что только противоречие может быть двигателем прогресса, - нам предстоит еще увидеть, как развиваются, взаимообогащаясь и изменяясь под действием друг друга, Интернет и XML…
СИНТАКСИС
Внешне XML-документ очень похож на HTML: те же угловые скобки, открывающие и закрывающие теги, атрибуты и подстановки. Но если в HTML все допустимые теги жестко заданы стандартом, то XML-документ может пользоваться любыми тегами, пусть даже изобретаемыми на ходу автором документа. Это объясняется разным статусом этих языков: если HTML есть одно из приложений SGML, его отпрыск и порождение, то XML - это подмножество SGML, его "младший брат", обладающий лишь чуть меньшими возможностями и точно так же пригодный для создания фиксированных систем разметки документов. Такие системы на основе XML действительно создаются в последнее время во множестве - от сложного языка Math ML для разметки математических текстов до простеньких наборов из пары десятков тегов для хранения кулинарных рецептов или текстов церковных проповедей.
DTD. Вся специфика HTML как одного из приложений SGML выражена в особой формальной конструкции, называемой определением типа документа (Document Type Definition, DTD). В идеале DTD - высший авторитет во всем, что касается синтаксиса той или иной версии HTML. Им, к примеру, пользуются HTML-валидаторы - интерпретаторы SGML, проверяющие соответствие HTML-документа некоторому DTD. Поскольку DTD для каждой версии HTML зафиксировано в официальной спецификации языка, в самом документе приводить его не нужно, - однако любой HTML-документ обязан ссылаться на свое DTD с помощью тега! DOCTYPE (стр. 29).
Хотя синтаксис DTD мы в этой книге рассматривать не будем, полезно знать, какая именно информация может храниться в определении типа документа:
• полный список допустимых элементов с указанием на обязательность для каждого из них открывающего и закрывающего тегов;
• полный список атрибутов для каждого элемента, с информацией об их обязательности/факультативности и значениями по умолчанию;
• иерархическая структура документа в виде ин 4 юрмации о том, какие другие элементы, в каком порядке и в каких сочетаниях (друг с другом и/или с обычным текстом) могут встречаться внутри каждого из элементов.
Например, в DTD для HTML 4.0 указано, что у элемента HTML можно опускать как открывающий, так и закрывающий теги (границы элемента устанавливаются интерпретатором по контексту), а его содержимое должно состоять из элементов HEAD и BODY, идущих именно в таком порядке. Элемент OL (нумерованный список) обязан иметь как открывающий, так и закрывающий теги, а содержимое его должно состоять из одного или нескольких следующих друг за другом элементов LI. DTD в языке XML на этом уровне рассмотрения имеет только одно существенное отличие от DTD в SGML (и HTML): все элементы XML–до–кумента без исключения обязаны иметь и открывающий, и закрывающий тег.
Важно понимать, что ни в SGML, ни в XML DTD не имеет никаких средств для задания семантики тегов, - иными словами, DTD не дает ответа на вопрос, что означает каждый тег. В каком–то смысле идеология SGML следует Людвигу Витгенштейну, которому принадлежит высказывание: "The meaning of a word is its use" ("Значение слова - это то, как оно употребляется"). Тот факт, к примеру, что тег I включает курсивное начертание, формально средствами SGML не выразим, - он лишь подразумевается авторами языка HTML и указывается в комментариях или в сопроводительной документации к HTML DTD. Именно поэтому путь, избранный в HTML, - жесткое закрепление за каждым из тегов (набор которых ограничен) некоторой "рекомендуемой" роли и параметров форматирования - несмотря на свою простоту, плохо Укладывается в рамки идеологии SGML и влечет за собой неприятные последствия. Если семантику тега невозможно определить формально, то нет ничего удивительного в том, что эффект даже простейших тегов иногда сильно различается у разных броузеров. Абстрактный вопрос "что делает такой–то тег", по сути лишён смысла - можно только выяснять, какой результат даёт применение этого тега в том или ином броузере.
Уровни соответствия. Если в SGML каждый документ обязан иметь свое DTD, а у HTML есть одно DTD на всех, то XML представляет собой компромисс: документ может иметь (или ссылаться на) DTD, а может и обходиться без DTD. В последнем случае каждый новый тег и атрибут определяются самим фактом своего употребления. Таким образом, для XML - документов существует два уровня соответствия стандарту: документы, не имеющие DTD, но удовлетворяющие всем другим требованиям синтаксиса XML, называют правильно структурированными (well–formed), чтобы отличить их от документов валидных (valid), имеющих в своем составе DTD (или ссылку на внешнее DTD).
Правильно структурированные документы, хотя и уступают по "правильности" документам валидным, годятся для большинства практических случаев. Это значит, что вы можете сразу же начать описывать структуру вашего документа на "почти человеческом" языке, выдумывая теги на ходу и заботясь лишь об их правильной вложенности:
<ПРЕДЛОЖЕНИЕ>
<ПОДЛЕЖАЩЕЕ>
<СУЩЕСТВИТЕЛЬНОЕ> мама </СУЩЕСТВИТЕЛЬНОЕ>
</ПОДЛЕЖАЩЕЕ>
<СКАЗУЕМОЕ тип="простое">
<ГЛАГОЛ> мыла </ГЛАГОЛ>
</СКАЗУЕМОЕ>
<ДОПОЛНЕНИЕ тип="прямое">
<СУЩЕСТВИТЕЛЬНОЕ> раму </СУЩЕСТВИТЕЛЬНОЕ>
</ДОПОЛНЕНИЕ>
</ПРЕДЛОЖЕНИЕ>
Как видно из этого примера, имена тегов и атрибутов можно писать и по–русски. Опыт HTML показал, сколь важна тщательная и своевременная интернационализация всех аспектов языка, претендующего на какую–то роль в Интернете. Поэтому создатели XML позаботились, в частности, о том, чтобы в именах тегов и атрибутов можно было пользоваться не только латинскими буквами, но и кириллицей, иероглифами и вообще любыми символами из репертуара Unicode, которые считаются "буквами" хотя бы в одном языке или системе письменности.
Такая разметка позволит интерпретатору XML порубить документ на кусочки в соответствии с его теговой структурой. После этого в действие вступает другое приложение - его задачей может быть, например, автоматическое индексирование документа, занесение его в базу данных или (чаще всего) форматирование в соответствии с приложенной к документу стилевой спецификацией. (В нашем примере можно было бы, скажем, раскрасить разные части речи разными цветами.) Однако важно понимать, что все эти задачи лежат уже за пределами собственно языка XML, - который, таким образом, свободен от заботы о визуальном (или каком–либо ином) представлении документа и позволяет сфокусироваться на его логической структуре.
Конверсия. Возможность использовать произвольные теги означает, в частности, что любой HTML-документ очень легко преобразовать в XML. Изменения, требуемые для этого преобразования, немногочисленны и сугубо формальны:
• все значения атрибутов должны быть взяты в кавычки;
• регистр букв в открывающих и закрывающих тегах должен совпадать (в отличие от HTML, язык XML чувствителен к регистру);