Файл: Языки гипертекстовой разметки (Определение основных понятий).pdf

Публичная дискуссия о возможностях HTML проходит на (архивы ).

Английская версия этой спецификации является единственным нормативным документом^[10]. Однако переводы этого документа можно найти по адресу: http://www.w3.org/MarkUp/html4-updates/translations.

Сценарии - ключевое средство интерактивного взаимодействия в вебе, однако в спецификации HTML механизмы их создания не были определены достаточно хорошо. В результате браузеры обрабатывают сценарии во многом несогласованно. К счастью, в HTML 4.0 реализов ан более полный подход.

Одно из наиболее важных изменений заключается в спецификации сценариев на веб-страницах. Элемент meta позволяет определить заданный по умолчанию язык сценариев для всех сценариев страницы. Это делается с помощью спецификации значения в заголовке Conte nзаданное по умолчанию значение, браузер попытается извлечь его из соответствующего поля фактического заголовка HTTP, установленного веб-сервером. После определения языка сценария для сценариев указывается тип со держимого MIME. Чаще всего типом содержим ог(сценарий VBScript) или text/javascript (сценарий JavaScript), однако можно использовать и другие допустимые типы, такие, как text/tcl (сценарий TCL)^[11].

Чтобы указать в качестве заданного по умолчанию языка JavaScript, используйте выражение:

<meta http-equiv="Content-Script-Type" content="text/javascript">

С помощью элемента script можно переопределить используемый по умолчанию язык сценариев в любом месте страницы, однако атрибут language в данной спецификации HTML применять не рекомендуется. Вместо этого нужно использовать атрибут type, позволяющий задат ь тип содержимого MIME для сценариев, например, . Между тем, не следует забывать, что при указании атрибута type некоторые старые браузеры не смогут правильно обрабатывать ваши сценарии. Пока все это урегулируется, нужно имет ь в виду, что, хотя атрибут type вполне законен, он не является обязательным.

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

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

<a href="main.html" onmouseover="show('Посетите нашу адресную страницу')">Main</a>

Когда указатель мыши перемещается на фиксированный текст, вызывается функция show(), и этот текст передается ей. Как вы обнаружите на практике, лучше всего использовать атрибуты именно так, когда одна и та же функция вызывается многократно.

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

3.2. О спецификации XML

Стандарт Расширяемого Языка Разметки (XML) задает формат данных, но вопрос о том, какие данные следует сохранять, оставляет совершенно открытым. Формат хранения данных весьма гибок, предусматривая отображение произвольно сложных типов данных^[12].

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

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

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

Спецификация SGML определенного языка разметки называется Описание Типа Документа, или DTD. Например, спецификация HTML существует как группа SGML DTD, каждое из которых определяет, что именно является или не является допустимым в данной разновидности HTML. Спецификация XML позволяет пользователям создавать свои собственные DTD, с некоторыми ограничениями. Однако различным XML документам не требуется иметь каких-либо общих элементов.

Это поднимает вопрос о различии между корректным XML и допустимым XML. Документ, который подчиняется сугубо синтаксическим требованиям (компоновка знаков больше и меньше и использование сущностей (entities)) XML, корректный вне зависимости от содержащихся в нем сущностей или элементов. "Корректность" не зависит от отдельного DTD, это особенность, которую XML документ может иметь без ссылки на DTD, или даже если документ нарушает данный DTD. Документ, который соответствует описаниям элементов конкретного DTD, называется "допустимым".

Допустимый XML может, в принципе, быть использован определенным приложением, которое владеет данным DTD. Знание того, что файл XML корректный, не столь полезно; это гораздо точнее, чем сказать: "формат наших данных - ASCII", но сталкивается с теми же принципиальными ограничениями. Однако даже допустимый XML файл может быть написан для DTD, который может быть недоступен для пользователей, делая его совершенно бесполезным. Мог бы существовать DTD, под которым следующий элемент XML был бы допустимым:

<zz><y/><x>183af892</x><w/></zz>

Спецификации XML сейчас не всегда выражаются через DTD; Microsoft® предложил новый способ выражения тех же типов понятий, называемый XML Схемами. XML Схема стала стандартом W3C в 2001 году. Сами XML Схемы написаны в XML и предназначены, чтобы разобраться с некоторыми проблемами, которые люди имели с традиционными DTD. Возможно, наиболее значительным является больший простор для определения типов данных и семантического содержания. Например, заданные "даты", которые предписывают порядок таких компонентов, как год месяц и день. XML Схемы дают больше семантического содержания, чем традиционные DTD, помогая заполнить пробел между "допустимым" и "понятным". Они также могут определить дальнейшие ограничения на содержание, такие как приемлемый диапазон для числовых значений.

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

В августе 1997 RFC 2376 были утверждены MIME типы для XML-ресурсов: text/xml и application/xml. Поэтому XML документы могут передаваться по HTTP и отображаться программой просмотра также, как и обычные HTML- страницы. Для этого нужно немного изменить конфигурацию Web-сервера (в Apache - добавить в файл mime.types строчку "text/xml xml ddt"), а на стороне клиента иметь броузер, поддерживающий стилевые таблицы или JavaScript. Сегодня такими броузерами являются Microsoft Internet Explorer 5, первый броузер, поддерживающий спецификацию XML 1.0 и стилевые таблицы XSL; броузер Amaya, предлагаемый консорциумом специально для тестовых целей (http://www.w3.org/Amaya/User/BinDist.html) и поддерживающий практически все разрабатываемые стандарты W3C. Поддержка XML также планируется в будущих версиях Netscape Navigator^[13].

3.3. О спецификации XHTML

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

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

Постоянно вводятся альтернативные методы доступа в Интернет. По некоторым оценкам, в 2002 году 75% обращений к документам в Интернет будет выполняться с альтернативных платформ. Семейство XHTML создавалось с учетом общей совместимости пользовательских агентов. С помощью нового механизма профилирования пользовательских агентов и документов серверы, прокси и пользовательские агенты смогут преобразовывать содержимое наилучшим образом. В конечном счете станет возможной разработка соответствующего XHTML содержимого, пригодного для любого соответствующего XHTML пользовательского агента^[14].

Спецификация XHTML 1.0 была одобрена в качестве рекомендации консорциума Всемирной паутины в январе 2000 года. В августе 2002 года была опубликована вторая редакция спецификации — XHTML 1.1. Параллельно полным ходом началась разработка XHTML 2.0, призванного стать новым уровнем представления документов во Всемирной сети. Разработчики пошли на довольно смелый шаг — нарушение обратной совместимости, но нововведения, которые они собирались внести, стоили того. XHTML 2.0 содержит спецификации Xforms, Xframes, призванные заменить стандартные HTML-формы и фреймы соответственно, ML Events — API для управления DOM-структурой документа, встроенную поддержку модулей Ruby character и многое другое. Работа шла полным ходом, но было несколько обстоятельств, совершенно не радующих авторов спецификаций. Если коротко, XHTML просто не получил должного распространения.

Во-первых, огорчали веб-разработчики, которые после вольницы HTML никак не хотели принимать новые правила в полном объеме. Расставлять в нужном месте кавычки и сущности оказалось просто непосильной задачей. Что там говорить про XHTML, если и со стандартами HTML4 веб-верстальщики обходились достаточно вольно. И что самое возмутительное — производители браузеров активно им в этом потакали!

И именно в этом заключалась вторая проблема. На самом деле все довольно понятно — те, кто делали браузеры, просто не могли допустить, чтобы какой-либо значимый контент в них был не доступен пользователю из-за каких-то неясных принципиальных соображений, и, надо сказать, они были по-своему правы (ну в самом деле, веб нам нужен для общения с миром, а не для т ого, чтобы все атрибуты были снабжены кавычками!). В результате наиболее популярные браузеры имели два режима отображения XHTML-документов, причем по умолчанию обычно работал «нестрогий» режим, при котором огрехи в разметке милосердно прощались. Хуже того, безусловно, самый распространенный на тот момент браузер Internet Explorer вообще не реагировал на MIME-тип application/xhtml и не имел в своем составе парсера обработки XHTML-документов вплоть до восьмой версии.

Главная причина неудачи повсеместного внедрения XHTML довольно проста. Строгие правила валидации, атрибуты, взятые в кавычки, закрытые одиночные теги… все это, может, и хорошо, но нужны эти тонкости в основном самим разработчикам и блюстителям стандарта, но никак не пользователям, которым, строго говоря, дел нет до всех этих тонкостей. И никак не создателям веб-контента, которым эти правила попросту ничего не дают, кроме несильной головной боли. В общем, сложилось что-то вроде революционной ситуации — создателям стандарт не нужен, а потребителям он не нужен тем более. А что всем им было нужно? Живой интерактивный веб-контент, воплощающий социальные потребности современного человека. Плоский мир HTML с этим справлялся плохо, и к концу 90-х на веб-странице появились не относящиеся к языку разметки компоненты^[15].

Заключение

Часто приходится слышать, что WWW - это очень просто. Однако за этой кажущейся простотой скрывается хорошо продуманная сложная система. При этом следует заметить, что система бурно развивается.

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