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

В области управления информацией существует устойчивое противоречие между постоянством и доступностью. Дэн Коннолли (Dan Connol

🕛 29.09.2005, 02:30

В области управления информацией существует устойчивое противоречие между постоянством и доступностью. Это противоречие привело к появлению отдельных технологий для унифицированных имен ресурсов (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 для редактирования удаленных файлов. Оно сводило воедино имена хост-узла и пользователя с путем доступа к файлу, и в результате получалась конструкция такого типа: /jbrown@freddie.ucla.edu:~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 записана следующим образом:

<xsl:includehref="exslt.org/math/min/math.min.template.xsl"/>,

то она не будет работать, как ожидается, если только это выражение не является обращением к файлу в директории 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

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

<Class rdf:about="#Nothing"/>

В этом примере ссылка #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)