Jump to content

Extensible Resource Identifier

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by CapitalR (talk | contribs) at 22:41, 14 February 2011 (moved XRI to Extensible Resource Identifier: Moving revisions as part of history merge). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

XRI (eXtensible Resource Identifier) is a scheme and resolution protocol for abstract identifiers compatible with Uniform Resource Identifiers and Internationalized Resource Identifiers, developed by the XRI Technical Committee at OASIS. The goal of XRIs is to provide a universal format for identifiers that are domain-, location-, application-, and transport-independent, so they can be shared across any number of domains, directories, and interaction protocols.

Background & Motivations

URIs -- the address of every resource on the Internet -- are the most successful identifiers in history. However the growth of the Web has led to new requirements for resource identifiers that are not easily met by standard URI syntax. One of these key requirements -- internationalization -- was ultimately met by the W3C and IETF by developing a new form of URI called an Internationalized Resource Identifier (IRI). The IRI specifications built on the URI standard by extending the character set to support the full range of Unicode characters.

With the growth of XML, Web services, and other ways of adapting the Web to automated, machine-to-machine communications, another set of requirements has emerged. These are the requirements to be able to identify a resource independent of a specific physical network path, location, or protocol because you need to:

  • Create structured identifiers with self-describing "tags" that can be understood across domains the same way XML documents provide a self-describing, domain-independent data format.
  • Maintain a persistent link to the resource regardless of whether its network location changes.
  • Delegate identifier management not just in the authority segment (the first segment following the "xxx://" scheme name) but anywhere in the identifier path.
  • Map identifiers used to identify a resource in one domain to other "synonyms" used to identify the same resource in the same domain, or in other domains.

By early 2003, these requirements led to the establishment of a new technical committee at OASIS whose goal was to create a new type of identifier that built on top of the IRI specification the same way the IRI specification built on top of the URI specification. The XRI TC was also charged with creating an optional resolution protocol based on HTTP and simple XML documents called Extensible Resource Descriptors (XRDs).

Features

  • URI- and IRI-compatibility — XRIs can be used wherever URIs or IRIs are called for.
  • Cross-references — An XRI can contain another XRI (or a URI), to any level of nesting. This enables the construction of structured, "tagged" identifiers that enable identifier sharing across domains the same way XML enables data sharing across domains.
  • Global context symbols — These are single-character symbols (=, @, +, $, or !) that provide a simple, human-friendly way to indicate the global context of an i-name or i-number. These are not required, but may be used within communities of interest that agree on their meaning and how they are resolved.
  • Peer-to-peer addressing — XRI syntax supports the ability for any two network nodes to assign each other XRIs and perform cross-resolution. That is, a top-level namespace authority can be referred to by names assigned by other parties. This aids in federating namespaces between organizations or communities of interest.
  • Decentralization — XRIs can be rooted in either centralized addressing systems (e.g., IP addresses or DNS domain names) or private/decentralized root authorities.
  • Delegation — Namespaces can be delegated to other namespace authorities.
  • Federation — Namespaces defined separately at any level can be joined together in a hierarchical or polyarchical fashion, and made visible and resolvable.
  • Persistence — The ability to express the intent that parts (or all) of an XRI are permanent identifiers that will never be reassigned.
  • Human-friendly and machine-friendly formats — XRI provides syntax both for identifiers that can be created and understood by humans easily, and those that are optimized for machine structuring/parsing.
  • Simple, extensible resolution — XRI offers a lightweight resolution scheme using HTTP and simple XML documents.
  • Trusted resolution — the XRI resolution protocol includes a trusted version that uses SAML assertions.
  • Multiple resolution options — XRI resolution can be independent of DNS.
  • Fully internationalizable, leveraging Unicode and IRI specifications.
  • Transport independent — XRIs are not bound to any specific transport protocols or mechanism.

Why not just use HTTP URLs?

This is one of the most frequently asked questions about XRIs (after all, HTTP URLs are the most successful identifiers of all time.)

First, the XRI Technical Committee is updating the XRI Resolution specification to include a defined HTTP URL format in which any XRI can be expressed. So in essence, XRIs can be treated entirely as HTTP URIs for the purpose of backwards compatibility with HTTP infrastructure.

From a broader perspective, however, the reason HTTP URI syntax itself was not used is that it does not fulfill several of the most important requirements for abstract, cross-context identifiers. Specifically:

  • HTTP URIs are bound to a specific transport protocol. A fully abstract identifier scheme needs to be independent of any specific transport or access protocol.
  • HTTP URIs do not support sharing structured, “tagged” identifiers across contexts. A fully abstract identifier scheme will enable “identifier markup” just like XML enables data markup.
  • HTTP URIs do not define a clear way to get at metadata (as opposed to data) about a resource. A fully abstract identifier scheme can cleanly distinguish access to resource metadata vs. a resource itself.
  • HTTP URIs offer only a very limited authority delegation model. Abstract identifiers need to be able to express logical authorities and authority delegation relationships.
  • HTTP URIs do not offer a trusted resolution mechanism. A fully abstract identifier scheme can define an trusted resolution protocol independent of DNS.
  • HTTP URIs do not offer a standard syntax for persistence. A fully abstract identifier scheme can clearly distinguish between persistent and reassignable identifiers.

As a specific example, say a library system uses URNs in the ISBN namespace to identify books and DNS subdomains to identify its library branches. HTTP URI syntax does not provide a standard way to express the URN for the book title in the context of the DNS name for the library branch. XRI cross-reference syntax solves this problem by allowing the library (and even automated programs running at the library) to programmatically construct the XRIs necessary to address any book at any branch. Examples: 

 xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)
 xri://shoreline.library.example.com/(urn:isbn:0-395-36341-1)
 xri://northgate.library.example.com/(urn:isbn:0-395-36341-1)

This ability to create structured, self-describing identifiers can be extended to many other uses. For example, say the library wanted to indicate the type of each book available. By establishing a simple XRI dictionary of book types, it can now programmatically construct XRIs that include this metadata, 

 xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)/(+hardcover)
 xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)/(+softcover)
 xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)/(+reference)

Applications

Examples of applications being developed using XRI infrastructure include:

Examples

(Note that none of these show the prefix "xri://", which is optional in XRIs when they are not in URI normal form.)

Example XRIs composed entirely of reassignable segments: 

 =Mary.Jones
 @Jones.and.Company
 +phone.number
 +phone.number/(+area.code)
 =Mary.Jones/(+phone.number)
 @Jones.and.Company/(+phone.number)
 @Jones.and.Company/((+phone.number)/(+area.code))

Example XRIs composed entirely of persistent segments: 

 !!1002!A7C5
 !!1002!A7C5/!D90F.88

Example of XRIs with mixes of persistent and reassignable segments (XRI allows any combination of the two): 

 !!1002!A745/(+phone.number)
 @Jones.and.Company/!D90F.88/(+area.code)

See also

Retrieved from "https://en.wikipedia.org/w/index.php?title=Extensible_Resource_Identifier&oldid=413959996"