XRI

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa

XRI (eXtensible Resource Identifier - Identificador de Recursos eXtensível) é um protocolo de resolução para identificadores abstratos compatível com URIs e IRIs, desenvolvido pelo XRI Technical Committee na OASIS. O objetivo do XRI é fornecer um formato universal para identificadores abstratos e estruturados que são independentes de domínio, localização, aplicação e transporte, assim podem ser compartilhados através de qualquer quantidade de domínios, diretórios e protocolos de interação.

Background e motivações[editar | editar código-fonte]

URIs foram identificadores de sucesso na Internet. Porém o crescimento da Web tem levado a novos requisitos para identificadores de recursos que não são facilmente encontrados na sintaxe padrão de URIs. Um desses requisitos-chave — a internacionalização — foi encontrado pelo W3C e IETF pelo desenvolvimento de uma nova forma de URI chamada Internationalized Resource Identifier (IRI). As especificações do IRI foram construídas no padrão URI estendendo o conjunto de caracteres para suportar Unicode.

Com o crescimento do XML, Web services, e outros modos de adaptar a Web a uma comunicação entre máquinas automatizada, outro conjunto de requisitos emergiu. Estes são os requisitos de ser capaz de identificar um recurso independente de uma localização, protocolo ou caminho físico específico da rede, pois é necessário:

  • Criar identificadores estruturados com "marcadores" se auto-descrevendo que possam ser entendidos através de domínios de forma que documentos XML forneçam um formato de dados auto-descritivo independente de domínio.
  • Manter uma ligação persistente para um recurso desprezado de sua localização de rede muda.
  • Delegar o gerenciamento de identificador não somente no segmento da autoridade (o primeiro segmento seguindo o "xxx://") mas em qualquer lugar no caminho do identificador.
  • Traçar os identificadores usados para identificar um recurso em um domínio para outros "sinônimos" usados para identificar o mesmo recurso no mesmo domínio, ou em outros domínios.

Em 2003, esses requisitos guiaram ao estabelecimento de um novo comité técnico na OASIS cujo objetivo foi criar um novo tipo de identificador que construisse sobre a especificação do IRI da mesma forma que a especificação do IRI foi construída sobre a especificação do URI. O XRI TC também foi encarregado de criar um protocolo de resolução opcional baseado no HTTP e documentos XML simples chamados Extensible Resource Descriptors (XRDs).

Características[editar | editar código-fonte]

  • Compatibilidade com URI e IRI — XRIs podem ser usados se URIs ou IRIs são chamados.
  • Referências cruzadas — um XRI pode conter outro XRI (ou um URI), para qualquer nível de aninhamento. Isso possibilita a construção de identificadores estruturados e "marcados" que possibilitam compartilhamento de identificadores através de domínios e o mesmo XML possibilita compartilhamento de dados através de domínios.
  • Símbolos de contexto global — esses são símbolos de um único caractere (=, @, +, $, or !) que fornecem um modo simples e amigável para humanos de indicar o contexto global de um i-name ou i-number. Estes não são necessários, mas podem ser usados dentro de comunidades de interesse que aceitem em seu significado e como eles são resolvidos.
  • Endereçamento P2P — a sintaxe do XRI suporta a habilidade de quaisquer dois nós da rede atribuir a cada outro XRIs e realizar resolução cruzada. Isso é, uma autoridade pode ser consultada pelos nomes atribuídos por outros partidos. Isso ajuda a federar espaços de nome entre organizações ou comités de interesse.
  • Descentralização — XRIs podem ser enraizados ou em sistemas de endereçamento centralizado (por exemplo, endereços IP ou DNS) ou autoridades-raíz privadas/descentralizadas.
  • Delegação — espaços de nome podem ser delegados para outras autoridades.
  • Federação — espaços de nome definidos separadamente em qualquer nível podem ser juntados de uma forma hierárquica ou poligárquica, e serem feitos visíveis em resolvíveis.
  • Persistência — a habilidade de expressar a intenção que partes (ou todo) de um XRI são identificadores permanentes que nunca serão atribuídos novamente.
  • Formatos amigáveis a humanos e máquinas — XRI fornece uma sintaxe para identificadores que são criados e entendidos por humanos facilmente, e aqueles que são otimizados para estruturação/análise de máquinas.
  • resolução simples e extensível — XRI oferece um esquema de resolução leve usando HTTP e documentos XML simples.
  • Resolução confiável — o protocolo de resolução do XRI inclui uma versão confiável que usa asserções SAML.
  • Múltiplas opções de resolução — a resolução do XRI pode ser independente de DNS.
  • Totalmente internacionalizável, alavancando as especificações Unicode e IRI.
  • Independente de transporte — XRIs não são limitadas a nenhum protocolo ou mecanismo específico de transporte.

Por que não apenas usar URLs HTTP?[editar | editar código-fonte]

Note que a maioria dos problemas descritos aqui só são problemas percebidos pela comunidade desenvolvendo XRIs. Há outros que discordam que estes são problemas, em particular aqueles com profundo conhecimento da arquitetura da Web. Por exemplo, o Grupo de Arquitetura Técnica da W3C está trabalhando em um documento esboço que tenta refutar algumas das reivindicações feitas per proponentes do XRI.

Isso é uma das questões mais frequentemente perguntadas sobre XRIs (afinal, URLs HTTP são os identificadores de maior sucesso de todos os tempos.)

Primeiramente, o Comité Técnico do XRI está atualizando a especificação de Resolução de XRI para incluir um formato definido de URL HTTP no qual qualquer XRI pode ser expressada. Então essencialmente, XRIs podem ser tratadas inteiramente como URIs HTTP para o propósito de compatibilidade com a infraestrutura HTTP.

De uma perspectiva mais larga, porém, a razão pela qual a sintaxe de URI HTTP propriamente dita não foi usada é que ela não cumpre vários dos mais importantes requisitos para identificadores abstratos e de contexto cruzado. Especificamente:

  • URIs HTTP são limitadas a um protocolo de transporte específico. Um identificador totalmente abstrato precisa ser independente de qualquer protocolo de transporte ou acesso específico.
  • URIs HTTP não suportam compartilhamento de identificadores estruturados e "marcados" através de contextos. Um identificador totalmente abstrato possibilitará “marcação de identificador” assim como XML possibilita marcação de dados.
  • URIs HTTP não definem um jeito claro de pegar metadados (ao contrário dos dados) sobre um recurso. Um identificador totalmente abstrato pode distinguir acesso a metadados do recurso de acesso ao próprio recurso.
  • URIs HTTP oferecem um modelo de delegação de autoridade muito limitado. Identificadores abstratos precisam ser capazes de expressar relações entre autoridades lógicas e autoridades de delegação.
  • URIs HTTP não oferecem um mecanismo de resolução confiável. Um identificador totalmente abstrato pode definir um protocolo de resolução confiável independente de DNS.
  • URIs HTTP não oferecem uma sintaxe padrão para persistência. Um identificador totalmente abstrato pode claramente distinguir entre identificadores persistente e identificadores reatribuídos.

Como um exemplo específico, digamos que um sistema de biblioteca usa URNs no espaço de nomes ISBN para identificar livros e subdomínios DNS para identificar suas filiais. A sintaxe de URI HTTP não fornece um modo de expressar o URN para o título do livro no contexto do nome do DNS para a filial da biblioteca. A sintaxe de referência cruzada do XRI resolve esse problema permitindo que a biblioteca (e nivelar os programas automatizados rodando na biblioteca) construa periodicamente as XRIs necessárias para endereçar qualquer livro em qualquer filial. Exemplos:

 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)

Essa habilidade de criar identificadores estruturados auto-descritivos pode ser estendida para muitos outros usos. Por exemplo, digamos que a biblioteca quer indicar o tipo de cada livro disponível. Estabelecendo um simples dicionário XRI de tipos de livro, ela agora pode periodicamente construir XRIs que incluam esse metadado,

 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)

Aplicações[editar | editar código-fonte]

Exemplos de aplicações sendo desenvolvidos usando a infrsestrutura XRI incluem:

Exemplo[editar | editar código-fonte]

(Note que nenhum destes mostram o prefixo "xri://", que é opcional em XRIs quando elas não estão na forma de URIs.)

Exemplos de XRIs compostas inteiramente por segmentos reatribuídos:

 =Mary.Jones
 @Jones.e.Company
 +numero.telefone
 +numero.telefone/(+cod.area)
 =Mary.Jones/(+numero.telefone)
 @Jones.e.Company/(+numero.telefone)
 @Jones.e.Company/((+numero.telefone)/(+cod.area))

Exemplos de XRIs compostas inteiramente de segmentos persistentes:

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

Exemplos de XRIs com mistos de segmentos persistentes e reatribuídos (XRIs permitem quaisquer combinações dos dois):

 !!1002!A745/(+numero.telefone)
 @Jones.and.Company/!D90F.88/(+cod.area)

Ver também[editar | editar código-fonte]

Ligações externas[editar | editar código-fonte]