xmlhack.ru logo
>> статьи на xmlhack.ru

Микроформаты в контексте их применения

Автор: Юч Огбуджи
Перевод: Кондаков Валерий
Опубликовано на XML.com (26.04.2006, англ.): http://www.xml.com/pub/a/2006/04/26/microformats-grddl-rdfa-nvdl.html
Опубликовано на xmlhack.ru (30.04.2006, рус.): http://xmlhack.ru/texts/06/microformats/microformats.html
В закладки:   Del.icio.us   reddit

Вокруг XML часто возникали дискуссии, как сильно затронет (или затронула) нас революционная расширяемость, обещанная разработчиками XML. Является ли на самом деле XML инструментом создания специализированных языков, предназначенных для удобного представления информации в большинстве естественных форматов? Или же это всего лишь способ облегчить труд тех, кто пишет код для обработки веб-контента (будь требователен к тому, что получаешь, чтобы не тратить время на ерунду). Предоставляют ли схема-технологии инструменты управления гибкостью, которую даёт XML, или попросту являются ещё одним орудием, направленным против пользователей («Невалиден. Уходи»)? Конечно же, мой способ постановки данных вопросов, отражает мои собственные убеждения. Я полагаю, что XML должен быть инструментом, привносящим в сеть выразительность и контролируемое разнообразие. Я решительно не согласен с мнением, не так давно выраженным в некоторых кругах, что существует лишь несколько жизнеспособных форматов XML, и что люди должны прекратить попытки создавать новые. Ключевым предметом данного спора является свежая изюминка Web 2.0: микроформаты. Если вы всё ещё не знакомы с этим явлением, сперва прочтите «Что такое микроформаты».

Этот мир — мир границ

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

К несчастью, изменений редко удаётся избежать на практике. Многие основанные на XHTML микроформаты, которые мне довелось видеть, злоупотребляют семантикой XHTML. Есть тенденция особенно злоупотреблять a/@rel. Рекомендация HTML 4.01, чью семантику перенял XHTML, утверждает:

Этот атрибут описывает связь данного документа и якоря, определённого атрибутом href. Значением данного атрибута является разделённый пробелами список ссылочных типов.

Микроформат такой, как Гугловское rel='nofollow', доводит использование данного определения до абсурда. «Не ходите по данной ссылке» — это инструкция агенту пользователя (наиболее вероятно, что автоматизированному агенту, например, индексно-поисковому роботу). Этот факт соотносится с тем, что в спецификации XLink имело название «actuation», и очень сильно отличается от абстрактного взаимоотношения между двумя документами. Я потороплюсь добавить, что лагерь приверженцев микроформатов, в общем, признал существование этих проблем, и что существуют некоторые довольно обоснованные варианты использования a/@rel в микроформатах, включая rel-license и rel-tag. И вот, опять мы сталкиваемся с rel-обёрткой, которая всё ещё признаётся недоработанной, однако даёт повод злоупотреблять a/@rel без каких-либо извинений в спецификации. Злоупотребление a/@rev в микроформатах типа vote-link являет собой ещё более отвратительный пример. И прежде, чем вы отбросите мои претензии к злоупотреблению существующими конструктами XHTML как слишком изысканные и оторванные от реальности, примите во внимание, что это может привести к довольно серьёзным проблемам в случае возникновения конфликта между микроформатами.

Подсудимый rel, пожалуйста, встаньте!

Существует невероятно много атрибутов XHTML, от которых можно оттолкнуться, и, если вы можете подогнать семантику каждого атрибута под свои нужды, вам неизбежно потребуется использовать несостыкующиеся микроформаты. Представьте, что у вас есть веб-лог, который автоматически подставляет rel='nofollow' на ссылки в комментариях для того, чтобы воспрепятствовать их использованию для рассылки спама. Комментарий в этом случае может выглядеть так, как приведено ниже.

<p>Приятный блог. Прикупите себе medz <a href='http://medz.com' rel='nofollow'>here</a></p>

Однако, у вас есть ещё один инструмент, который ищет личные ссылки внутри вашей организации и отмечает их, используя обозначение «коллега» в микроформате XFN.

<p>Я всего лишь хочу удостовериться, что ваши читатели знают, что мы
обеспокоены проблемами стабильности последней версии. Я запостил несколько обходных приёмов в
<a href='http://mf-wizards.com/~jdoe/' rel='colleague'>моём собственном блоге</a>.</p>

Теперь вам есть, над чем поразмыслить. Конечно же, вы не можете использовать два атрибута rel в одном и том же элементе. вы могли бы выставить приоритеты, чтобы аннотация XFN переопределяла rel-nofollow (это, возможно, то, что вам и нужно на практике), однако, это приведёт к тому, что ваши микроформаты внезапно перестанут быть по-настоящему независимы, и, конечно же, потеряют модульность. Микроформатный инструментарий должен учитывать, что различные спецификации могут конфликтовать между собой, и вы можете получить несколько негативный результат. В качестве обходного пути вы можете использовать NMTOKENS, в результате чего после применения обоих иснструментов комментарий будет выглядеть следующим образом:

<p>Я всего лишь хочу удостовериться, что ваши читатели знают, что мы
обеспокоены проблемами стабильности последней версии. Я запостил несколько обходных приёмов в
<a href='http://mf-wizards.com/employees/jdoe/' rel='colleague nofollow'>моём собственном блоге</a>.</p>

Одна из проблем в том, что, если вы имеете микроформат, например, XFN, который заведомо позволяет использование нескольких токенов в a/@rel, всё ещё могут возникнуть коллизии, поскольку неясно, какие из токенов являются частью XFN, а какие связаны с другими конвенциями. Так возникает проблема установления границ владения между форматами. XFN определяет rel='date' как утверждение, что вы имеете романтические отношения с персоной, представленной ресурсом, обозначенным с помощью тэга href. Но это может вызвать некоторую корреляцию с микроформатом, который описывает календарные ресурсы, и в котором rel='date' будет иметь явно иное значение.

У.Р.О.Д.С.Т.В.О. У тебя нет оправданий...!

Другая проблема, произрастающая из ограниченности основного языка, в том, что вы часто используете очень запутанные и безобразные конструкты, чтобы побыстрее подогнать результат. Очевидным примером является XOXO. Я однажды проводил исследование XOXO как языка для обмена списками веблогов, более предпочтительного, чем общепринятый, хотя и довольно некрасивый, OPML. В результате я получил нечто похожее на то, что приведено в листинге 1.

Листинг 1: Пример списка веблогов на языке XOXO

<ol class="xoxo">
  <li>
    <p>Technology</p>
    <ol>
      <li>
        <ul>
          <li>
            <a href="http://weblog.foo" type="text/html">Weblog home</a>
            <a href="http://weblog.foo/atom" type="application/atom+xml">Web feed</a>
            <dl>
              <dt>description</dt>
              <dd>That good ole Weblog</dd>
            </dl>
          </li>
        </ul>
      </li>
    </ol>
  </li>
</ol>

XHTML не был создан специально для отображения списков источников, так что XOXO является довольно массивной надстройкой над базисом XHTML. Текст результата объёмен и трудночитаем. Я описываю ужасы XML, обнаруженные мной, и одним из самых распространённых примеров абсурда является то, что я называю «обходной путь разметки». Разработчики иногда пытаются игнорировать основы, на которых строится расширяемость XML, и придумывают форматы, структура которых полностью самобытна, и вся разметка, по сути, становится контентом. Обычным подозреваемым является раздутый перевод файла CSV.

<product>
  <property>
    <name>ID</name>
    <value>xyz123</value>
  </property>
</product>

вместо <product xml:id='xyz123'/>. Крайняя степень этой глупости — использование <element name="description">... вместо <description>.... Но что ещё более поражает, XOXO ещё сильнее портит картину, превосходя эту глупость таким прибамбасом:

<dl>
  <dt>description</dt>
  <dd>My favorite Weblog</dd>
</dl>

Так и хочется использовать вместо этого просто <description>Weblog</description>. Но не только уродство кода являет собой проблему. Вторая проблема с обходными путями разметки заключается в том, что вы противостоите самой идее XML и инструментам общего назначения, которые были разработаны для поиска ключей к структуре среди элементов, а не в контенте. Обходные пути разметки так же затрудняют обработку, и в этом состоит самая распространённая проблема микроформатов. Eve Maler указал мне в личной беседе, что эта проблема была типичной с самого момента рождения SGML, и её корни в ощущении ложной экономии, которое испытывают люди, считая, что меньшее разнообразие тегов снижает нагрузку.

Если вместо XHTML я буду использовать XBEL, словарь XML, который специально разработан для отображения списков ссылок, я получу более привлекательный результат, приведённый в листинге 2.

Листинг 2: Обновление листинга 1 (список веблогов) с помощью XBEL с дополнениями

<folder>
  <title>Technology</title>
  <bookmark href="http://weblog.foo">
    <title>Example Weblog</title>
    <info>
      <metadata owner="webfeeds">
        <link href="http://weblog.foo/atom" type="application/atom+xml"/>
        <description>That good ole Weblog</description>
      </metadata>
    </info>
  </bookmark>
</folder>

Я могу добиться ещё более хороших результатов, если создам специализированный словарь для веблогов, как показано в листинге 3.

Листинг 3: Обновление листинга 1 (список веблогов) с помощью специализированного формата XML

<folder>
  <title>Technology</title>
  <weblog href="http://weblog.foo">
    <title>Example Weblog</title>
    <webfeed href="http://weblog.foo/atom" type="application/atom+xml"/>
    <description>That good ole Weblog</description>
  </weblog>
</folder>

Преимущество, конечно же, в том, что, поскольку я использую XML, мне легко перекодировать листинги 3 и 2 к листингу 1, неважно, буду ли я расширять для этого XHTML, используя XSLT, или создавать эквивалентное представление с помощью CSS. Почти все современные браузеры поддерживают по крайней мере XML и CSS, так что это никак не отразится на пользователях.

Так в чём же разница? Достаточно интересно, что любители микроформатов сильно сокращают философию читабельности кода, в основе которой лежит идея, что лучшие стандарты в сети должны быть простыми и легко читаться с тем, чтобы разработчик или автор контента мог легко найти страницу для подражания, прочесть код страницы и сымитировать конструкты. Парадокс в том, что ограничения микроформатов делают их применение неудобным вне простейших задач, а потому не удовлетворяют философии просмотра кода. Сильно специализированными форматами, или, по крайней мере, расширениями к существующим форматам намного легче пользоваться при чтении случайного кода.

Поиск смысла

Одной из проблем, которые не рассматриваются при изучении техники микроформатов, является автоматический поиск семантики. Вы можете узнать значение соглашений в микроформате, читая спецификацию на формат. Но только так и не иначе. Если от образца вы добрались до основного формата, который подозрительно похож на микроформат, у вас нет способа узнать, для чего он предназначен, и каковы его правила, пока вы не найдёте с помощью вами предпочитаемого поисковика спецификацию на микроформат. Но даже, если вам удалось найти спецификацию, она почти всегда содержит лишь неформальное описание соглашений. Часто в ней нет схемы, или же в ней нет схемы, структурированной настолько, чтобы помочь вам автоматизировать использование формата.

Есть ограничение, которое, как мне кажется, сослужит добрую службу микроформатам. Поиск и семантика — две тяжёлые задачи, и микроформаты никогда бы не достигли успеха, пытаясь их решить, если бы XML не пытался решать проблему семантической читабельности, а также проблему синтаксической читабельности. Микроформаты очень сильно привязаны к синтаксису, и те, кто нуждается в формализации и структурированности, могут идти от основ. В этой статье я заостряю внимание на соображениях относительно связи синтаксиса и микроформатов, однако некоторые из этих соображений связаны с семантикой и построены на том, как семантика может быть внедрена в микроформаты.

Основным стержнем этих строк является Сбор Описаний Ресурсов из Языковых Диалектов (Gleaning Resource Descriptions from Dialects of Languages или GRDDL). GRDDL это первый шаг (предпринятый в основном сотрудниками W3C), чтобы привязать микроформаты к RDF-моделям. Это представляется особенно интересным, поскольку держится на простой идее, к которой мои коллеги из компании Fourthought пришли четыре года назад и внедрили как функциональную возможность в сервер 4Suite и в хранилище (Эрик ван дер Влист независимо преследовал похожие цели почти в то же время). Идея состоит в том, чтобы использовать преобразования XSLT для преобразования прежнего чистого XML к RDF/XML, таким образом, проложив мостик от синтаксической до формализованной синтаксической модели. Однако, самым важным вкладом со стороны GRDDL было соглашение, чтобы основной язык отображал с помощью URI, какие микроформаты используются в сущности документа. Пример использования профиля GRDDL для XHTML приводится в листинге 4.

Листинг 4: Документ XHTML, использующий микроформат XFN и GRDDL

<html xmlns="http://www.w3.org/1999/xhtml">
  <head profile="http://www.w3.org/2003/g/data-view">
    <title>Some Document</title>
    <link rel="transformation"
       href="http://www.w3.org/2000/06/dc-extract/dc-extract.xsl" />
    <link rel="transformation"
       href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl" />
  </head>
  <body>
  ...
    <div class='blogroll'>
      <a href="http://chimezie.ogbuji.net/" rel="brother met">Chimezie</a>
    </div>
  ...
  </body>
</html>

Профиль предписывает использовать атрибут profile="http://www.w3.org/2003/g/data-view" в элементе head так, чтобы обработчики GRDDL знали, что документ следует этому соглашению. Профиль также дозволяет парсинг некоторых элементов link с rel="transformation", каждый из которых определяет преобразование от синтаксиса, провозглашённого в XHTML, к RDF/XML, с целью создания модели. Листинг 4 использует XFN и, таким образом, предоставляет ссылку для соответствующего преобразования в http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl. Также существует ссылка преобразования в http://www.w3.org/2000/06/dc-extract/dc-extract.xsl, которая не связана ни с каким микроформатом, но связана с самим XHTML. Она выделяет из XHTML легко доступные метаданные Dublin Core, например, описание заголовка документа (из элемента title), имя автора или дату (из соответствующих элементов meta). Это подчёркивает, что GRDDL более важен, чем микроформаты. На деле, если вы предпочитаете расширения к XHTML микроформатам, вы также можете использовать GRDDL для расширения и извлечения RDF.

GRDDL налагает дополнительное условие на спецификации микроформатов, в частности, трансформацию XSLT к RDF/XML. Чаще всего это не вызывает проблем, поскольку авторы микроформатов обычно знают, что делают, и, даже в худшем случае они могут получить помощь от кого-нибудь ещё, чтобы написать преобразование. GRDDL также накладывает дополнительное бремя на пользователя микроформатов: атрибуты профиля и ссылки преобразований в заголовке документа. Это вызывает больше проблем, поскольку большинство авторов в сети не любят заботиться о таких деталях. Идея GRDDL профилей может помочь решить проблемы поиска и семантики микроформатов, хотя было бы неплохо увидеть другие виды ссылок, как то ссылки на схему или даже на спецификацию микроформата, которые GRDDL ещё не упоминает. Остаётся выяснить, возьмут ли авторы на себя обязанность прописывать информацию профиля в заголовках документов. Поскольку предоставление этих ссылок недвусмысленно отражает синтаксис, возможно, адвокатам GRDDL придётся убеждать разработчиков инструментария делать в нём соответствующие небольшие необходимые изменения.

Более радикальное средство

GRDDL создавался для того, чтобы легко разобраться с основными форматами, микроформатами, распространёнными расширениями и почти со всем, что может быть сотворено в синтаксисе. RDF/A является похожим начинанием, однако представляет собой более радикальное средство отвязаться от микроформатов. Вообще-то, RDF/A появился раньше микроформатов и GRDDL. Он появился как синтаксис RDF, который мог быть более дружественным к авторам, поскольку выражен в XHTML. Недавно он изменил своё название, некоторые из своих целей, и получил некоторую поддержку из-за возни с микроформатами. Поскольку вы можете представить себе, что GRDDL является мостиком от микроформатов к RDF, вы также можете представить себе, что RDF/A первым перетащил микроформаты на берег RDF. Микроформат rel-license предписывает, что ссылка особенным образом относится к лицензии на исходный документ.

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Some Document</title>
  </head>
  <body>
  ...
    <p>This document is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by-nc/2.5/">
  Creative Commons Non-Commercial License
</a>.
    </p>
  ...
  </body>
</html>

Потребуются совсем незначительные изменения, чтобы привести это к RDF/A

<html
  xmlns="http://www.w3.org/1999/xhtml"
  xmlns:cc="http://creativecommons.org/licenses/">
  <head>
    <title>Some Document</title>
  </head>
  <body>
  ...
    <p>This document is licensed under a
<a rel="cc:license" href="http://creativecommons.org/licenses/by-nc/2.5/">
  Creative Commons Non-Commercial License
</a>.
    </p>
  ...
  </body>
</html>

rel="cc:license" более предпочтителен, чем rel="license", если обьявлять перед этим пространство имён http://creativecommons.org/licenses/. Вот ещё один пример насыщенного проблемами использования QNames в контексте, но он основан на наследии RDF/XML и используется для конструирования предикатных ссылок RDF таким же образом, как в RDF/XML используются конструкты QName.

Изменение лицензионных отношений таким образом улучшает точность поиска и средства семантики. Простанство имён может быть воспринято в качестве ссылки и быть разыменовано, чтобы получить больше информации об использовании, и эти ссылочные отношения не будут коррелировать с любыми другими видами отношений. Основная проблема синтаксиса, влияющая на микроформаты, также преследует RDF/A. Расширяя RDF до размеров XHTML, можно получить очень уродливые результаты. Если вы хоть отчасти обеспокоены разработкой XML, или хотя бы читабельностью, вас ещё много раз передёрнет, пока вы читаете примеры в учебнике по RDF/A.

Как я уже упоминал, со стороны микроформатов было правильным шагом начать сильно беспокоиться о синтаксисе через семантику. Я считаю, что, поскольку микроформаты набирают популярность, люди начнут скучать по помощи, которую оказывают более формальные семантики в задачах обмена и преобразования данных. Кажется, что микроформаты кодируют лишь небольшие островки относительно неформального контекста, тогда как GRDDL and RDF/A, как кажется, собирают эти островки в распределённые модели, чтобы сформировать основу семантической сети. Было бы неплохо иметь управляемого при помощи схемы посредника между этими двумя подходами, который бы позволял аннотировать значения конструктов микроформатов (приходит в голову Схематрон как очень плодотворная технология в данном контексте), предоставляя помощь в обработке, если не аггрегацию, которая могла бы затем делегироваться в отдельный слой RDF (возможно, через GRDDL).

Форма есть функция

В то время, как я заканчивал первый черновик данной статьи, Norm Walsh написал пост в веблоге, в котором отобразил некоторые мысленные эксперименты на тему средств определения микроформатов. Он полагает, что «проблема [определения] должна быть решена до того, как микроформаты станут признанным средством отображения данных». Я с ним согласен, и было очень интересно читать его пост. Особенно интересно, поскольку он отражает мои собственные мысли, высказанные выше. Во-первых, чтобы сделать структуру документа более приспособленной для определения, он написал преобразование, которое позволяет превратить токены, спрятанные в атрибутах классов, в основные идентификаторы тэгов XML. Это отражает то моё предположение, что основанность микроформатов на структуре, спрятанной в атрибутах, делает обработку более сложной, чем при использовании XML. По крайней мере один из комментаторов поста отметил, насколько лучше стал преобразованный контент, что пересекается с моими взглядами о читабельности. Norm также должен был столкнуться с случаями семантических коллизий между конструктами в различных микроформатах (в этом случае, даже между двумя форматами, созданными одним и тем же автором). В его заметке акцент сделан в большей мере на обработке синтаксиса, я же в данной статье акцентируюсь на его выразительности.

G. Ken Holman указал мне в частном письме, что новый стандарт ISO/IEC 19757-4 Язык Координирования Обработки, Основанный на Пространстве Имён (Namespace-based Validation Dispatching Language или NVDL) продвигает использование микрословарей (небольших, специализированных форматов XML). Вы можете внедрить их в основной язык и использовать NVDL для того, чтобы объявлять, как обработка передаётся другой схеме, основанной на пространстве имён или другой модели. Ken дал неплохой обзор этого подхода в его сообщении в списке UBL.

Прискорбно, что микроформаты и RDF/A упрощаются до настолько ужасного уровня при использовании XML в нетривиальных случаях. Хорошее использование XML в разработке интересует не только борцов за чистоту языка. Читабельность и прозрачность имеют важное значение, и в этом состоит основная цель XML. Поддержке XML в браузерах только сейчас начинают придавать значение настолько, чтобы начать использовать технологии так, как их следует использовать. Нет совершенно никакой причины, почему модули или специализированные диалекты XML с присоединёнными к ним модулями CSS не могут использоваться вкупе с основными языками. Существует проблема, заключающаяся в том, что основные языки не всегда легко расширяемы; в случае XHTML, если говорить технически корректно, вам следует самим попробовать создать модуль DTD, который вступает в конфликт со строгими стандартами. На практике, как бы то ни было, в сети валидация используется не так часто. Если бы мы могли смешивать профили GRDDL и использовать больше типов ссылок с последующим преобразованием в RDF, то это был бы мостик к полуавтоматической обработке данных. Такая комбинация могла бы быть по-настоящему лакомым кусочком, на основе которого сообщества практиков могли бы разделять скромные сильно акцентированные соглашения, не прекращая распространять разметку невероятно высокого уровня. Это бы потребовало почти всех ресурсов для новой технологии. Это было бы стало причиной первокласному умению заинтересовать сообщество пользователей, и на этом пути революция микроформатов преподала нам хороший урок.

Ссылки от xmlhack.ru



XML.com Copyright © 1998-2007 O'Reilly Media, Inc.
Перевод: xmlhack.ru Copyright © 2000-2007 xmlhack.ru