В области управления информацией существует устойчивое противоречие между постоянством и доступностью. Это противоречие привело к появлению отдельных технологий для унифицированных имен ресурсов (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 записана следующим образом: <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;" xmlnswl="&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. Взято с http://www.stfw.ru/ Автор: Дэн Коннолли
