Распутывание URI, URL и URN

В области управления информацией существует устойчивое противоречие между постоянством и доступностью.
В области управления информацией существует устойчивое противоречие между постоянством и доступностью. Это противоречие привело к появлению отдельных технологий для унифицированных имен ресурсов (uniform resource names - urn) и унифицированных указателей информационных ресурсов (uniform resource locators - url). При этом универсальные идентификаторы ресурсов (uniform resource identifiers - uri) созданы для того, чтобы выполнять функции и постоянных имен, и доступных ресурсов. В предлагаемой ниже статье объясняется, как использовать современные стандарты uri с xml-технологиями, рассказывается об истории urn и url и дается прогноз развития противоречий между постоянством и доступностью.
Присвоение имен и проблема постоянства

Интернет включает три вида технологий: форматы данных, протоколы и указатели, которые связывают первые два элемента. Связь между такими форматами данных, как xml и html, достаточно очевидна, также как и между протоколами http и ftp. Но с указателями дело обстоит несколько сложнее.

Еще лет десять назад интернет-адреса были довольно загадочным предметом, а сегодня их можно видеть уже не только в web-браузерах, но и на визитках и в брошюрах, на рекламных щитах и автобусах и даже на футболках. Они известны под названием унифицированных указателей информационных ресурсов или url. Обычно они выглядят следующим образом: http://www.cisco.com/en/us/partners/index.html. Но как быть с более короткой формой, например, www.yahoo.com/sports? Является ли она также url? А ../noarch/config.xsd? Или guide/glossary#octothorpe?

Для того чтобы правильно использовать url в пространствах имен и схемах xml, а также в расширяемом языке преобразования стилей (extensible stylesheet language transformations - xslt), нужно знать некоторые правила. Но семейство спецификаций xml оперирует такими понятиями, как uri и urn. Чем же они отличаются от url? Этот вопрос имеет довольно долгую историю.

В 1990 г. пионер компьютерных сетей и гипертекста Дуглас Энгелбарт (douglas engelbart) среди прочих требований к открытой системе гипердокументов называл и необходимость того, чтобы "каждый объект, на который кто-либо захочет или должен будет сослаться, имел однозначный адрес". Тим Бёнез-Ли (tim berners-lee), изобретатель интернета, в 1991 г. указывал в своем конструкторском документе о присвоении имен: "Синтаксис имени, по которому документ или его часть (якорь) могут быть найдены в любой точке мира, - это, вероятно, наиболее важный аспект проектирования и стандартизации в открытых гипертекстовых системах".

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

Документ rfc3986, "Универсальный идентификатор ресурсов (uri): общий синтаксис" - это стандарт интернета. Так называемая серия "Запросы на комментарии" (request for comments - rfc) - это известная серия архивных документов, которая является основой процесса разработки стандартов в Проблемной группе проектирования internet (internet engineering task force - ietf). Только несколько из тысяч документов rfc, такие как протокол управления передачей (transmission control protocol - tcp) и почтовый формат (rfc821) и протокол (rfc822) интернета получили полный статус стандартов интернета. rfc3986 получил этот статус в январе 2005 г.

Согласно стандарту uri, первый из вышеприведенных примеров - http://www.cisco.com/en/us/partners/index.html является настоящим uri и включает несколько составляющих его частей:
имя схемы (http);
имя домена (www.cisco.com);
путь (/en/us/partners/index.html).

Непротиворечивый процесс ietf управляет схемами. Официальный реестр схем uri Агентства по выделению имен и уникальных параметров протоколов internet (internet assigned numbers authority - iana) включает как общеизвестные схемы, такие как http, https и mailto, так и множество других, менее знакомых широкому кругу пользователей.

uri-путь выглядит как типичный путь доступа к файлу. uri унаследовали левую косую черту (a/b/c) из традиций unix, поскольку в конце 1980-х годов, когда они разрабатывались, в интернете преобладала культура unix, а не pc. Тогда существовало несколько распространенных представлений для доступа к удаленным файлам. Одно из них - это ange-ftp, расширение emacs для редактирования удаленных файлов. Оно сводило воедино имена хост-узла и пользователя с путем доступа к файлу, и в результате получалась конструкция такого типа: /[email protected]:~mblack/. Синтаксис uri, разработанный для интернета, использовал двойную левую косую черту для перекрестного обращения к машинам (это унаследовано из диалекта apollo domain unix). Помимо этого, он ввел в обращение синтаксис схем для того, чтобы можно было унифицировать соглашения о присвоении имен из любого количества различных протоколов. Вот несколько примеров:
mailto:mbox@domain
ftp://host/file
http://domain/path.

Второй пример во введении, www.yahoo.com/sports, на самом деле не является настоящим uri. Это удобное сокращение для http://www.yahoo.com/sports. Такой формат поддерживается пользовательскими интерфейсами распространенных web-браузеров. Но если схема xslt записана следующим образом:

,

то она не будет работать, как ожидается, если только это выражение не является обращением к файлу в директории exslt.org, находящейся рядом с таблицей стилей xslt. Атрибут href в xslt означает uri-ссылку, которая может быть абсолютной или относительной. Если uri-ссылка начинается со схемы и двоеточия, то она является абсолютной, в противном случае - относительной. Относительная uri-ссылка очень похожа на путь доступа к файлу. Например, ../noarch/config.xsd - это относительная uri-ссылка.
Международные идентификаторы ресурсов

Сказать, что атрибут href в html означает uri-ссылку, - это несколько упростить ситуацию. uri и uri-ссылки создаются из ограниченного набора символов ascii, а html является более интернациональным образованием. Запрос на комментарии, который последовал за запросом rfc3986, - это запрос rfc3987 "Международные идентификаторы ресурсов (iri)" (internationalized resource identifiers (iris) (см. раздел Ресурсы). Эта спецификация не является единственной в процессе разработки ietf-стандартов, в отличие от своей предшественницы, но данная технология уже достаточно зрелая и широко используется. iri очень похожи на uri с тем исключением, что в них может использоваться весь набор символов unicode, а не только ascii. Для каждого iri существует соответствующая кодировка в формате uri на тот случай, если идентификатор нужно будет использовать в протоколе (например, http), который может работать только с uri.
xml:base перекрывает базовый uri

Обычно ссылка uri является относительной для любого документа, в котором она найдена. Если, например, просматривается документ с базовым uri http://exslt.org/math/min/math.min.template.xsl, и в нем обнаруживается uri-ссылка ../../random/random.xml, то она приведет к документу с адресом http://exslt.org/random/random.xml. В формате html есть возможность вынести базовый элемент в заголовок документа, чтобы перекрыть базовый uri. Базовая спецификация xml (xml base) (см. раздел Ресурсы) обеспечивает эквивалентную форму в xml.

Рассмотрим документ, доступ к которому может быть осуществлен двумя путями: file:/my/doc или http://my.domain/doc. Если доступ выполняется через файловую систему, то ссылки типа #part2 расширяются до формата file:/my/doc#part2. В случае доступа через http данная ссылка расширится до формата http://my.domain/doc#part2. Но в схеме описания ресурсов (resource description framework - rdf) расширенная форма не должна изменяться для того, чтобы обеспечить выполнение ряда задач. Спецификация xml base облегчает выполнение расширения (см. Листинг 1).
Листинг 1. Расширенная форма в rdf

xmlns="&owl;"
xmlns:owl="&owl;"
xml:base="http://www.w3.org/2002/07/owl"
xmlns:rdf="&rdf;"
xmlns:rdfs="&rdfs;"
>

В этом примере ссылка #nothing расширяется до http://www.w3.org/2002/07/owl#nothing независимо от места нахождения документа.

Теперь перейдем к url и urn.
url и urn

uri разработаны таким образом, чтобы выполнять функции и имени, и адреса. После того, как они поступили в ietf для стандартизации, их стали именовать унифицированными указателями информационных ресурсов (uniform resource locators); одновременно началась работа над разработкой унифицированных имен ресурсов (uniform resource names).

Для имен и ресурсов интернет-хостов существуют отдельные стандарты. Синтаксис имен хостов такой же, как и имен доменов (например, zork1.example.edu). Эти имена связаны с адресами типа 192.168.300.21 с помощью протокола системы имен домена (domain name system - dns). Такая непрямая связь позволяет именам оставаться стабильными, когда хосты перемещаются в сети и их нумерация изменяется.

Случайные неработающие ссылки в интернете приводят к тому, что web-адреса становятся больше похожими на указатели, а не на имена, поэтому в сообществе ietf возникли различные предложения:
uri: запрос rfc1630, выпущенный в июне 1994 г., был назван "Универсальные идентификаторы ресурсов в www: единый синтаксис для выражения имен и адресов объектов в сети, используемый во Всемирной сети Интернет" (universal resource identifiers in www: a unifying syntax for the expression of names and addresses of objects on the network as used in the world-wide web) (см. раздел Ресурсы). Это был информационный запрос, т.е. он не получил общего одобрения it-сообщества;
url: запрос rfc1738, выпущенный в декабре 1994 г., был назван "Унифицированные указатели информационных ресурсов" (uniform resource locators) (см. раздел Ресурсы). Это был предлагаемый стандарт, т.е. он являлся результатом согласований, хотя еще и не был в достаточной степени проверенным и зрелым, чтобы стать стандартом для всего интернета;
urn: запрос rfc1737, выпущенный в декабре 1994 г., был назван "Функциональные требования для унифицированных имен ресурсов" (functional requirements for uniform resource names) (см. раздел Ресурсы).

В 1997 г. за запросом rfc1737 последовал предлагаемый стандарт rfc2141 - "Синтаксис urn", который описывал спецификацию еще одной схемы - urn, в дополнение к уже существовавшим http:, ftp: и другим.

Окончательный стандарт uri rfc3986 объясняет различие между этими понятиями в секции 1.1.3 - "uri, url и urn":

uri может далее рассматриваться как указатель, имя или и то, и другое. Термин "унифицированный указатель информационных ресурсов" (url) относится к подмножеству uri, которые, помимо идентификации ресурса, указывают способ его нахождения путем описания основных механизмов доступа к нему (т.е. его "положение" в сети). Термин "унифицированное имя ресурса" (urn) исторически использовался как для uri в пределах схемы urn (запрос rfc2141), которые должны оставаться уникальными в мировом масштабе и оставаться стабильными, даже если ресурс прекращает существование или становится недоступным, так и для любых других uri со свойствами имени.

Отдельная схема не обязательно должна рассматриваться только как "имя" или "указатель". Конкретные uri из любой схемы могут иметь характеристики как имен, так и указателей, или обоих этих понятий. Часто это зависит от постоянства и тщательности в распределении идентификаторов полномочным органом по присвоению имен, а не от качества схемы. В будущих спецификациях и связанных с ними документах должен использоваться общий термин uri, а не более узкие понятия url и urn (запрос rfc3305).
Постоянство на практике

Между постоянством и доступностью существует естественное противоречие. Предположим, на каком-то хосте, связанном с интернетом, есть некий файл. Самый простой способ сделать этот файл доступным - подключить к хосту web-сервер и предоставить пользователю uri, который состоит из имени хоста и файла (например, http://dhcp324.coolisp.net/drafts/freelunch.wsdl). Такая схема будет отлично работать, пока не закончится срок лицензии протокола динамической конфигурации хоста (dynamic host configuration protocol - dhcp), не изменится провайдер или файл не будет перемещен в другую директорию. А если сервис станет популярным и за пользование им будут взимать плату? Чем менее достаточную информацию содержит имя, тем ниже его шансы уцелеть при изменениях.

Но хорошее постоянное имя, подобное http://xyzpdq.org/2005/ls434, не так легко поддерживать. Необходимо зарегистрировать домен, осуществлять отображение ("мэппирование") имени домена на адрес хоста и либо держать в памяти, что ls434 - это файл с описанием предложений ланча, либо сделать таблицу отображения файлов на web-сервере.

Проект purl и система идентификации цифровых объектов (digital object identifier - doi) (см. раздел Ресурсы) представляют другие подходы к проблеме постоянства. Постоянный url (persistent url - purl) - это обыкновенный http uri домена, который обеспечивается серьезной поддержкой его постоянства. Например, домен purl.org поддерживается Центром интерактивной компьютерной библиотеки (online computer library center - oclc) - всемирным библиотечным кооперативом. Любой может подать заявление о выделении адреса и управлять своим собственным набором purl. Желающий помещает свои материалы на обыкновенный web-сервер, а затем связывает его со своим purl путем перенаправления с помощью http. Перенаправление от purl на менее постоянные http uri во многом похоже на аналогичный процесс, обеспечиваемый dns. Разница состоит в том, что в этом случае и источник, и место назначения перенаправления относятся к одной и той же категории. Любой purl, например, http://purl.org/net/dajobe/, может использоваться как обыкновенный http uri. И что еще более важно, те люди, с которыми необходимо установить сообщение, также могут использовать его как обыкновенный http uri; при этом не требуется никаких подключаемых программ или расширений.

Система doi использует свою собственную схему, например, doi:10.123/456. web-браузеры могут быть приспособлены к поддержке этой схемы с помощью подключаемой программы. Фонд doi обеспечивает стандарты, регистрацию и услуги по перенаправлению http, подобно тому, как это делают провайдеры purl, например, oclc. Хотя Фонд doi поддерживает специальное имя для каждого doi в форме http://dx.doi.org/10.123/456, в руководстве по doi (см. раздел Ресурсы) утверждается, что эта система имеет "существенные недостатки по сравнению с подключаемой программой распознавателя". Но с точки зрения автора статьи, гораздо более существенный недостаток - это необходимость поддержки двух разных имен для каждого объекта.
Творческие проблемы в управлении информацией

Несмотря на противоречие между постоянством и доступностью, хороший uri имеет оба качества и функционирует и как постоянное имя, и как доступный ресурс. Таким образом, url - это просто более практичный uri.

Сторонники схемы urn: утверждают, что данное противоречие нельзя устранить в рамках http и dns. Проблемные области, безусловно, существуют, но с этими вопросами сталкивается любой web-мастер, и постепенно вырабатываются принципы управления информацией, которые помогают справляться с ними. Мир постоянно меняется, и чтобы успевать за этими изменениями, необходимо работать.

В большинстве случаев иерархическая природа системы присвоения имен dns достаточно удобна, но это приводит к концентрации большого количества энергии в одном месте и вызывает существенные управленческие проблемы. Системы соединения равноправных узлов, такие как распределенные равнодозированные таблицы (хэш-таблицы - hash tables), могут решить некоторые вопросы централизации, свойственные dns, но никто не знает, к каким проблемам управления может привести их использование. Различные передовые разработки показывают, как новые протоколы могут использоваться для обслуживания уже имеющихся имен типа http://..., повышая ценность существующей сети гипермедиа. Эти технологии кажутся более перспективными, чем разработка новых схем для любых действий, отдаленно напоминающих операции http типа get/put/post/delete (доставить/поместить/вывесить/убрать). По прогнозу автора статьи, современная передовая практика в управлении информацией, а также дальнейшее улучшение протоколов обеспечат продолжительное существование uri на основе http и dns.
Ресурсы
Дуглас Энгелбарт (douglas engelbart). 1990. Совместимость областей знаний и система открытых гипердокументов. Обзор исследований возможностей совместной работы с помощью компьютеров (computer-supported cooperative work - cscw). (knowledge-domain interoperability and an open hyperdocument system).
Присвоение имен документам (document naming). Тим Бёнез-Ли (tim berners-lee). Вопросы проектирования (design issues). Серия, начатая в 1991 г. и продолжающаяся по сегодняшний день.
Проблемная группа проектирования internet (internet engineering task force - ietf). Запросы на комментарии, изданные ietf и обсуждаемые в настоящей статье:
rfc1630 - Универсальные идентификаторы ресурсов в www (rfc1630 -- "universal resource identifiers in www");
rfc1737 - Функциональные требования для унифицированных имен ресурсов (rfc1737 -- "functional requirements for uniform resource names");
rfc1738 - Унифицированные указатели информационных ресурсов (rfc1738 -- "uniform resource locators"). Версия гипертекста может быть найдена на сайте w3c;
rfc2141 - Синтаксис urn (rfc2141 -- "urn syntax");
rfc3305 - Отчет специальной совместной группы w3c и ietf по планированию uri: uri, url и urn (rfc3305 -- "report from the joint w3c/ietf uri planning interest group: uris, urls, and urns");
rfc3986 - Базовый синтаксис унифицированных указателей информационных ресурсов (rfc3986 -- "uniform resource identifier (uri): generic syntax"). Также доступна версия гипертекста Роя Филдина (roy fielding);
rfc3987 - Международные указатели информационных ресурсов (rfc3987 -- "internationalized resource identifiers - iris)".
Агентство по выделению имен и уникальных параметров протоколов internet (internet assigned numbers authority - iana) и его официальный список схем uri.
Сайт проекта purl и его страница часто задаваемых вопросов.
Система doi (the doi system) и глава из "Руководства по doi", посвященная разрешающей способности.
Разделы сайта w3c, посвященные xml-схемам, пространству имен xml и базовой спецификации xml.
Статья Уши Оджбуджи (uche ogbuji) "Принципы xml-дизайна: осторожность при использовании пространства имен xml" (principles of xml design: use xml namespaces with care) (апрель 2004 г.) и его обзор xml-стандартов (январь 2004 г.).
Дополнительные xml-ресурсы на сайте ibm.
Литература по xml (developer bookstore).
Информация о том, как стать Сертифицированным разработчиком ibm в области xml и других смежных технологий (ibm certified developer in xml and related technologies)