1. A única versão normativa deste documento é a versão em língua inglesa que se encontra no site do W3C.
  2. O presente documento traduzido para a língua portuguesa do Brasil, pode conter erros de tradução.
  3. A versão oficial e original, em inglês, deste documento, encontra-se em: https://www.w3.org/TR/webarch/ e os seus direitos se dão conforme:

Este documento foi traduzido em 17 de maio de 2016 por: Yasodara Córdova e encontra-se hospedado no "Repositório de traduções do W3C Brasil Office " em http://traducoes.w3c.br/TR/webarch/

A tradução para a língua portuguesa do Brasil, foi para este documento. Vale dizer, as páginas remetidas pelos links nele constantes, estão em sua versão original em língua inglesa.

Por favor, relate erros encontrados neste documento para Centro de Estudos sobre Tecnologias Web.

W3C

Arquitetura da World Wide Web, volume 1

Recomendação W3C, 15 de dezembro de 2004

Esta versão:
http://www.w3.org/TR/2004/REC-webarch-20041215/
Última versão:
http://www.w3.org/TR/webarch/
Versão anterior:
http://www.w3.org/TR/2004/PR-webarch-20041105/
Editores:
Ian Jacobs, W3C
Norman Walsh, Sun Microsystems, Inc.
Autores:
Ver agradecimentos (§8).

Favor consultar a errata para este documento, que pode incluir algumas correções normativas.

Ver também traduções..

.

Resumo

A World Wide Web usa tecnologias relativamente simples com suficientes escalabilidade, eficiência e utilidade, que resultaram em um formidável espaço de informações de recursos inter-relacionados, de diferentes idiomas, culturas e mídias. Em um esforço para preservar essas propriedades do espaço de informações, mesmo com a evolução das tecnologias, este documento de arquitetura discute os principais componentes do projeto da Web. São eles: a identificação de recursos, a representação do estado do recurso e os protocolos que apoiam a interação entre agentes e recursos no espaço. Relacionamos os principais componentes do projeto, restrições e boas práticas aos princípios e propriedades que apoiam.

Situação deste documento

Esta seção descreve a situação deste documento à época de sua publicação. Outros documentos podem substituir este. Uma lista de publicações atuaestá do W3C e as últimas revisões deste relatório técnico podem ser encontradas no índice de relatórios técnicos do W3C no índice de reports técnicos do W3C

Esta é a Recomendação de “Arquitetura da World Wide Web, Volume Um”, de 15 de dezembro de 2004. Este documento foi revisado por membros do W3C, por desenvolvedores de software e por outros grupos e partes interessadas do W3C, sendo endossado pelo Diretor como uma Recomendação W3C. É um documento estável e pode ser usado como material de referência ou citado em outro documento. O papel do W3C ao fazer esta Recomendação é chamar atenção para a especificação e promover sua ampla implementação. Isso aumenta a funcionalidade e a interoperabilidade da Web.

Este documento foi desenvolvido pelo Grupo Técnico de Arquitetura do W3C (TAG), que mantém, um estatuto com uma lista de questões arquitetônicas.. O escopo deste documento é um subgrupo útil dessas questões; não pretendendo abordar todas elas. O TAG pretende abordar as questões remanescentes (e futuras) agora que o Volume Um está publicado como Recomendação W3C. Está disponível um histórico completo das mudanças deste documento. Por favor envie comentários sobre este documento para public-webarch-comments@w3.org (arquivo público de public-webarch-comments). A discussão técnica do TAG ocorre em www-tag@w3.org (arquivo público de www-tag).

Este documento foi produzido sob a Política IPR do W3C de julho de 2001 quanto ao processo de documentação.. O TAG mantém uma lista pública de divulgação de patentes relevantes a este documento; a página também inclui instruções para divulgar uma patente. Uma pessoa que conheça uma patente que acredite conter Pretensão(ões) Essencial(is) referente(s) a esta especificação deve divulgar a informação, de acordo com a seção 6 da Política de Patentes do W3C..

Sumário

Lista de Princípios, Restrições e Boas Práticas

Os princípios, as restrições e as boas práticas a seguir são discutidos neste documento e listados aqui por conveniência. Existe também um resumo independente.

Identificação
Interação
Formatos de Dados
Princípios Gerais de Arquitetura

1. Introdução

A World Wide Web (WWW, ou simplesmente Web) é um espaço de informações em que itens de interesse, referidos como recursos, são reconhecidos por identificadores globais chamados de Uniform Resource Identifiers. (URI).

Exemplos, como o da história a seguir, em um cenário de viagem, serão utilizados durante todo este documento para ilustrar o comportamento típico dos Web agents—pessoas ou softwares agindo sobre este espaço de informações. Um user agent age em nome de um usuário. Software agents incluem servidores, proxies, spiders, navegadores e tocadores multimídia.

História

Enquanto planeja uma viagem para o México, Nádia lê “Informação do tempo em Oaxaca: 'http://weather.example.com/oaxaca'” em uma revista de viagens. Nádia tem experiência suficiente com a Web para reconhecer que "http://weather.example.com/oaxaca" é uma URI e que é capaz de obter informações associadas a partir de seu navegador Web. Quando Nádia digita o URI em seu navegador:

  1. O navegador reconhece que aquilo que Nádia digita é um URI.
  2. O navegador realiza uma ação de obtenção de informações de acordo com seu comportamento configurado para recursos identificados pelo esquema de URI “http”.
  3. A autoridade responsável por “weather.exemplo.com” fornece informações em resposta à solicitação.
  4. O navegador interpreta a resposta, identificada como XHTML pelo servidor, e realiza ações adicionaestá de obtenção de gráficos inline e de outros conteúdos, conforme necessário.
  5. O navegador apresenta as informações obtidas, que incluem links de hipertexto para outras informações. Nádia poderia seguir esses links de hipertexto para obter informações adicionais.

Este cenário ilustra as três bases arquitetônicas da Web que são discutidas neste documento:

  1. Identificação (§2). URIs são usados para identificar recursos. Neste cenário de viagem, o recurso é um relatório periodicamente atualizado sobre o tempo em Oaxaca, e a URI é “http://weather.exemplo.com/oaxaca”.

  2. Interação (§3). Agentes da Web se comunicam usando protocolos padronizados que permitem interação através de troca de mensagens que seguem a uma sintaxe e uma semântica definidas. Ao digitar um URI em uma caixa de diálogo ou selecionar um link de hipertexto, Nádia diz para seu navegador realizar uma ação de obtenção do recurso identificado pelo URI. Neste exemplo, o navegador envia um pedido HTTP GET (parte do protocolo HTTP) ao servidor em “weather.exemplo.com”, via TCP/IP porta 80, e o servidor retorna uma mensagem contendo o que determina ser uma representação do recurso no momento em que aquela representação foi gerada. Observe que este exemplo é específico da navegação de informações em hipertexto – outros tipos de interação são possíveis, tanto em navegadores como pelo uso de outros tipos de agentes da Web; nosso exemplo pretende ilustrar uma interação comum, não definir a gama de possíveis interações ou limitar as formas como agentes podem usar a Web.

  3. Formatos (§4). A maioria dos protocolos usados para obtenção e/ou submissão de representação utilizam uma sequência de uma ou mais mensagens que, juntas, contêm uma quantidade de dados e metadados de representação, para transferir a representação entre agentes. A escolha do protocolo de interação coloca limites nos formatos de dados e metadados de representação que podem ser transmitidos. O HTTP, por exemplo, normalmente transmite um único octet stream (fluxo de octetos) mais metadados, e usa campos de cabeçalho “Content-Type” e “Content-Encoding” para identificar melhor o formato da representação. Neste cenário, a representação transferida está em XHTML, conforme identificado pelo campo de cabeçalho HTTP “Content-type” contendo o nome do tipo de mídia de Internet registrado, “application/xhtml+xml”. Esse nome do tipo de mídia de Internet indica que os dados de representação podem ser processados de acordo com a especificação do XHTML.

    O navegador de Nádia está configurado e programado para interpretar a recepção de uma representação do tipo “application/xhtml+xml” como uma instrução para processar o conteúdo daquela representação de acordo com o modelo de renderização XHTML, incluindo todas as interações subsidiárias (tais como pedidos por folhas de estilo externas ou imagens in-line) requisitadas pela representação. No cenário, os dados de representação XHTML recebidos no pedido inicial instruem o navegador de Nádia a também obter e processar os mapas meteorológicos, cada um identificado por um URI e, assim, produzir uma ação de obtenção adicional, resultando em representações adicionais que são processadas pelo navegador de acordo com seus próprios formatos de dados (por exemplo, “application/svg+xml” indica o formato de dados SVG), e esse processo continua até que todos os formatos de dados tenham sido processados. O resultado de todo esse processamento, assim que o navegador chega a um estado estacionário de aplicativo que encerra a ação inicialmente solicitada por Nádia, é comumente referido como uma “página Web”.

A ilustração a seguir mostra a relação entre identificador, recurso e representação.

Um recurso (a informação sobre o tempo em Oaxaca) é identificada por uma URI em particupar e é representada por conteúdo pseudo-HTML

No restante deste documento, realçamos importantes pontos arquitetônicos a respeito de identificadores Web, protocolos e formatos. Também discutimos alguns importantes princípios gerais de arquitetura (§5) e como se aplicam à Web.

1.1. Sobre este documento

Este documento descreve as propriedades que desejamos da Web e as escolha de projeto que foram feitas para alcançá-las. Promove a reutilização de padrões existentes, quando adequado, e orienta sobre como inovar de maneira consistente na arquitetura Web.

Os termos DEVE, NÃO DEVE, DEVERIA, NÃO DEVERIA e PODE são usados nos princípios, nas restrições e nas boas práticas de acordo com a [RFC2119.

Este documento não inclui disposições de conformidade pelos seguintes motivos:

1.1.1. Público deste Documento

TEste documento é destinado a estimular discussões sobre questões de arquitetura Web. O público-alvo do documento inclui:

  1. Participantes em Atividades do W3C
  2. Outros grupos e indivíduos projetando tecnologias a serem integradas à Web
  3. Implementadores de especificações W3C
  4. Autores e editores de conteúdo Web

Nota: Este documento não faz qualquer distinção formal entre os termos “linguagem” e “formato”. O contexto determina qual termo é utilizado. A expressão “Designer de especificação” engloba projetista de linguagem, formato e protocolo.

1.1.2. Escopo desde Documento

Este documento apresenta a arquitetura geral da Web. Outros grupos dentro e fora do W3C também abordam aspectos específicos de arquitetura Web, incluindo acessibilidade, garantia de qualidade, internacionalização, independência de dispositivos e Serviços Web. A seção sobre Especificações da Arquitetura (§7.1) inclui referências a essas especificações relacionadas.

O documento procura um equilíbrio entre brevidade e precisão, ao mesmo tempo que inclui exemplos ilustrativos. Os textos de conclusões do TAG textos de conclusões do TAG são documentos informativos que complementam o documento atual, fornecendo maestá detalhes sobre determinados tópicos. Este documento inclui alguns excertos desses textos de conclusões. Como as conclusões evoluem de forma independente, este documento inclui referências a textos aprovados do TAG. Para outras questões do TAG, cobertas pelo presente documento mas sem um texto de conclusões aprovado, as referências para verbetes estão na lista de boletins do TAG.

Muitos dos exemplos neste documento que envolvem atividades humanas supõem o conhecido modelo de interação Web (ilustrado no início da Introdução), em que uma pessoa segue um link por meio de um agente de usuário, o agente de usuário obtém e apresenta dados, o usuário segue outro link, etc. Este documento não discute em detalhes outros modelos de interação, como navegação por voz (veja, por exemplo, o [VOICEXML2]). A escolha do modelo de interação pode ter um impacto sobre o comportamento esperado do agente. Por exemplo, quando um agente de usuário gráfico rodando em um laptop ou em um dispositivo de mão encontra um erro, o agente de usuário pode reportar erros diretamente para o usuário por meio de sinais visuais e de áudio e apresentar ao usuário opções para resolver os erros. Por outro lado, quando alguém está navegando na Web por meio de entrada de voz e saída somente em áudio, interromper o diálogo para aguardar a entrada do usuário pode reduzir a usabilidade, uma vez que é muito fácil “perder a noção” quando se navega apenas com saída em áudio. Este documento não discute como os princípios, as restrições e as boas práticas identificadas aqui se aplicam em todos os contextos de interação.

1.1.3. Princípios, Restrições e Boas Práticas

Os pontos importantes deste documento são classificados da seguinte forma:

Princípio
Um princípio arquitetônico é uma regra fundamental que se aplica a um grande número de situações e variáveis. Princípios arquitetônicos incluem “separação de interesses”, “interface genérica”, “sintaxe autodescritiva”, “semântica evidente”, “efeito de rede” (Lei de Metcalfe) e a Lei de Amdahl: “A velocidade de um sistema é limitada por seu componente mais lento”.
Restrição
Em um projeto de Web, algumas escolhas, como os nomes dos elementos p e li em HTML, a escolha do caractere de dois pontos (:) em URIs, ou o agrupamento de bits em unidades de oito bits (octetos), são um tanto arbitrárias; se paragraph fosse escolhido em vez de p, ou asterisco (*) em vez de dois pontos, o resultado no final seria, muito provavelmente, o mesmo. Este documento concentra-se em escolhas de projeto mais importantes: escolhas de projeto que levam a restrições, ou seja, restrições de comportamento ou de interação dentro do sistema. Restrições podem ser impostas por motivos técnicos, políticos ou outras razões para alcançar propriedades desejáveis no sistema, tais como acessibilidade, alcance global, relativa facilidade de evolução, eficiência e extensibilidade dinâmica.
Boas Práticas
Boas práticas - por desenvolvedores de software, autores de conteúdo, gestores de sites, usuários e projetistas de especificação – aumentam o valor da Web.

2. Identificação

Para se comunicar internamente, uma comunidade concorda (em certa medida) a respeito de um conjunto de termos e seus significados. Um dos objetivos da Web, desde sua criação, tem sido construir uma comunidade global em que qualquer parte pode compartilhar informações com qualquer outra. Para atingir este objetivo, a Web faz uso de um único sistema de identificação global: o URI. Os URIs são um marco da arquitetura Web, fornecendo identificação que é comum em toda a Web. O alcance global dos URIs promove “efeitos de rede” em grande escala: o valor de um identificador aumenta quanto mais for usado de forma consistente (por exemplo, quando mais for usado em links de hipertexto(§4.4)).

Princípio: Identificadores globais

Identificadores Globais Nomes globais levam a efeitos de rede globais.

Este princípio remonta, pelo menos, até o trabalho seminal de Douglas Engelbart sobre sistemas abertos de hipertexto; veja a seção Todo Objeto Acessível em [Eng90].

2.1. Benefícios dos URIs

A escolha da sintaxe para identificadores globais é um tanto arbitrária; o importante é seu alcance global. O Uniform Resource IdentifierURI foi implantado com sucesso desde a criação da Web. Existem benefícios substanciais em participar da rede existente de URIs, incluindo links, bookmarking, caching e indexação por motores de busca, e há custos substanciais para a criação de um novo sistema de identificação que tenha as mesmas propriedades dos URIs.

Boa prática:Identificar com URIs

para se beneficiar e aumentar o valor da World Wide Web, agentes devem fornecer URIs como identificadores de recursos.

Um recurso deve ter um URI associado caso outra parte queira, razoavelmente, criar um link de hipertexto para ele, fazer ou refutar declarações a respeito, recuperar ou armazenar em cache uma representação dele, incluí-lo todo ou parte dele por referência em outra representação, anotar nele ou realizar outras operações. Os desenvolvedores de software devem saber que é útil o compartilhamento de URIs entre aplicativos, mesmo que essa utilidade não seja evidente desde o início. O texto de conclusões do TAG "“URIs, acessibilidade e o uso de HTTP GET e POST”" discute benefícios adicionais e tece considerações sobre acessibilidade de URI.

Observação: Alguns esquemas de URI (como a especificação de esquema de URI “ftp”) usam o termo “designar” quando este documento usa “identificar”.

2.2. Relações URI/Recurso

No projeto, o URI identifica um recurso. Não limitamos o escopo do que pode ser um recurso. O termo “recurso” é usado em um sentido geral para o que pode ser identificado por um URI. É normal, na Web de hipertexto, descrever páginas Web, imagens, catálogos de produtos, etc. como “recursos”. A característica distintiva desses recursos é que todas as suas características essenciais podem ser expressas em uma mensagem. Identificamos esse conjunto como “recursos de informação.”

Este documento é um exemplo de recurso de informação. Consiste de palavras, símbolos de pontuação, gráficos e outros artefatos que podem ser codificados, com diferentes graus de fidelidade, em uma sequência de bits. Não há nada sobre o conteúdo informativo fundamental deste documento que não possa, em princípio, ser transferido em uma mensagem. No caso deste documento, o conteúdo da mensagem é a representação do presente documento.

No entanto, nosso uso do termo recurso é intencionalmente mais amplo. Outras coisas, como carros e cães (e, se você imprimiu este documento em folhas físicas de papel, o artefato que está segurando em sua mão), são recursos também. Contudo, não são recursos de informação, porque sua essência não é informação. Embora seja possível descrever um grande número de coisas sobre um carro ou um cão em uma sequência de bits, a soma dessas coisas vai ser sempre uma aproximação do caráter essencial do recurso.

Definimos o termo “recurso de informação” porque observamos que é algo útil em discussões sobre tecnologia Web e pode ser útil na construção de especificações para facilidades criadas para uso na Web.

Restrições: URIs identificam um único recurso

Atribua URestá distintos para recursos distintos.

Como o escopo de um URI é global, o recurso identificado por um URI não depende do contexto em que o URI aparece (veja também a seção sobre identificação indireta (§ 2.2.3))

[URI] é um acordo sobre como a comunidade da Internet atribui nomes e os associa aos recursos que identificam. Os URIs são divididos em schemas (§ 2.4), que definem, por meio de sua especificação de esquema, o mecanismo pelo qual identificadores específicos de esquema são associados a recursos. Por exemplo, o esquema de URI “http” ([RFC2616]) usa servidores HTTP baseados em TCP e DNS para fins de alocação e resolução de identificadores. Como consequência, identificadores como “http://exemplo.com/somepath#someFrag” muitas vezes assumem significado pela experiência da comunidade em realizar uma solicitação HTTP GET sobre o identificador e, se for obtida uma resposta positiva, interpretam a resposta como uma representação do recurso identificado. (Veja também Identificadores de Fragmento (§ 2.6). Logicamente, uma ação de obtenção como GET não é a única maneira de obter informações sobre um recurso. Pode-se também publicar um documento que pretende definir o significado de um determinado URI. Essas outras fontes de informação podem sugerir significados para tais identificadores, mas é uma decisão política local se essas sugestões devem ser levadas em consideração.

Assim como se pode querer referir-se a uma pessoa por diferentes nomes (por nome completo, apenas o primeiro nome, apelido em esportes, apelido romântico e assim por diante), a arquitetura Web permite a associação de maestá de um URI a um recurso. URIs que identificam o mesmo recurso são chamados de URI aliases. The section on URI aliases (§2.3.1). A seção sobre aliases URI (§ 2.3.1) discute alguns dos possíveis custos de se criar múltiplos URIs para o mesmo recurso.

Várias seções deste documento abordam questões sobre a relação entre URIs e recursos, incluindo:

2.2.1. Colisão de URIs

Por definição, o URI identifica um recurso. Usar o mesmo URI para identificar diretamente recursos diferentes produz uma colisão de URI. Frequentemente uma colisão impõe um custo na comunicação devido ao esforço necessário para resolver ambiguidades.

Suponha, por exemplo, que uma organização utiliza um URI para se referir ao filme Golpe de Mestre e outra organização usa o mesmo URI para se referir a um fórum de discussão sobre Golpe de Mestre. Para um terceiro, ciente de ambas as organizações, essa colisão cria uma confusão sobre o que o URI identifica, minando o valor do URI. Se alguém quisesse conversar sobre a data de criação do recurso identificado pelo URI, por exemplo, não ficaria claro se o assunto em questão seria “quando o filme foi criado” ou “quando o fórum de discussão sobre o filme foi criado”.

Foram concebidas soluções técnicas e sociais para ajudar a evitar colisões de URI. No entanto, o sucesso ou o fracasso dessas diferentes abordagens depende da medida em que há consenso na comunidade da Internet quanto às especificações definidoras.

A seção sobre alocação de URIs (§ 2.2.2) examina abordagens para estabelecer a fonte oficial de informações sobre qual recurso é identificado por um URI.

URIs são, por vezes, usados para identificação indireta (§ 2.2.3) . Isso não necessariamente leva a colisões.

2.2.2. Alocação de URI

Alocação de URI é o processo de se associar um URI a um recurso. A alocação pode ser realizada tanto por proprietários dos recursos quanto por terceiros. É importante evitar colisão de URI (§2.2.1).

2.2.2.1. URI ownership

URI ownership Ownership de URI é uma relação entre um URI e uma entidade social, como uma pessoa, organização ou especificação. A propriedade de URI dá à entidade social certos direitos, incluindo:

  1. passar a propriedade de um ou todos os URIs para outro proprietário – delegação; e
  2. e associar um recurso a um URI de sua propriedade – alocação de URI.

Por convenção social, a propriedade de URI é delegada do registro [IANA de esquemas de URI], ela própria uma entidade social, para as especificações de esquema de URI registradas na IANA. Algumas especificações de esquema de URI delegam a propriedade para registros subordinados ou outros proprietários indicados, os quais poderão, por sua vez, delegar a propriedade. No caso de uma especificação, a propriedade fica com a comunidade que mantém a especificação.

A abordagem adotada para o esquema de URI “http”, por exemplo, segue o padrão pelo qual a comunidade da Internet delega autoridade, por meio do registro de esquemas URI da IANA e do DNS, sobre um conjunto de URIs com um prefixo comum a determinado proprietário. Uma consequência dessa abordagem é a forte dependência da Web no registro central de DNS. Uma abordagem diferente é a do esquema URN Syntax [RFC2141] que delega a propriedade de partes de espaço URN para especificações de Namespaces (espaços de nomes) URN, as quais estão registradas em um registro mantido pela IANA de Identificadores de Namespaces URN.

Proprietários de URI são responsáveis por evitar a atribuição de URIs equivalentes a várias recursos. Assim, se a especificação de um esquema de URI prevê a delegação de um URI ou conjuntos organizados de URIs, deve-se tomar o cuidado de garantir que a propriedade, em última análise, reside nas mãos de uma única entidade social. Permitir múltiplos proprietários aumenta a probabilidade de colisões de URI.

Proprietários de URI podem organizar ou implantar infraestrutura para garantir que estejam disponíveis representações de recursos associados e, quando apropriado, a interação com o recurso pela troca de representações. Existem expectativas sociais para a gestão de representação responsável gestão da representação (§3.5) (§ 3.5) pelos proprietários de URI. Não são discutidas aqui implicações sociais adicionaestá de propriedade de URI.

Veja o boletim do TAG siteData-36, que diz respeito à expropriação de autoridade de nome.

2.2.2.2. Outros esquemas de alocação

Alguns esquemas usam outras técnicas além de delegação de propriedade para evitar colisões técnicas. Por exemplo, a especificação para o esquema de URL de dados [RFC2397] especifica que o recurso identificado por um URI de esquema de dados tenha apenas uma representação possível. Os dados de representação tornam-se o URI que identifica o recurso. Assim, a própria especificação determina como os URestá de dados são alocados; não é possível nenhuma delegação.

Outros esquemas (como “news:comp.text.xml”) dependem de um processo social.

2.2.3. Identificação Indireta

Dizer que o URI “mailto:nadia@exemplo.com” identifica ao mesmo tempo uma caixa postal na Internet e Nádia, a pessoa, introduz uma colisão de URI. Contudo, podemos usar o URI para identificar indiretamente Nádia. É bem comum o uso de identificadores dessa forma.

Ao escutar um noticiário, pode-se ouvir uma reportagem sobre a Grã-Bretanha que começa: “Hoje, 10 Downing Street anunciou uma série de novas medidas econômicas”. De modo geral, “10 Downing Street” identifica a residência oficial do primeiro-ministro da Grã-Bretanha. Neste contexto, o repórter o está usando (já que a retórica em inglês permite) para identificar indiretamente o governo britânico. Da mesma forma, URIs identificam recursos, mas também podem ser usados em muitas construções para identificar indiretamente outros recursos. Políticas de definição adotadas de modo global tornam alguns URIs interessantes como identificadores de propósitos gerais. Políticas locais estabelecem o que identificam indiretamente.

uponhamos que nadia@example.com seja o endereço de e-mail de Nádia. Os organizadores de uma conferência da qual Nádia participe podem usar “mailto:nadia@exemplo.com” para se referirem indiretamente a ela (por exemplo, usando o URI como uma chave no banco de dados dos participantes da conferência). Isso não introduz uma colisão de URI.

2.3. Comparações de URI

URIs que são idênticos, em todos os caracteres, referem-se ao mesmo recurso. Como a Arquitetura Web permite a associação de múltiplos URIs a um determinado recurso, dois URIs, mesmo que não idênticos em todos os caracteres, podem ainda assim se referir ao mesmo recurso. Diferentes URIs não necessariamente referem-se a diferentes recursos, mas costuma haver um custo computacional mais alto para se determinar que diferentes URIs referem-se ao mesmo recurso.

Para se reduzir o risco de um falso negativo (i.e., uma conclusão incorreta de que dois URIs não se referem ao mesmo recurso) ou um falso positivo (i.e., uma conclusão incorreta de que dois URIs referem-se ao mesmo recurso), algumas especificações descrevem testes de equivalência, além da comparação caractere a caractere. Agentes que chegam a conclusões com base em comparações que não são licenciadas por especificações relevantes responsabilizam-se por qualquer problema resultante; veja a seção sobre como lidar com erros (§5.3) para mais informações sobre comportamento responsável ao se chegar a conclusões não licenciadas. A seção 6 de [URI] traz mais informações sobre comparação de URIs e redução dos riscos de falsos negativos e positivos.

Veja também a determinação de que dois URIs identificam o mesmo recurso (§2.7.2).

2.3.1. Aliases de URI

Embora existam benefícios (como a flexibilidade de nomes) nos aliases de URI, também há custos. Aliases de URI são danosos quando separam a Web de recursos relacionados. Um corolário do Princípio de Metcalfe (o “efeito rede”) é que o valor de um determinado recurso pode ser medido pelo número e pelos valores de outros recursos em sua vizinhança da rede, isto é, os recurso ligados a ele.

O problema com aliases é que, se, para determinado recurso, metade da vizinhança aponta para um URI e a outra metade aponta para outro, diferentes URIs para o mesmo recurso, a vizinhança fica dividida. Não apenas o recurso com alias fica desvalorizado por causa dessa divisão, mas toda a vizinhança de recursos perde valor devido à falta de relações de segunda ordem que deveriam existir entre os recursos referentes em virtude de suas referências ao recurso com alias.

Boa prática: Evitar aliases de URI

O proprietário do URI NÃO DEVE associar arbitrariamente diferentes URIs ao mesmo recurso.

Consumidores de URI também têm o dever de garantir a consistência do URI. Por exemplo, ao transcrever um URI, agentes não devem fazer codificação por cento de caracteres gratuitamente. O termo “caractere” refere-se a caracteres de URI, como definido na seção 2 de [URI]; a codificação por cento é discutida na seção 2.1 daquela especificação.

Boa prática: Uso de URI consistente

Um agente que recebe um URI DEVE referir-se ao recurso associado usando o mesmo URI, caractere a caractere.

Quando um alias de URI se torna comum, deve usar técnicas de protocolo, como redirecionamentos no lado servidor para relacionar os dois recursos. A comunidade se beneficia quando o o proprietário do URI apoia o redirecionamento de um URI com alias ao URI “oficial” correspondente. Para mais informações sobre redirecionamento, veja seção 10.3, Redirecionamento, em [RFC2616]. Veja também [CHIPS] para uma discussão sobre as melhores práticas para administradores de servidor.

2.3.2. Reutilização de representação

A atribuição de aliases a URIs ocorre apenas quando maestá de um URI é utilizado para identificar o mesmo recurso. O fato de que diferentes recursos às vezes têm a mesma representação não transforma os URIs em aliases para esses recursos.

História

Dirk gostaria de adicionar em seu website um link para o sítio de meteorologia de Oaxaca. Ele usa o URI http://weather.exemplo.com/oaxaca e nomeia seu link como “relatório meteorológico em Oaxaca em 1º de agosto de 2004”. Nádia salienta que Dirk está criando expectativas enganosas para o URI que usou. A política do sítio de meteorologia de Oaxaca é que o URI em questão identifica um relatório sobre o clima atual em Oaxaca – para qualquer dia – e não sobre o tempo em 1º de agosto. Logicamente, em 1º de agosto, o link de Dirk estará correto, mas no restante do tempo ele estará iludindo os leitores. Nádia indica para Dirk que os administradores do sítio de meteorologia de Oaxaca disponibilizam um URI diferente permanentemente designado para um recurso informando sobre o clima em 1º de agosto de 2004.

Nesta história, há dois recursos: “um relatório sobre o clima atual em Oaxaca” e “um relatório sobre o clima em Oaxaca em 1º de agosto de 2004”. Os administradores do sítio de meteorologia de Oaxaca designam dois URIs a esses dois recursos diferentes. Em 1º de agosto de 2004, as representações para esses recursos são idênticas. O fato de existirem duas URestá diferentes produzindo representações idênticas não implica que as duas URIs sejam aliases.

2.4. Esquemas de URI

Na URI "http://weather.example.com/", o "http" que aparece antes dos parênteses (":") determina um esquema de URI.Cada esquema de URI tem uma especificação que explica os detalhes específicos de como os identificadores do esquema estão alocados e se associam com um recurso. A sintaxe da URI é, então, um sistema de nomeação federado e extensível onde cada especificação de esquema pode, inclusive, restringir a sintaxe e a semântica dos identificadores que estão naquele esquema.

Exemplos de URestá de vários esquemas incluem:

Embora a arquitetura Web permita a definição de novos esquemas, introduzir um novo esquema é custoso. Muitos aspectos do processamento de URestá dependem de esquema, e uma grande quantidade de softwares lançados já processam URestá de esquemas bem conhecidos. Introduzir um novo esquema de URI exige o desenvolvimento e a implantação não apenas de softwares clientes para lidar com o esquema, mas também de agentes subordinados como gateways, proxies e caches. Veja a [RFC2718] para outras considerações e custos relacionados a projetos de esquema de URI.

Devido a esses custos, se existe um esquema de URI que supra as necessidades de um aplicativo, designers deveriam usá-lo em vez de inventar um.

Boas práticas: Reutilização de esquemas de URI

Uma especificação DEVE reutilizar um esquema de URI existente (em vez de criar um novo) quando ele oferece as propriedades desejadas de um identificador e sua relação com recursos.

Consideremos nosso cenário de viagem: deveria o agente fornecedor de informações sobre o tempo em Oaxaca registrar um novo esquema de URI “weather” para a identificação de recursos relacionados ao tempo? Ele poderia, então, publicar URIs como “weather://travel.exemplo.com/oaxaca”. Quando um agente de software desreferencia esse URI, se o que realmente acontece é que HTTP GET é invocado para obter uma representação do recurso, então o URI “http” teria sido suficiente.

2.4.1. Registro de esquema de URI

A Internet Assigned Numbers Authority (Autoridade para Atribuição de Números da Internet – (IANA) mantém um registro [IANASchemes] de mapeamento entre nomes de esquemas de URI e especificações de URI. Por exemplo, o registro IANA indica que o esquema “http” é definido em [RFC2616]. O processo de registrar um novo esquema de URI é definido na [RFC2717].

NÃO SE DEVE usar esquemas de URI não registrados por inúmeros motivos:

  • Não existe um modo geralmente aceito para localizar a especificação do esquema.
  • Outra pessoa pode estar usando o esquema para propósitos diversos.
  • Não se deve esperar que softwares generalistas façam algo útil com URestá desse esquema além de uma comparação de URIs.

Uma motivação enganosa para se registrar um novo esquema de URI é permitir que um agente de software inicialize um determinado aplicativo ao obter uma representação. O mesmo pode ser alcançado com custos menores expedindo-se com base no tipo de representação, assim possibilitando o uso de protocolos de transferência e implementações existentes.

Mesmo que um agente não consiga processar dados de representação em formato desconhecido, ele pode ao menos obtê-los. Os dados podem conter informações suficientes para permitir que um usuário ou agente de usuário os aproveite. Quando um agente não consegue lidar com um novo esquema de URI, ele não consegue obter uma representação.

o projetar um novo formato de dados, o mecanismo preferido para promover sua implantação na Web é o tipo de mídia de Internet (ver Tipos de Representação e Tipos de Mídia de Internet (§3.2)).Tipos de mídia também propiciam um meio de construir novas aplicações de informação, como descrito em direções futuras para formatos de dados (§4.6) .

2.5. Opacidade de URI

É tentador adivinhar a natureza de um recurso inspecionando o URI que o identifica. Contudo, a Web é projetada para que os agentes comuniquem o estado de um recurso de informação por meio de representações, não identificadores. Em geral, não se pode determinar o tipo de uma representação de recurso inspecionando o URI para aquele recurso.Por exemplo, o “.html” no final de “http://exemplo.com/page.html” não dá qualquer garantia de que as representações do recurso identificado serão emitidas com o tipo de mídia de Internet “text/html”. O editor é livre para alocar identificadores e definir como são emitidos. O protocolo HTTP não restringe o tipo de mídia de Internet com base no componente caminho do URI; o proprietário do URI é livre para configurar o servidor para retornar uma representação usando PNG ou qualquer outro formato de dados.

O estado do recurso pode evoluir com o tempo. Exigir que o proprietário de um URI publique um novo URI a cada mudança no estado do recurso levaria a um número significativo de referências quebradas. Para robustez, a arquitetura Web promove independência entre um identificador e o estado do recurso identificado.

Boa prática: opacidade de URI

Agentes utilizando URIs NÃO DEVEM tentar inferir propriedades do recurso referido.

Na prática, pode-se obter um pequeno número de inferências, porque são explicitamente licenciadas pelas especificações relevantes. Algumas dessas inferências são discutidas em detalhes da obtenção de uma representação (§3.1.1).

A URI exemplo utilizada no cenário de viagem (“http://weather.exemplo.com/oaxaca”) sugere a um leitor humano que o recurso identificado tem alguma relação com o tempo em Oaxaca. Um sítio informando sobre o tempo em Oaxaca poderia muito bem ser identificado também pelo URI “http://vjc.exemplo.com/315”. E o URI “http://weather.exemplo.com/vancouver” pode identificar o recurso “meu álbum de fotos”.

Por outro lado, o URI “mailto:joe@exemplo.com” indica que o URI refere-se a uma caixa postal. A especificação do esquema de URI “mailto” autoriza agentes a inferirem que URestá dessa forma identificam caixas postaestá de Internet.

Algumas autoridades de definição de URI documentam e publicam suas regras de definição de URI. Para mais informações sobre opacidade de URI, ver os boletins do TAG metaDataInURI-31 e siteData-36.

2.6. Identificadores de fragmento

História

Ao navegar pelo documento XHTML que Nadia recebe como uma representação do recurso identificado por “http://weather.exemplo.com/oaxaca”, Nadia descobre que o URI “http://weather.exemplo.com/oaxaca#fds” refere-se à parte da representação que contém informações sobre a previsão do final de semana. O URI inclui o identificador de fragmento “fds” (uma string depoestá de “#”).

O identificador de fragmento de um URI permite a identificação indireta de um recurso secundário para referir-se a um recurso primário e a informações de identificação adicionais. O recurso secundário pode ser uma parte ou subgrupo do recurso primário, uma visualização de representações do recurso primário, ou algum outro recurso definido ou descrito por essas representações. Os termos “recurso primário” e “recurso secundário” são definidos na seção 3.5 de [URI].

Os termos "primário" e “secundário”, nesse contexto, não limitam a natureza do recurso – não são classes. Neste contexto, primário e secundário simplesmente indicam que existe uma relação entre os recursos para os propósitos de um URI: o URI com um identificador de fragmento. Qualquer recurso pode ser identificado como um recurso secundário. Pode também ser identificado usando um URI sem um identificador de fragmento, e um recurso pode ser identificado como um recurso secundário por meio de múltiplos URIs. O propósito desses termos é possibilitar uma discussão sobre a relação entre esses recursos, não limitar a natureza de um recurso.

A interpretação de identificadores de fragmento é discutida na sessão sobre tipos de mídia e semântica de identificadores de fragmento (§3.2.1).

Veja o boletim do TAG abstractComponentRefs-37, que diz respeito ao uso de identificadores de fragmento com nomes de namespaces para identificar componentes abstratos.

2.7. Direções Futuras para Identificadores

Permanecem abertas questões a respeito de identificadores na Web.

2.7.1. Identificadores internacionalizados

A integração de identificadores internacionalizados (i.e., compostos de caracteres além daqueles permitidos por [URI]) na arquitetura Web é uma questão importante e aberta. Ver o boletim do TAG IRIEverywhere-27 para uma discussão sobre os trabalhos atuais nessa área.

2.7.2. Determinação de que dois URIs identificam o mesmo recurso

Tecnologias de Web Semântica emergentes, incluindo a “Web Ontology Language (OWL)” [OWL10], definem propriedades como sameAs para determinar que dois URIs identificam o mesmo recurso, ou iinverseFunctionalProperty para implicá-lo.

3. Interação

A comunicação entre agentes em uma rede sobre recursos envolve URIs, mensagens e dados. Os protocolos da Web (incluindo HTTP, FTP, SOAP, NNTP e SMTP) são baseados na troca de mensagens. Uma mensagem mpode incluir dados e metadados sobre um recurso (como os cabeçalhos HTTP “Alternates” e “Vary”), os dados da mensagem e a própria mensagem (como o cabeçalho HTTP “Transfer-encoding”). Uma mensagem pode até incluir metadados sobre os metadados da mensagem (por exemplo, para verificações de integridade da mensagem).

História

Nadia segue um link de hipertexto chamado “satellite image” esperando obter uma foto de satélite da região de Oaxaca. O link para a imagem de satélite é um link XHTML codificado como <a href=“http://exemplo.com/satimage/oaxaca”>imagem de satélite</a>. O navegador de Nadia analisa o URI e determina que seu esquema A configuração do navegador determina como ele localiza a informação identificada, que pode ser por cache de ações de obtenção prévias, por contato a um intermediário (como um servidor proxy), ou por acesso direto ao servidor identificado como uma porção do URI. Neste exemplo, o navegador abre uma conexão de rede com a porta 80 do servidor em “exemplo.com” e envia uma mensagem “GET”, como especificado pelo protocolo HTTP, requisitando uma representação do recurso.

O servidor envia uma mensagem de resposta ao navegador, mais uma vez de acordo com o protocolo HTTP. A mensagem consiste de diversos cabeçalhos e uma imagem JPEG. O navegador lê os cabeçalhos, descobre (a partir do campo “Content-Type”) que o tipo de mídia de Internet da representação é “image/jpeg”, lê a sequência de octetos e forma os dados de representação, apresentando a imagem. Esta seção descreve os princípios e restrições arquitetônicos a respeito de interações entre agentes, incluindo tópicos como protocolos de rede e estilos de interação, junto com interações entre a Web, enquanto sistema, e pessoas que a utilizam. O fato de a Web ser um sistema altamente distribuído afeta as restrições e declarações arquitetônicas sobre interações.

3.1. Usar um URI para Acessar um Recurso

Agentes podem usar um URI para acessar o recurso referido; isso é chamado de desreferenciamento de URI. O acesso pode assumir muitas formas, incluindo obter uma representação do recurso (por exemplo, usando HTTP GET ou HEAD), adicionar ou modificar uma representação do recurso (por exemplo, usando HTTP POST ou PUT, o que, em alguns casos, pode modificar o próprio estado do recurso caso as representações submetidas sejam interpretadas como instruções para isso) e deletar algumas ou todas as representações do recurso (por exemplo, usando HTTP DELETE, o que, em alguns casos, pode resultar na deleção do próprio recurso).

Pode haver maestá de uma maneira de acessar um recurso para determinado URI; o contexto da aplicação determina que método de acesso um agente usa. Por exemplo, um navegador pode usar HTTP GET para obter uma representação de um recurso, enquanto um verificador de link de hipertexto pode usar HTTP HEAD no mesmo URI simplesmente para estabelecer a disponibilidade de uma representação. Alguns esquemas de URI definem expectativas a respeito de métodos de acesso disponíveis, outros, não (como o esquema URN) [RFC 2141]). A Seção 1.2.2 do [URI] discute a separação de identificação e interação com maestá detalhes. Para mais informações sobre relações entre múltiplos métodos de acesso e endereçabilidade de URI, ver o texto do TAG "“URIs, Endereçabilidade e o uso de HTTP GET e POST”".

Embora muitos esquemas de URIs(§2.4) recebam seus nomes a partir de protocolos, isso não implica que o uso de tal URI irá necessariamente resultar em acesso ao recurso por meio do protocolo nomeado.

Mesmo quando um agente usa um URI para obter uma representação, o acesso pode ser por meio de gateways, proxies, caches e serviços de solução de nomes que sejam independentes do protocolo associado ao nome do esquema.Muitos esquemas de URI definem um protocolo de interação padrão para se tentar acessar o recurso identificado. Esse protocolo de interação muitas vezes é a base para alocar identificadores dentro daquele esquema, assim como URIs “http” são definidos em termos de servidores HTTP baseados em TCP. Contudo, isso não implica que toda interação com tais recursos seja limitada ao protocolo de interação padrão. Por exemplo, sistemas de obtenção de informação costumam utilizar proxies para interagir com uma enormidade de esquemas de URI, como por exemplo proxies HTTP sendo usados para acessar recursos “ftp” e “wais”. Proxies também podem fornecer serviços melhorados, como proxies anotações que combinam obtenção de informações normais com obtenção de metadados adicionais para propiciar uma imagem limpa, multidimensional de recursos usando os mesmos protocolos e agentes de usuário, como a Web não anotada. Da mesma forma, podem-se definir protocolos futuros de forma que englobem nossos sistemas atuais, usando mecanismos de interação totalmente diferentes, sem alterar os esquemas identificadores existentes. Ver também princípios de especificações ortogonais (§5.1)..

3.1.1. Detalhes da obtenção de uma representação

Desreferenciar um URI em geral envolve uma sequência de passos, como descrita em inúmeras especificações e implementada pelo agente. O exemplo a seguir ilustra a série de especificações que governa o processo em que um agente de usuário é instruído a seguir um link de hipertexto (§4.4) que seja parte de um documento SVG. Neste exemplo, o URI é http://weather.exemplo.com/oaxaca, e o contexto do aplicativo exige que o agente de usuário obtenha e faça uma representação do recurso identificado.

  1. 1 Como o URI é parte de um link de hipertexto em um documento SVG, a primeira especificação relevante é a Recomendação SVG 1.1 [SVG11]. Seção 17.1 1 desta especificação importa a semântica do link definida em [XLink10]: "O recurso remoto (a destinação do link) é definido por um URI especificado pelo atributo href no elemento 'a'" A especificação SVG especifica que um elemento a envolve obter a representação de um recurso, identificado pelo atributo href no namespace XLink: "Ao ativar esses links (clicando com o mouse, por meio do teclado, comando de voz, etc.), os usuários podem visitar os recursos”."
  2. A especificação[XLink10], que define o atributo href href na seção 5.4, define que “o valor do atributo href deve ser uma referência URI como definida em [IETF RFC 2396], ou deve resultar em uma referência URI após ser aplicado o procedimento de saída descrito abaixo”.
  3. A especificação URI [URI]declara que “cada URI começa com um nome de esquema que se refere a uma especificação para definir identificadores dentro daquele esquema”. O nome de esquema de URI neste exemplo é “http”.
  4. [IANASchemes] define que o esquema “http” é definido pela especificação HTTP/1.1 (RFC 2616 [RFC2616], seção 3.2.2).
  5. Neste contexto SVG, o agente constrói um pedido HTTP GET (de acordo com a seção 9.3 da [RFC2616]) para obter a representação.
  6. A seção 6 da [RFC2616]define como o servidor constrói uma mensagem de resposta correspondente, incluindo o campo “Content-Type”.
  7. Seção 1.4 da [RFC2616]afirma que “a comunicação HTTP em geral acontece sobre conexões TCP/IP”. Este exemplo não aborda nem aquele passo no processo, nem outros, como a resolução Domain Name System (DNS).
  8. O agente interpreta a representação retornada de acordo com a especificação de formato de dados que corresponda ao tipo de mídia de Internet (§3.2) (o valor do “Content-Type” HTTP) no registro IANA relevante [MEDIATYPEREG].

PSaber precisamente que representação(ões) é(são) obtida(s) depende de inúmeros fatores. Entre eles:

  1. Se o proprietário do URI disponibiliza alguma representação;
  2. 1 Se o agente que faz o pedido tem privilégios de acesso para aquelas representações (ver a seção sobre links e controle de acesso (§3.5.2));
  3. 1 Se o proprietário do URI forneceu maestá de uma representação (em diferentes formatos, como HTML, PNG ou RDF; em diferentes idiomas, como inglês e espanhol; ou dinamicamente transformados de acordo com as capacidades de hardware ou software do recipiente), a representação resultante pode depender da negociação entre o agente de usuário e o servidor.
  4. O momento do pedido; o mundo muda com o tempo, de forma que representações de recursos também podem mudar com o tempo.

Assumindo-se que se tenha conseguido obter bem uma representação, o poder expressivo do formato da representação afetará a precisão de como o provedor de representações comunica o estado do recurso. Se a representação comunica o estado do recurso de forma imprecisa, esta imprecisão ou ambiguidade pode levar a confusão entre usuários sobre o que é o recurso. Se diferentes usuários alcançam diferentes conclusões sobre o que é o recurso, eles podem interpretar isso como uma colisão de URIs (§2.2.1). Algumas comunidades, como aquelas que desenvolvem a Web Semântica, buscam fornecer uma estrutura para comunicar de maneira precisa a semântica de um recurso de uma forma que uma máquina consiga ler. A semântica para ser lida em máquina pode aliviar parte da ambiguidade associada a descrições de recursos em línguas naturais.

3.2. Tipos de Representação e Tipos de Mídia de Internet

Uma representação constitui-se de dados que codificam informações sobre o estado do recurso. Representações não descrevem necessariamente o recurso, ou retratam algo semelhante ao recurso, ou representam o recurso em outros sentidos da palavra “representar”.

Representações de um recurso podem ser enviadas ou recebidas usando-se protocolos de interação. Esses protocolos, por sua vez, determinam o modo como representações são expressas na Web. O HTTP, por exemplo, possibilita a transmissão de representações como octet streams rotulados usando-se os tipos de mídia para Internet [RFC2046]. Assim como é importante reutilizar esquemas de URI existentes sempre que possível, existem benefícios significativos em se usar octet streams rotulados conforme a mídia para representações mesmo no caso incomum em que se deve definir um novo esquema de URI e seu respectivo protocolo. Por exemplo, se o tempo de Oaxaca fosse entregue ao navegador de Nadia usando-se um protocolo diferente de HTTP, o software para produzir formatos como text/xhmtl+xml e image/png ainda seria usável se o novo protocolo suportasse transmissão desses tipos. Este é um exemplo do princípio de especificações ortogonais (§5.1).

Boas práticas: Reutilizar formatos de representação

Novos protocolos criados para a Web DEVEM transmitir representações de octet streams rotulados conforme os tipos de mídia de Internet.

O mecanismo de tipo de mídia de Internet tem, de fato, algumas limitações. Por exemplo, strings de tipo de mídia não suportam versionamento (§4.2.1) ou outros parâmetros. Ver os boletins do TAG uriMediaType-9 e mediaTypeManagement-45 que dizem respeito a aspectos do mecanismo de tipo de mídia.

3.2.1. Tipos de representação e semântica do identificador de fragmentos

O tipo de mídia de Internet define a sintaxe e a semântica do identificador de fragmento (apresentado em Identificadores de Fragmento (§2.6)), se houver, que possa ser usado em conjunto com uma representação.

História

Em uma de suas páginas XHTML, Dirk cria um link de hipertexto para uma imagem que Nadia publicou na Web. Ele cria um link de hipertexto com <a href="http://www.example.com/images/nadia#hat">Nadia's hat</a>. Emma vê a página XHTML de Dirk em seu navegador Web e clica no link. A implementação HTML em seu navegador remove o fragmento do URI e solicita a imagem “http://www.exemplo.com/images/nadia”. Nadia disponibiliza uma representação SVG da imagem (com o tipo de mídia de Internet “image/svg+xml”). O navegador Web de Emma inicia uma implementação SVG para ver a imagem. Passa para o URI original incluindo o fragmento, “http://www.example.com/images/nadia#hat”, de forma a fazer esta implementação, causando uma visualização do chapéu a ser apresentada, e não a imagem completa.

Observe que a implementação HTML no navegador de Emma não precisa entender a sintaxe ou a semântica do fragmento SVG (nem a implementação SVG precisa entender HTML, WebCGM, RDF... sintaxe ou semântica de fragmento; simplesmente precisa reconhecer o delimitador # da sintaxe URI [URI] e remover o fragmento ao acessar o recurso). Esta ortogonalidade (§5.1) é uma característica importante da arquitetura Web; é isso que possibilitou que o navegador de Emma fornecesse um serviço útil sem exigir uma atualização.

A semântica de um identificador de fragmentos é definida pelo conjunto de representações que podem resultar de uma ação de obtenção sobre o recurso primário. O formato e a resolução do fragmento são, portanto, dependentes do tipo da representação potencialmente obtida, mesmo que essa obtenção só seja realizada se o URI é desreferenciado. Se não existir essa representação, a semântica do fragmento é considerada desconhecida e, efetivamente, ilimitada. A semântica do identificador de fragmentos é ortogonal a esquemas de URI e, assim, não pode ser redefinida por especificações de esquemas de URIs.

A interpretação do identificador de fragmentos é realizada unicamente pelo agente que desreferencia um URI; o identificador de fragmentos não é passado a outro sistema durante o processo de obtenção. Isso significa que alguns intermediários na arquitetura Web (como proxies) não têm interação com identificadores de fragmentos e que esse redirecionamento (em HTTP [RFC2616], por exemplo) não é responsável por fragmentos.

3.2.2. Identificadores de fragmento e negociação de conteúdo

Negociação de conteúdo refere-se à prática de disponibilizar diversas representações por meio do mesmo URI. A negociação entre o agente requerente e o servidor determina que representação se dá (em geral, com o objetivo de dar a “melhor” representação que um agente receptor pode processar). HTTP é um exemplo de protocolo que possibilita que provedores de representação usem negociação de conteúdo.

Alguns formatos de dados podem definir suas próprias regras de uso de sintaxe de identificador de fragmento para especificar diferentes tipos de subconjuntos, visualizações ou referências externas que sejam identificáveis como recursos secundários por aquele tipo de mídia. Portanto, provedores de representação devem gerenciar negociação de conteúdo de maneira cuidadosa quando usados com um URI que contenha um identificador de fragmento. Consideremos um exemplo em que o proprietário do URI “http://weather.exemplo.com/oaxaca/map#zicatela” usa negociação de conteúdo para dar duas representações do recurso identificado. Três situações podem surgir:

  1. 1 A interpretação de “zicatela” é definida de maneira consistente por ambas as especificações de formato de dados. O provedor de representação decide quando definições de semântica de identificador de fragmentos são suficientemente consistentes.
  2. A interpretação de “zicatela” é definida de maneira inconsistente pelas especificações de formato de dados.
  3. A interpretação de “zicatela” é definida em uma especificação de formato de dados, mas não pela outra.

A primeira situação – semântica consistente – não apresenta problemas.

O segundo caso é um erro de gerenciamento de servidor: provedores de representação não devem usar negociação de conteúdo para atender a formatos de representação que tenham semântica de identificador de fragmentos inconsistente. Essa situação também leva a colisão de URIs (§2.2.1).

O terceiro caso não é um erro de gerenciamento de servidor. É um meio pelo qual a Web pode crescer. Como a Web é um sistema distribuído em que formatos e agentes são entregues de uma maneira não uniforme, a arquitetura Web não restringe autores a usarem apenas formatos de “denominadores comuns mais baixos”. Autores de conteúdo podem aproveitar os novos formatos de dados ao mesmo tempo que garantem uma compatibilidade razoável com anteriores para agentes que ainda não os implementaram.

No terceiro caso, o comportamento do agente receptor deve variar se o formato negociado define a semântica do identificador de fragmentos. Quando um formato de dados recebidos não define a semântica do identificador de fragmentos, o agente não deve realizar uma recuperação de erros silenciosa a não ser que o usuário tenha consentido; ver [CUAP] para mais comportamentos de agente sugeridos neste caso.

Ver o boletim do TAG referente a isso: RDFinXHTML-35.

3.3. Inconsistências entre Dados e Metadados de Representação

Uma boa comunicação entre duas partes depende de um entendimento razoável de ambas da semântica das mensagens trocadas, tanto dados como metadados. De vez em quando, pode haver inconsistências entre os dados e os metadados do remetente da mensagem. Entre os exemplos, observados na prática, de inconsistência entre dados e metadados de representação, estão:

Por outro lado, não existe inconsistência em apresentar conteúdo HTML com o tipo de mídia “text/plain”, por exemplo, já que esta combinação é licenciada por especificações.

Agentes receptores devem detectar inconsistências de protocolo e realizar uma recuperação de erro adequada.

Restrição: Inconsistência dados-metadados

Agentes NÃO DEVEM ignorar metadados de mensagem sem o consentimento do usuário.

Assim, por exemplo, se as partes responsáveis por “weather.exemplo.com”, por engano, nomeassem a foto de satélite com Oaxaca como “image/gif” em vez de “image/jpeg”, e se o navegador de Nadia detectasse um problema, o navegador de Nadia não deveria ignorar o problema (por exemplo, simplesmente entregando a imagem JPEG) sem o consentimento de Nadia.O navegador de Nadia poderia notificar Nadia do problema ou notificar Nadia e realizar uma ação corretiva.

Além disso, provedores de representação podem ajudar a reduzir o risco de inconsistências por meio de declarações cuidadosas de metadados de representação (especialmente aqueles que se aplicam a representações). A seção sobre tipos de mídia para XML (§4.5.7) apresenta um exemplo de redução de risco de erros ao se não oferecer metadados sobre codificação de caracteres quando se usa XML.

A precisão dos metadados depende dos administradores do servidor, dos autores das representações e do software que usam. De modo prático, as capacidades das ferramentas e as relações sociais podem ser os fatores limitadores.

A precisão desses e de outros campos de metadados é tão importante para os recursos de Web dinâmicos que um pouco de pensamento e programação, muitas vezes, pode garantir metadados corretos para um grande número de recursos.

Frequentemente, existe uma separação de controle entre os usuários que criam representações de recursos e os gerenciadores de servidores que mantêm o software do website. Como em geral é o software do website que fornece os metadados associados a um recurso, é necessária a coordenação entre os gerenciadores de servidores e os criadores de conteúdos.

Boa prática: Associação de metadados

Gerenciadores de servidores DEVEM permitir que os criadores de representações controlem os metadados associados a suas representações.

Em particular, criadores de conteúdos devem ser capazes de controlar o tipo de conteúdo (para extensibilidade) e a codificação de caracteres (para a internacionalização adequada).

Os estudos do TAG sobre" Metadados confiáveis, ou autoritativos" discute em maestá detalhes como lidar como inconsistências dados/metadados e como a configuração do servidor pode ser usada para evitá-las.

3.4. Interações seguras

A obtenção, por Nadia, de informações sobre o tempo (um exemplo de uma busca ou pedido só leitura) qualifica-se como uma interação “segura”; uma interação segura é aquela em que o agente não incorre em qualquer obrigação além da interação. Um agente pode incorrer em uma obrigação por outros meios (como ao assinar um contrato). Se o agente não tem uma obrigação antes de uma interação segura, ele não tem nenhuma obrigação depois.

Outras interações de Web lembram mais ordens do que pedidos. Estas interações inseguras podem causar uma mudança do estado de um recurso e o usuário pode ser responsabilizado pelas consequências dessas interações. Interações inseguras incluem assinar uma newsletter, postar em uma lista ou modificar um banco de dados. Nota: Neste contexto, a palavra “insegura” não significa necessariamente “perigosa”; o termo “seguro” é usado na seção 9.1.1 da [RFC2616] ae “inseguro” é seu antinômio natural.

História

Nadia decide reservar uma viagem a Oaxaca em “booking.exemplo.com”. Ela entra seus dados em uma série de formulários on-line e, no fim, é-lhe pedido o número do cartão de crédito para adquirir passagens aéreas. Ela fornece essa informação em outro formulário. Quando aperta o botão “Adquirir”, o navegador dela abre outra conexão de rede com o servidor em “booking.exemplo.com” e envia uma mensagem composta de dados form usando o método POST.Esta é uma interação insegura; Nadia deseja mudar o estado do sistema trocando dinheiro por passagens aéreas.

O servidor lê o pedido POST e, depoestá de realizar o agendamento, retorna uma mensagem para o navegador de Nadia que contém uma representação dos resultados do pedido de Nadia. Os dados de representação estão em HTML, de forma que possam ser salvos ou impressos nos registros de Nadia.

Note that neither the data transmitted with the POST nor the data received in the response necessarily correspond to any resource identified by a URI.

Observem que nem os dados transmitidos com POST nem os dados recebidos em resposta necessariamente correspondem a qualquer recurso identificado por um URI. Interações seguras são importantes porque essas são interações em que usuários podem navegar com confiança e em que agentes (incluindo ferramentas de busca e navegadores que pré-armazenam dados para os usuários) podem seguir com segurança links de hipertexto. Usuários (ou agentes atuando em seu nome) não se comprometem a nada ao buscar um recurso ou ao seguir um link de hipertexto.

Princípio: Obtenção segura

Agentes não ficam sujeitos a obrigações ao obter uma representação.

Por exemplo, é incorreto publicar um URI que, quando seguido como parte de um link de hipertexto, subscreve um usuário a uma mailing list. Lembre-se de que ferramentas de busca podem seguir esses links hipertexto.

O fato de que HTTP GET, o método de acesso mais usado quando se segue um link de hipertexto, é seguro, não implica que todas as interações seguras devam ser feitas por meio de HTTP GET. De vez em quando, pode haver boas razões (como exigências de confidencialidade ou limites práticos sobre comprimento de URI) para se realizar uma operação antes segura usando-se um mecanismo geralmente reservado para operações inseguras (por exemplo, HTTP POST).

Para mais informações sobre operações seguras e inseguras usando HTTP GET e POST, e sobre como lidar com questões de segurança no que se refere ao uso de HTTP GET, ver o texto do TAG "“URIs, Endereçabilidade e o uso de HTTP GET e POST”.".

3.4.1. Interações inseguras e responsabilização

Story

Nadia paga por suas passagens aéreas on-line (por uma interação POST, como descrito acima). Ela recebe uma página Web com informações de confirmação e quer marcá-la de forma que possa consultá-la quando for calcular suas despesas. Embora Nadia possa imprimir os resultados, ou salvá-los em um arquivo, ela também gostaria de marcá-los.

Pedidos e resultados de transações são recursos valiosos e, como todos os recursos valiosos, são úteis para serem consultados a partir de uma URI persistente (§3.5.1). No entanto, na prática, Nadia não pode marcar seu compromisso de pagar (expresso pela solicitação POST) ou o reconhecimento e o compromisso da companhia aérea de fornecer-lhe um voo (expresso pela resposta ao POST).

Há maneiras de fornecer URIs persistentes para os pedidos de transação e seus resultados. Para solicitações de transação, os agentes podem fornecer uma interface para gerenciar transações em que o agente de usuário tenha ficado sujeito a uma obrigação em nome do usuário. Para resultados de transações, o HTTP permite que provedores de representação associem um URI aos resultados de uma solicitação HTTP POST usando o cabeçalho “Content-Location” (descrito na seção 14.14 de [RFC2616]).

3.5. Gerenciamento de Representação

History

Como Nadia considera útil o sítio do tempo de Oaxaca, ela envia observações acerca dele a seu amigo Dirk, recomendando-lhe que o visite em “http://weather.exemplo.com/oaxaca”. Dirk clica no link de hipertexto resultante no e-mail que recebe e é frustrado por um 404 (não encontrado). Dirk tenta de novo no dia seguinte e recebe uma representação com notícias que são de duas semanas atrás. Ele tenta mais uma vez no dia seguinte, mas recebe uma representação que afirma que o tempo em Oaxaca está ensolarado, apesar de seus amigos em Oaxaca lhe dizerem por telefone que, na verdade, está chovendo. Dirk e Nadia concluem que os proprietários do URI são não confiáveis ou imprevisíveis. Embora o proprietário do URI tenha escolhido a Web como meio de comunicação, o proprietário perdeu dois clientes devido a uma gestão ineficaz de representação.

O proprietário de um URI pode fornecer zero ou mais representações autorizadas do recurso identificado por esse URI. Há benefícios para a comunidade em fornecer representações.

Boa prática: Representação disponível

Um proprietário de URI DEVE fornecer representações do recurso que ele identifica.

Por exemplo, proprietários de URestá de namespaces XML devem usá-los para identificar um documento de namespace (§4.5.4).

Só o fato de haver representações disponíveis não significa que é sempre desejável obtê-las. Na verdade, em alguns casos, o oposto é verdadeiro.

Princípio: Referência não implica desreferência

Um desenvolvedor de aplicativos ou autor de especificações NÃO DEVE exigir a obtenção em rede de representações toda vez que são referidos.

Desreferenciar um URI tem um custo (potencialmente significativo) de programação e de recursos de largura de banda, pode ter implicações de segurança e pode impor latência significativa sobre o aplicativo desreferenciante. Deve-se evitar desreferenciar URIs, exceto quando necessário.

As seções a seguir discutem alguns aspectos de gestão de representações, incluindo a promoção de persistência de URIs (§3.5.1), gerenciamento do acesso aos recursos (§3.5.2) e suporte de navegação (§3.5.3).

3.5.1. Persistência de URI

Como ocorre com muitas interações humanas, a confiança nas interações via Web depende de estabilidade e previsibilidade. Para um recurso de informação, a persistência depende da consistência das representações. O provedor de representações decide quando as representações são suficientemente consistentes (embora essa determinação geralmente leve em conta as expectativas dos usuários).

Ainda que, neste caso, persistência seja observada como um resultado de uma obtenção de representação, o termo persistência de URIs é usado para descrever a propriedade desejável de que, uma vez associado a um recurso, um URI deve continuar indefinidamente referindo-se a este recurso.

Boa prática: Representação consistente

Um proprietário de URI DEVE fornecer representações do recurso identificado de modo consistente e previsível.

Persistência de URI é uma questão de política e compromisso por parte do proprietário da URI. A escolha de determinado esquema de URI não oferece qualquer garantia de que esses URIs serão estáveis ou que não serão estáveis.

O HTTP [RFC2616] foi projetado para ajudar a gerenciar a persistência de URI. Por exemplo, o redirecionamento de HTTP (utilizando os códigos de resposta 3xx) permite que servidores contem a um agente que outra ação precisa ser tomada por ele a fim de atender à solicitação (por exemplo, um novo URI ser associado ao recurso).

Além disso, a negociação de conteúdo também promove consistência, já que não é necessário que o administrador de um sítio defina novos URIs ao incluir suporte para uma nova especificação de formato. Protocolos que não suportam negociação de conteúdo (como FTP) exigem um novo identificador quando é introduzido um novo formato de dados. O uso inadequado de negociação de conteúdo pode levar a representações inconsistentes.

Para maestá discussões sobre estabilidade de URI, ver [Cool].

3.5.2. Links e controle de acesso

É importante limitar o acesso a um recurso (por razões comerciais ou de segurança, por exemplo), mas simplesmente identificar o recurso é como se referir a um livro pelo título. Em circunstâncias excepcionais, as pessoas podem entrar em acordo sobre manter confidenciais títulos ou URIs (por exemplo, o autor de um livro e uma editora podem concordar em manter em segredo o URI da página que contém material adicional até que o livro seja publicado); se esse acerto não houver, as partes são livres para divulgá-los.

Uma analogia: Os proprietários de um edifício podem definir uma regra de que o público só poderá entrar no edifício pela porta principal, e apenas durante o horário comercial. As pessoas que trabalham no prédio e aquelas que fazem entregas podem usar outras portas, mais apropriadas. Tal regra seria reforçada por uma combinação de agentes de segurança e dispositivos mecânicos, como fechaduras e pass-cards. Não se faria cumprir esta regra escondendo algumas entradas do edifício, nem por um código que exigisse o uso da porta da frente e proibisse qualquer pessoa de revelar a existência de outras portas no prédio.

História

Nadia envia a Dirk o URI do artigo que está lendo naquele momento. Com seu navegador, Dirk segue o link de hipertexto e é solicitado a digitar o nome de usuário e senha do assinante. Como Dirk também é assinante dos serviços prestados por “weather.exemplo.com”, ele consegue acessar a mesma informação que Nadia. Dessa forma, a autoridade de “weather.exemplo.com” pode limitar o acesso a pessoas autorizadas e ainda fornecer os benefícios de URIs.

A Web oferece vários mecanismos para controlar o acesso a recursos; esses mecanismos não se baseiam em esconder ou suprimir URIs para esses recursos. Para mais informações, ver o texto do TAG "'Links Profundos' na World Wide Web".

3.5.3. Navegação de apoio

Uma das vantagens da Arquitetura Web é que se pode fazer e compartilhar links; um usuário que descobriu uma parte interessante da Web pode compartilhar essa experiência apenas republicando um URI.

História

Nadia e Dirk querem visitar o Museu da Previsão do Tempo em Oaxaca. Nadia vai a “http://maps.exemplo.com”, localiza o museu e envia o URI “http://maps.exemplo.com/oaxaca?lat=17.065;lon=-96.716;scale=6” para Dirk. Dirk vai a “http://mymaps.exemplo.com”, localiza o museu e envia o URI “http://mymaps.exemplo.com/geo?sessionID=765345;userID=Dirk” para Nadia. Dirk lê o e-mail de Nadia e consegue seguir o link até o mapa. Nadia lê o e-mail de Dirk, clica no link e recebe a mensagem de erro “Não existe essa sessão/usuário”. Nadia precisa começar mais uma vez de “http://mymaps.exemplo.com” para voltar a encontrar a localização do museu.

Para recursos que são gerados sob demanda, é comum a geração maquinal de URIs. Para recursos que possam ser convenientemente marcados para consulta posterior, ou compartilhados com outras pessoas, os gerenciadores de servidor devem evitar restringir de maneira desnecessária a reutilização de tais URIs. Se a intenção é restringir a informação para um usuário específico, como é o caso em uma aplicação em home banking, por exemplo, os programadores devem usar mecanismos adequados de controle de acesso (§3.5.2).

Interações realizadas com HTTP POST (em que se poderia ter usado HTTP GET) também limitam as possibilidades de navegação. O usuário não consegue marcar ou compartilhar o URI, pois as transações HTTP POST não costumam resultar em um URI diferente quando o usuário interage com o sítio.

3.6. Direções Futuras para Interação

Restam perguntas abertas a respeito das interações Web. O TAG espera que futuras versões deste documento abordem com maestá detalhes a relação entre a arquitetura aqui descrita, Web Services, sistemas peer-to-peer, sistemas de mensagens instantâneas (como [RFC3920]), streaming de áudio (como RTSP [RFC2326]), e voz sobre IP (como o SIP [RFC3261]).

4. Formatos de Dados

Uma especificação de formato de dados (por exemplo, para XHTML, RDF/XML, SMIL, XLink, CSS e PNG) traz em si um acordo sobre a interpretação correta dos dados de representação. O primeiro formato de dados usado na Web foi o HTML. Desde então, os formatos de dados cresceram em número. A arquitetura Web não restringe os formatos de dados que provedores de conteúdo podem usar. Esta flexibilidade é importante porque ocorre uma evolução constante dos aplicativos, resultando em novos formatos de dados e refinamentos de formatos existentes. Embora a arquitetura Web permita a implantação de novos formatos de dados, a criação e a implantação de novos formatos (e agentes capazes de lidar com eles) são dispendiosas. Assim, antes de inventar um novo formato de dados (ou “meta” formato, como XML), os programadores devem pensar seriamente em reutilizar um que já esteja disponível.

Para um formato de dados ser interoperável entre duas partes, as partes devem concordar (de forma razoável) sobre sua sintaxe e semântica. Um entendimento compartilhado de um formato de dados promove interoperabilidade, mas não implica restrições sobre o uso; por exemplo, um remetente de dados não pode contar com a possibilidade de limitar o comportamento de um receptor de dados.

A seguir, descrevemos algumas características de um formato de dados que facilitam a integração à arquitetura Web. Este documento não aborda características geralmente benéficas de uma especificação, como a legibilidade, simplicidade, atenção aos objetivos do programador, atenção às necessidades do usuário, acessibilidade ou internacionalização. A seção sobre especificações arquitetonicas (§7.1) traz referências a diretrizes adicionaestá de especificação de formato.

4.1. Formatos de Dados Binários e Textuais

Formatos de dados binários são aqueles em que partes dos dados são codificados para uso direto por processadores informáticos, por exemplo complementos de 2 em little-endian de 32 bits e ponto flutuante de precisão dupla IEEE de 64 bits. As porções de dados assim representados incluem valores numéricos, ponteiros e dados comprimidos de todos os tipos.

Um formato de dados textuais é aquele em que dados são especificados em uma codificação definida como uma sequência de caracteres. HTML, e-mail de Internet e todos os formatos baseados em XML(§4.5) são textuais. Cada vez mais, formatos de dados textuais internacionalizados referem-se ao repertório [UNICODE] para definições de caracteres.

Um formato de dados ser textual, conforme definido nesta seção, não implica que ele deva ser apresentado com um tipo de mídia que se inicie com “text/”. Apesar de formatos baseados em XML serem textuais, muitos formatos baseados em XML não consistem basicamente de frases em linguagem natural. Veja a seção sobre tipos de mídia para XML (§4.5.7) para questões que surgem quando “text/” é usado em conjunto com um formato baseado em XML.

Em princípio, todos os dados podem ser representados com formatos textuais. Na prática, alguns tipos de conteúdo (por exemplo, áudio e vídeo) costumam ser representados com formatos binários.

As escolhas entre formatos de dados textuais e binários são complexas e dependem do aplicativo. Formatos binários podem ser substancialmente mais compactos, em especial para estruturas de dados com ponteiro complexas. Além disso, podem ser consumidos mais rapidamente por agentes nos casos em que podem ser carregados na memória e utilizados com pouca ou nenhuma conversão. Note, no entanto, que esses casos são relativamente raros, já que tal uso direto pode abrir a porta para questões de segurança que só podem ser resolvidas, de modo prático, pela análise detalhada de todos os aspectos da estrutura de dados.

Formatos textuais são geralmente mais portáteis e interoperáveis. Formatos textuais também têm a considerável vantagem de poderem ser lidos diretamente por seres humanos (e compreendidos, desde que haja documentação suficiente). Isso pode simplificar as tarefas de criação e manutenção de softwares e permitir a intervenção direta de seres humanos na cadeia de processamento sem se recorrer a ferramentas mais complexas do que o onipresente editor de texto. Por fim, simplifica a necessária tarefa humana de aprender sobre novos formatos de dados, o que é chamado de efeito "view source".

É importante ressaltar que a intuição quanto a questões como tamanho dos dados e velocidade de processamento não é um indicador muito confiável para projeto de formato de dados; estudos quantitativos são essenciais para a compreensão correta da escolha por um ou outro. Por isso, os programadores de uma especificação de formato de dados devem fazer uma opção ponderada entre formato binário e textual.

Ver o boletim do TAG binaryXML-30.

4.2. Versionamento e Extensibilidade

Em um mundo perfeito, programadores de linguagem inventariam linguagens que cumprissem perfeitamente os requisitos que lhes são apresentados, os requisitos seriam um modelo perfeito do mundo, que nunca mudariam com o tempo, e todas as implementações seriam perfeitamente interoperáveis, já que não haveria variabilidade nas especificações.

No mundo real, programadores de linguagem lidam de modo imperfeito com os requisitos ao interpretá-los, os requisitos modelam de forma imprecisa o mundo, requisitos conflitantes são apresentados, e eles mudam ao longo do tempo. Como consequência, programadores negociam com usuários, fazem concessões e, muitas vezes, introduzem mecanismos de extensibilidade para que seja possível contornar problemas em curto prazo. No longo prazo, produzem várias versões de suas linguagens, conforme o problema, e sua compreensão, evoluem. A consequente variabilidade – em especificações, linguagens e implementações – introduz custos de interoperabilidade.

Extensibilidade e versionamento são estratégias para ajudar a gerenciar a evolução natural de informações na Web e as tecnologias utilizadas para representar essas informações. Para maestá dados sobre como essas estratégias introduzem variabilidade e como tal variabilidade impacta a interoperabilidade, ver Variabilidade em Especificações..

Ver o boletim do TAG XMLVersioning-41, que diz respeito a boas práticas para programar linguagens XML extensíveis e para lidar com versionamento. Ver também “Arquitetura Web: linguagens extensíveis” [EXTLANG].

4.2.1. Versionamento

Costuma haver um período (longo) de transição durante o qual várias versões de um formato, protocolo ou agente ficam simultaneamente em uso.

Boa prática: Informação da versão

Uma especificação de formato de dados DEVE fornecer informações sobre a versão.

4.2.2. Versionamento e política para namespaces XML

História

Nadia e Dirk estão criando um formato de dados XML para codificar dados sobre a indústria cinematográfica. Eles se preparam para extensibilidade usando namespaces XML e criando um esquema que permite a inclusão, em certos lugares, de elementos de qualquer namespace. Ao reverem seu formato, Nadia propõe um novo atributo lang no elemento film. Dirk sente que tal mudança exige que atribuam um novo nome de namespace, o que pode demandar alterações no software implantado. Nadia conta a Dirk que a opção pela estratégia de extensibilidade em conjunto com sua política de namespaces permite certas mudanças que não afetam a conformidade de conteúdos e softwares existentes e, portanto, não é necessária alteração alguma no identificador de namespace. Eles escolheram essa política para que conseguissem atingir seus objetivos de reduzir o custo da alteração.

Dirk e Nadia escolheram uma política de mudança de namespace que lhes permite evitar a alteração do nome do namespace sempre que haja mudanças que não afetem a conformidade do conteúdo e do software implantados. Eles poderiam ter escolhido uma política diferente, por exemplo que qualquer novo elemento ou atributo deva pertencer a um namespace diferente do original. Seja qual for a política escolhida, deve-se definir claramente as expectativas para os usuários do formato.

Em geral, a alteração do nome do namespace de um elemento muda completamente o nome do elemento. Se "a" e "b" são ligados a duas URestá diferentes, a:element e b:element são tão distintos quanto a:eieio e a:xyzzy. Em termos práticos, isso significa que os aplicativos implementados precisarão ser atualizados, a fim de reconhecer a nova linguagem; o custo da atualização pode ser muito alto.

Conclui-se que há vantagens e desvantagens importantes a serem consideradas quando se decide sobre uma política de mudança de namespace. Se um vocabulário não tem pontos de extensibilidade (isto é, se ele não permite elementos ou atributos de namespaces estranhos, ou se tem um mecanismo para lidar com nomes não reconhecidos do mesmo namespace), pode ser absolutamente necessário mudar o nome do namespace. Linguagens que permitem alguma forma de extensibilidade sem a necessidade de mudar o nome do namespace são mais aptas a evoluir normalmente.

Boa prática: Política de namespace

Uma especificação de formato XML DEVE incluir informações sobre as políticas de mudança de namespaces XML.

Como exemplo de uma política de mudança projetada para refletir a estabilidade variável de um namespace, considerem a política de namespaces do W3Cpara documentos na linha da Recomendação W3C. A política estabelece expectativas de forma que o Grupo de Trabalho responsável pelo namespace consiga modificá-lo de qualquer maneira até determinado ponto do processo (“Recomendação Candidata”), quando então o W3C restringe o conjunto de possíveis alterações no namespace a fim de promover implementações estáveis.

Note-se que, como nomes de namespace são URIs, o proprietário de um URI de namespace tem a autoridade para decidir a política de mudança de namespace.

4.2.3. Extensibilidade

Requisitos mudam ao longo do tempo. Tecnologias bem-sucedidas são adotadas e adaptadas por novos usuários. Programadores podem facilitar o processo de transição fazendo opções cuidadosas sobre extensibilidade durante a concepção de uma linguagem ou especificação de protocolo.

Ao fazer essas escolhas, os programadores devem pesar as vantagens e desvantagens entre extensibilidade, simplicidade e variabilidade. Uma linguagem sem mecanismos de extensibilidade pode ser mais simples e menos variável, melhorando a interoperabilidade inicial. No entanto, é provável que mudar essa linguagem seja maestá difícil, talvez mais complexo e variável, do que caso o projeto inicial tenha fornecido esses mecanismos. Isso pode diminuir a interoperabilidade a longo prazo.

Boa prática: Mecanismos de extensibilidade

Uma especificação DEVE fornecer mecanismos que permitam que qualquer parte crie extensões.

Extensibilidade implica variabilidade, que tem um impacto sobre a interoperabilidade. No entanto, as linguagens que não possuem mecanismos de extensibilidade podem ser estendidas de formas ad hoc que também impactam a interoperabilidade. Um critério fundamental dos mecanismos oferecidos por programadores da linguagem é que eles permitem que linguagens estendidas permaneçam em conformidade com a especificação original, aumentando a probabilidade de interoperabilidade.

Boa prática: Conformidade de extensibilidade

Extensibilidade NÃO DEVE interferir com a conformidade à especificação original.

O aplicativo precisa determinar a estratégia de extensão mais apropriada para uma especificação. Por exemplo, aplicativos projetados para operar em ambientes fechados podem permitir que programadores de especificações definam uma estratégia de versionamento que seria impraticável na escala da Web.

Boa prática: Extensões desconhecidas

Uma especificação DEVE especificar o comportamento do agente diante de extensões desconhecidas.

Duas estratégias surgiram como particularmente úteis:

  1. “Deve ignorar”: O agente ignora qualquer conteúdo que não reconheça.
  2. “Deve entender”: O agente trata marcação não reconhecida como uma condição de erro.

Uma programação poderosa é quando a linguagem permite qualquer forma de extensão, mas as distingue explicitamente na sintaxe.

Outras estratégias são solicitar ao usuário mais informações e obter automaticamente dados de links de hipertexto disponíveis. Também são possíveis estratégias mais complexas, incluindo estratégias mistas. Por exemplo, uma linguagem pode incluir mecanismos para substituir o comportamento padrão. Assim, um formato de dados pode especificar a semântica “deve ignorar”, mas também permitir extensões que substituam essa semântica à luz das necessidades do aplicativo (por exemplo, com a semântica “deve entender” para determinada extensão).

Extensibilidade não é gratuita. Fornecer ganchos para extensibilidade é um dos muitos requisitos a serem considerados nos custos da programação de linguagem. A experiência sugere que os benefícios a longo prazo de um mecanismo de extensibilidade bem concebido geralmente superam os custos.

Veja “D.3 Extensibilidade e Extensões” em [QA].

4.2.4. Composição de formatos de dados

Muitos formatos de dados modernos incluem mecanismos de composição. Por exemplo:

  • É possível inserir comentários de texto em alguns formatos de imagem, como JPEG/JFIF. Embora esses comentários sejam incorporados aos dados contidos, eles não se destinam a afetar a visualização da imagem.
  • Existem formatos recipientes, como SOAP, que esperam receber conteúdo de vários namespaces, mas que proporcionam uma relação semântica geral de envelopamento e conteúdo da mensagem.
  • É bem definida a semântica de documentos RDF combinantes contendo múltiplos vocabulários.

Em princípio, essas relações podem ser misturadas e unidas de forma arbitrária. Uma mensagem SOAP, por exemplo, pode conter uma imagem SVG, que contém um comentário RDF que se refere a um vocabulário de termos para descrever a imagem.

Note-se, no entanto, que para o XML geral não existe um modelo semântico que defina as interações dentro de documentos XML com elementos e/ou atributos de uma variedade de namespaces. Cada aplicativo deve definir como namespaces interagem e qual é o efeito que o namespace de um elemento tem sobre os ancestrais, os irmãos e os descendentes do elemento.

Ver os boletins do TAG mixedUIXMLNamespace-33 a respeito do significado de um documento composto de conteúdo em múltiplos namespaces), xmlFunctions-34 (a respeito de uma abordagem para gerenciar transformação e composabilidade) e RDFinXHTML-35 (a respeito da interpretação de RDF quando inserido em um documento XHTML).

4.3. Separação de Conteúdo, Apresentação e Interação

A Web é um ambiente heterogêneo, onde uma grande variedade de agentes fornece acesso a conteúdo para usuários com uma ampla variedade de habilidades. É uma boa prática para autores criar conteúdo que possa atingir o público mais amplo possível, incluindo usuários com computadores desktop gráficos, dispositivos portáteis e telefones celulares, usuários com deficiência que possam necessitar de sintetizadores de voz e dispositivos ainda não imaginados. Além disso, autores, em alguns casos, não conseguem prever como um agente vai exibir ou processar seu conteúdo. A experiência mostra que a separação do conteúdo, a apresentação e a interação promovem a reutilização e a independência de dispositivos de conteúdo; isso decorre do princípio de especificações ortogonais(§5.1).

Essa separação também facilita a reutilização de conteúdo de recurso autoral em vários contextos de apresentação. Por vezes, experiências funcionaestá de usuário adequadas a qualquer contexto de apresentação podem ser geradas por um processo de adaptação aplicado a uma representação, que não depende do mecanismo de acesso. Para mais informações sobre princípios de independência de dispositivo, ver [DIPRINCIPLES].

Boa prática: Separação de conteúdo, apresentação, interação

Uma especificação DEVE permitir que autores separem o conteúdo de questões tanto de apresentação como de interação.

Note-se que, quando conteúdo, apresentação e interação são separados no projeto, agentes precisam recombiná-los. Existe um espectro de recombinação, com “cliente faz tudo” numa das extremidades e “servidor faz tudo” na outra.

Há vantagens em cada abordagem. Por exemplo, quando um cliente (por exemplo, um telefone celular) comunica as capacidades do dispositivo para o servidor (por exemplo, usando CC/PP), o servidor pode adaptar o conteúdo apresentado para atender a esse cliente. O servidor pode, por exemplo, permitir downloads mais rápidos ajustando os links para que se refiram a imagens de resolução mais baixa, vídeos menores ou nenhum vídeo. Da mesma forma, se o conteúdo for autoral com várias ramificações, o servidor pode remover ramificações não utilizadas antes da apresentação. Ademais, ao adaptar o conteúdo para corresponder às características de um cliente-alvo, o servidor pode ajudar a reduzir a computação por parte do cliente. No entanto, conteúdo especializado, dessa forma, reduz a eficiência de cache.

Por outro lado, a concepção de conteúdo que possa ser recombinado no cliente também tende a tornar esse conteúdo aplicável a uma vasta gama de dispositivos. Tal projeto também melhora a eficiência de cache e oferece aos usuários mais opções de apresentação. Folhas de estilos baseadas na mídia utilizada podem ser aproveitadas para adaptar o conteúdo no lado do cliente para determinados grupos de dispositivos. Para conteúdos textuais com estrutura regular e repetitiva, o tamanho do conteúdo textual somado ao da folha de estilos é geralmente menor do que o de conteúdo totalmente recombinado; a economia é ainda maior se a folha de estilos é reutilizada por outras páginas.

Na prática, costuma-se utilizar uma combinação das duas abordagens. A decisão de projeto sobre onde colocar um aplicativo dentro deste espectro depende da capacidade do cliente, da capacidade e da carga no servidor e da largura de banda do meio que os conecta. Se o número de possíveis clientes é ilimitado, o aplicativo funcionará melhor se mais computação ficar a cargo do cliente.

Logicamente, talvez não seja a vontade atingir o público mais amplo possível. Programadores devem considerar tecnologias apropriadas, tais como criptografia e controle de acesso (§3.5.2), para se limitar o público.

Alguns formatos de dados são projetados para descrever a apresentação (incluindo Formatting Objects SVG e XSL). Formatos de dados como esses demonstram que, até agora, só se pode separar o conteúdo da apresentação (ou da interação); em algum ponto, torna-se necessário falar sobre apresentação. De acordo com o princípio de especificações ortogonais (§5.1) esses formatos de dados só devem apenas abordar questões de apresentação.

Ver os boletins do TAG sobre formattingProperties-19 (a respeito da interoperabilidade no caso de propriedades e nomes de formatação) e contentPresentation-26 (sobre a separação entre marcação semântica e de apresentação).

4.4. Hypertexto

Uma característica típica da Web é que ela permite incorporar referências em outros recursos por meio de URIs. A simplicidade de se criar links de hipertexto usando URIs absolutos (<a href="http://www.example.com/foo">) e referências URI relativas <a href=”foo”> e (<a href="foo">) é, em parte (talvez em grande parte), responsável pelo sucesso da Web hipertexto como a conhecemos hoje.

Quando uma representação de um recurso contém uma referência a outro recurso, expressa com um URI identificando esse outro recurso, isso constitui um link entre os dois recursos. Metadados adicionais também podem fazer parte do vínculo (ver [XLink10] Nota: Nota: Neste documento, o termo “vínculo” geralmente significa “relacionamento”, e não “conexão física”.

Boa prática: Identificação de links

Uma especificação deve fornecer maneiras de se identificar vínculos para outros recursos, inclusive para recursos secundários (por meio de identificadores de fragmentos).

Formatos que permitem que autores de conteúdo usem URIs em vez de identificadores locais promovem o efeito de rede: o valor desses formatos cresce conforme o tamanho da Web implantada.

Boa prática: Linkar na Web

Uma especificação DEVE permitir vinculação pela Web, não apenas vínculos internos aos documentos.

Boa prática: URIs genéricos

Uma especificação DEVE permitir que autores de conteúdo usem URIs sem restringi-los a um conjunto limitado de esquemas de URI.

O que agentes fazem com um link de hipertexto não é limitado pela arquitetura Web e pode depender do contexto do aplicativo. Usuários de links de hipertexto esperam ser capazes de navegar entre representações seguindo links.

Boa prática: Links de hipertexto

Um formato de dados DEVE incorporar links de hipertexto se o paradigma de interface esperado pelo usuário for hipertexto.

Formatos de dados que não permitem que autores de conteúdo criem links de hipertexto levam à criação de “nós terminais” na Web.

4.4.1. Referências de URI

Links são geralmente expressos usando-se referências de URI (definidas na seção 4.2 de [URI]), que podem ser combinadas com o URI base para produzir um URI utilizável. A seção 5.1 de [URI] explica diferentes maneiras de se estabelecer um URI base para um recurso e estabelece uma precedência entre eles. Por exemplo, o URI base pode ser um URI para o recurso, ou especificado em uma representação (ver os elementos base fornecidos por HTML e XML, e o cabeçalho HTTP “Content-Location”). Ver também a seção de links em XML (§4.5.2).

Agentes resolvem uma referência de URI antes de utilizar o URI resultante para interagir com outro agente. Referências de URI ajudam no gerenciamento do conteúdo, permitindo que autores de conteúdo criem uma representação localmente, ou seja, sem a preocupação sobre qual identificador global pode ser usado depois para se referir ao recurso associado.

4.5. Formatos de Dados Baseados em XML

Muitos formatos de dados são baseados em XML, isto é, estão em conformidade com as regras sintáticas definidas na especificação XML [XML10] ou [XML11].Esta seção discute questões específicas desses formatos. Qualquer pessoa em busca de orientação nesta área deve consultar as “Diretrizes para o uso de XML em protocolos IETF”, [IETFXML], que contém uma discussão aprofundada sobre que considerações que regem ou não XML devem ser utilizadas, bem como orientações específicas sobre como utilizá-las. Embora voltada a aplicativos de Internet, com especial referência a protocolos, a discussão geralmente se aplica também a cenários Web.

A discussão aqui deve ser vista como acessória ao conteúdo [IETFXML]. Ver também “Diretrizes de Acessibilidade em XML” [XAG] para ajudar a programar formatos XML que reduzam as barreiras à acessibilidade Web para pessoas com deficiência.

4.5.1. Quando usar um formato baseado em XML

XML define formatos de dados textuais que são naturalmente adequados para descrever objetos de dados hierárquicos e processados na sequência escolhida. É muito útil para formatos de dados, mas não de modo universal; é improvável que um formato de áudio ou vídeo, por exemplo, seja adequado para expressão em XML. Entre as restrições de projeto que indicariam o uso de XML estão:

  1. Exigência de uma estrutura hierárquica.
  2. Necessidade de uma ampla gama de ferramentas em uma variedade de plataformas.
  3. Necessidades de dados que consigam sobreviver aos aplicativos que atualmente os processam.
  4. Capacidade de suportar internacionalização de um modo autodescritivo que dificulte a existência de confusão sobre opções de codificação.
  5. Detecção prévia de erros de codificação sem qualquer exigência de se “contornar” esses erros.
  6. Uma grande proporção de conteúdo textual legível por seres humanos.
  7. 2 Possível composição do formato de dados com outros formatos codificados em XML.
  8. Desejo por dados facilmente legíveis por seres humanos e máquinas.
  9. Desejo por vocabulários que possam ser inventados de uma maneira distribuída e combinados com flexibilidade.

4.5.2. Links no XML

Foram inventados mecanismos sofisticados de linkagem para formatos XML. XPointer permite links para endereçar os conteúdos que não têm uma âncora explícita, nomeada. [XLink] é uma especificação adequada para representar links em aplicações de hipertexto (§4.4) em XML. XLink permite que se façam links para vários fins e que sejam expressos in-line ou em “bases de links” armazenadas externamente para todo e qualquer recurso identificado pelos links que contém.

Programadores de formatos baseados em XML podem considerar o uso de XLink e, para definir a sintaxe de identificador de fragmentos, o framework XPointer e o elemento de XPointer () Schemes.

XLink não é o único projeto de linkagem proposto para XML, nem é universalmente aceito como um bom programa. Ver também o boletim do TAG xlinkScope-23.

4.5.3. XML namespaces

O propósito de um namespace de XML (definido em [XMLNS]) é permitir a implantação de vocabulários XML (em que são definidos nomes de elementos e de atributos) em um ambiente global e reduzir o risco de colisões de nome em determinado documento quando se combinam vocabulários. Por exemplo, especificações de MathML e SVG definem o elemento set. Embora dados XML vindos de diferentes formatos, como MathML e SVG, possam ser combinados em um único documento, neste caso poderia haver ambiguidade sobre qual elemento set era o foco. Namespaces de XML reduzem o risco de colisões de nome, aproveitando os sistemas existentes para atribuição de nomes de escopo global: o sistema URI (ver também a seção sobre alocação de URI (§2.2.2)). Ao se utilizar namespaces de XML, cada nome local em um vocabulário XML é emparelhado a um URI (o chamado namespace de URI), para distinguir o nome local dos nomes locais em outros vocabulários.

O uso de URIs confere benefícios adicionais. Primeiro, cada par URI/nome local pode ser mapeado para outro URI, fundamentando os termos do vocabulário na Web. Estes termos podem ser recursos importantes, e, portanto, é interessante ser capaz de se associar URIs a eles.

[RDFXML] usa concatenação simples do namespace de URI e o nome local para criar um URI para o termo identificado. Outros mapeamentos devem ser mais adequados para namespaces hierárquicos; ver o boletim relacionado do TAG abstractComponentRefs-37.

Programadores de formatos de dados baseados em XML que declaram namespaces possibilitam, assim, reutilizar os formatos de dados e combiná-los de novas maneiras ainda não imaginadas. Não declarar namespaces torna tal reutilização maestá difícil, até mesmo inviável em alguns casos.

Boa prática: Adoção de namespaces

Uma especificação que estabelece um vocabulário XML DEVE colocar todos os nomes de elementos e nomes de atributos globais em um namespace.

Atributos são sempre definidos pelo elemento em que aparecem. Um atributo “global”, isto é, aquele que pode aparecer de forma significativa em elementos de vários tipos, incluindo elementos em outros namespaces, deve ser explicitamente colocado em um namespace. Atributos locais, aqueles associados a apenas um tipo de elemento, não precisam ser incluídos em um namespace, já que seu significado será sempre claro pelo contexto fornecido por esse elemento.

O atributo type do namespace do W3C XML Schema Instance "http://www.w3.org/2001/XMLSchema-instance" ([XMLSCHEMA], seção 4.3.2) é um exemplo de atributo global. Pode ser usado por autores de qualquer vocabulário para fazer uma afirmação em dados de instância sobre o tipo do elemento em que aparece. Como é um atributo global, deve ser sempre qualificado. O atributo frame tabela HTML é um exemplo de atributo local. Não há qualquer valor em colocar esse atributo em um namespace, uma vez que é improvável que o atributo seja útil em um elemento diferente de uma tabela HTML.

Aplicativos que dependem de processamento DTD devem impor restrições adicionais sobre o uso de namespaces. DTDs realizam validação com base na forma lexical dos nomes de elementos e atributos do documento. Isso torna prefixos sintaticamente significativos de maneiras não previstas por [XMLNS].

4.5.4. Documentos namespace

História

Nadia recebe dados de representação de “weather.exemplo.com” em um formato de dados desconhecido. Ela sabe o suficiente sobre XML para reconhecer a que namespace de XML pertencem os elementos. Já que o namespace é identificado pela URI “http://weather.exemplo.com/2003/format”, ela pede a seu navegador que obtenha uma representação do recurso identificado. Ela recebe alguns dados úteis que lhe permitem obter mais informações sobre o formato de dados. O navegador de Nadia também é capaz de executar algumas operações automaticamente (ou seja, sem necessidade de supervisão por um ser humano), dando-lhe dados que foram otimizados para agentes de software. Por exemplo, seu navegador pode, em nome de Nadia, baixar agentes adicionais para processar e renderizar o formato.

Outra vantagem de se usar URIs para se construir namespaces de XML é que o URI de namespace pode ser usado para identificar um recurso de informação que contém informações úteis, usável por máquina e/ou ser humano, sobre os termos do namespace. TEsse tipo de recurso de informação é chamado de documento de namespace. Quando o proprietário de um URI de namespace fornece um documento de namespace, ele é dominante naquele namespace.

Existem muitos motivos para se fornecer um documento de namespace. Uma pessoa pode querer:

  • compreender o propósito do namespace,
  • aprender a usar o vocabulário de marcação no namespace,
  • descobrir quem tem o controle dele e das regras associadas,
  • solicitar autoridade para acessar esquemas ou materiais colaterais a respeito, ou
  • relatar um bug ou situação que possa ser considerada um erro em algum material colateral.

Um processador pode querer:

  • obter um esquema, para validação,
  • obter uma folha de estilos, para apresentação, ou
  • obter ontologias, para fazer inferências.

Em geral, não existe uma boa prática estabelecida para se criar representações de um documento de namespace; as expectativas do aplicativo influenciam o formato ou formatos de dados que são usados. As expectativas do aplicativo também influenciarão se a informação relevante aparece diretamente em uma representação ou se é referida nela.

Boa prática: Documentos de Namespace

O proprietário de um nome de namespace de XML DEVE disponibilizar material destinado a pessoas lerem e materiais otimizados para agentes de software, a fim de satisfazer às necessidades de quem vai usar o vocabulário namespace.

Por exemplo, alguns formatos de dados para documentos de namespace são: [OWL10], [RDDL], [XMLSCHEMA], e [XHTML11]. Cada um desses formatos atende a diferentes requisitos descritos acima para satisfazer às necessidades de um agente que quer mais informações sobre o namespace. Observe, no entanto, questões relacionadas a fragmentos identificadores ou negociação de conteúdo (§3.2.2) caso seja usada negociação de conteúdo.

Ver os boletins do TAG namespaceDocument-8 (a respeito das características desejadas para documentos de namespace) e abstractComponentRefs-37 (a respeito do uso de identificadores de fragmentos com nomes de namespace para identificar componentes abstratos).

4.5.5. QNames em XML

A seção 3 de “Namespaces em XML” [XMLNS] fornece uma construção sintática conhecida como QName para a expressão compacta de nomes qualificados em documentos XML. Um nome qualificado é um par constituído por um URI, que nomeia um namespace, e um nome local colocado dentro desse namespace. “Namespaces em XML” prevê o uso de QNames como nomes de elementos e atributos XML.

Outras especificações, desde [XSLT10], têm adotado o uso QNames em contextos diferentes que não sejam nomes de elementos e atributos, por exemplo em valores de atributos e em conteúdos de elemento. No entanto, processadores normaestá de XML não conseguem reconhecer com segurança QNames como quando são utilizados em valores de atributo e no conteúdo do elemento;por exemplo, a sintaxe de QNames sobrepõe-se à de URIs. A experiência também revelou outras limitações de QNames, como a perda de ligações de namespace após a canonização do XML.

restrição: QNames indistinguíveestá de URIs

Não permita QNames e URIs em valores de atributos ou conteúdos de elementos quando são indistinguíveis.

Para mais informações, ver o texto do TAG "Usando Qnames como identificadores em conteúdo".

Como QNames são compactos, alguns programadores de especificação adotaram a mesma sintaxe como meio de identificar recursos. Apesar de conveniente enquanto notação abreviada, esse uso tem um custo. Não existe uma única maneira aceita para converter um QName em um URI, ou vice-versa. Embora QNames sejam convenientes, eles não substituem o URI como sistema de identificação da Web. O uso de QNames para identificar recursos da Web sem fornecer um mapeamento de URIs é inconsistente com a arquitetura da Web.

Boa Prática: Mapeamento de Qname

Uma especificação em que QNames servem como identificadores de recursos DEVE fornecer um mapeamento de URIs.

Veja namespaces XML (§4.5.3) para exemplos de algumas estratégias de mapeamento.

Ver também os boletins do TAG rdfmsQnameUriMapping-6 (a respeito do mapeamento de QNames para URIs), qnameAsId-18 (a respeito do uso de QNames como identificadores em conteúdo XML), e abstractComponentRefs-37 (sobre o uso de identificadores de fragmento com nomes de namespace para identificar componentes abstratos).

4.5.6. Semântica de ID XML

Considere o seguinte fragmento de XML: <section name="foo">. Será que o elemento section tem aquilo a que a Recomendação XML se refere como o ID foo (i.e., “foo” não deve aparecer no documento XML englobante maestá de uma vez)? Não se pode responder essa pergunta apenas pela análise do elemento e de seus atributos. Em XML, a qualidade de “ser um ID” está associada a um atributo, não a seu nome. Encontrar os IDs em um documento requer processamento adicional.

  1. 1 Processar o documento com um processador que reconhece declarações de lista de atributos DTD (no subconjunto externo ou interno) pode revelar uma declaração que identifica o atributo name como um ID. Nota: Nota: Este processamento não é necessariamente parte da validação. Um processador não validante, que trabalhe com DTD, pode reconhecer IDs.
  2. Processar o documento com um esquema XML do W3C pode revelar uma declaração de elemento que identifica o atributo name como um XML Schema ID do W3C.
  3. 1 Na prática, processar o documento com outra linguagem de esquema, como [RELAXNG], 1 pode revelar os atributos declarados como de ID no sentido do XML Schema. Muitas especificações modernas começam a processar XML no nível [INFOSET] e não especificam normativamente como um Infoset é construído. Para essas especificações, qualquer processo que estabeleça o tipo de ID no Infoset (e Post Schema Validation Infoset (PSVI) definida em [XMLSCHEMA]) pode facilmente identificar os atributos do tipo de ID.
  4. Na prática, aplicativos podem ter meios independentes (tais como aqueles definidos na especificação XPointer, [XPTRFR] section 3.2) de localizar identificadores dentro de um documento.

Para complicar ainda mais, DTDs estabelecem o tipo de ID no Infoset enquanto o XML Schema do W3C produz um PSVI, mas não modifica o Infoset original. Isso deixa aberta a possibilidade de um processador só conseguir olhar no Infoset e, consequentemente, não ser suficiente para reconhecer IDS atribuídos por esquema.

Ver o boletim do TAG xmlIDSemantics-32 para mais informações e [XML-ID] para uma solução em desenvolvimento.

4.5.7. Tipos de mídia para XML

RFC 3023 define os tipos de mídia de Internet “application/xml” e “text/xml” e descreve uma convenção pela qual formatos de dados baseados em XML devem usar os tipos de mídia de Internet com um sufixo “+xml”, por exemplo “image/svg+xml”.

Existem dois problemas associados aos tipos de mídia “text”: primeiro, para dados identificados como “text/*”, os intermediários da Web estão autorizados a “transcodificar”, ou seja, converter uma codificação de caracteres em outra. Transcodificação pode tornar falsa a autodescrição ou pode fazer que o documento seja mal formado.

Boa prática: XML e "text/*"

Em geral, um provedor de representação NÃO DEVE atribuir tipos de mídia de Internet começando com “text/” para representações XML.

Em segundo lugar, é necessário que representações cujos tipos de mídia de Internet começam com “text/”, a não ser que o parâmetro charset seja especificado, sejam considerados como codificadas em US-ASCII. Como a sintaxe do XML é projetada para tornar os documentos autodescritivos, é uma boa prática omitir o parâmetro charset, e, como o XML muito frequentemente não é codificado em US-ASCII, o uso do tipo de mídia de Internet “text/” efetivamente impede essa boa prática.

Boa prática: XML e codificações de caracteres

Em geral, um provedor de representação NÃO DEVE especificar a codificação de caracteres para dados XML em cabeçalhos de protocolo, pois os dados são autodescritivos.

4.5.8. Identificadores de fragmentos em XML

A seção sobre tipos de mídia e semântica de identificadores de fragmentos (§3.2.1) discute a interpretação de identificadores de fragmentos. Programadores de uma especificação de formato de dados baseado em XML devem definir a semântica dos identificadores de fragmentos nesse formato. O Framework XPointer [XPTRFR] fornece um ponto de partida interoperável.

Quando o tipo de mídia atribuído a dados de representação é “application/xml”, não há semântica definida para identificadores de fragmento, e os autores não devem fazer uso de identificadores de fragmento nesses dados. O mesmo é válido se o tipo de mídia atribuído tem o sufixo “+xml” (definido em “Tipos de mídia XML” [RFC3023]), e a especificação do formato de dados não especifica a semântica de identificador de fragmentos. Em suma, apenas saber que o conteúdo é XML não fornece informações sobre a semântica de identificador de fragmentos.

Muitas pessoas acham que o identificador de fragmentos #abc, quando se refere a dados XML, identifica o elemento no documento com o ID “abc”. No entanto, não há qualquer suporte normativo para esta hipótese. Espera-se uma revisão do RFC 3023 para resolver tal questão.

Ver o boletim do TAG fragmentInXML-28.

4.6. Direções Futuras para Formatos de Dados

Formatos de dados permitem a criação de novos aplicativos para fazer uso da infraestrutura do espaço de informações. A Web Semântica é um desses aplicativos, construída sobre RDF [RDFXML]. Este documento não aborda a Web Semântica em detalhes; o TAG espera que futuros volumes deste documento a discutam. Veja o boletim relacionado do TAG httpRange-14.

5. Princípios Geraestá da Arquitetura

Muitos princípios geraestá da atquitetura aplicam-se às três bases da arquitetura Web.

5.1. Especificações Ortogonais

Identificação, interação e representação são conceitos ortogonais, o que significa que as tecnologias utilizadas para identificação, interação e representação podem evoluir de forma independente. Por exemplo:

Quando duas especificações são ortogonais, pode-se alterar uma sem se precisar alterar a outra, mesmo que uma seja dependente da outra. Por exemplo, embora a especificação HTTP dependa da especificação de URI, as duas podem evoluir de forma independente. Este ortogonalidade aumenta a flexibilidade e a robustez da Web. Por exemplo, é possível referir-se, por meio de um URI, a uma imagem sem saber coisa alguma sobre o formato escolhido para representar a imagem. Isso tem facilitado a introdução de formatos de imagem como PNG e SVG sem desorganizar as referências existentes para recursos de imagem.

Princípio: Ortogolalidade

Abstrações ortogonais beneficiam-se de especificações ortogonais.

A experiência mostra que surgem problemas quando ocorrem conceitos ortogonais em uma única especificação. Considere, por exemplo, a especificação HTML que inclui a especificação ortogonal x-www-form-urlencoded. Desenvolvedores de software (por exemplo, de aplicações [CGI] podem ter mais facilidade para encontrar a especificação se tiver sido publicada separadamente e, então, citada em especificações de HTTP, URI e HTML.

Também surgem problemas quando especificações tentam modificar abstrações ortogonaestá descritas em outro lugar. Uma versão histórica da especificação HTML adicionou um valor "Refresh" para o atributo http-equiv do elemento meta. Ele foi definido como equivalente ao cabeçalho HTTP de mesmo nome. Os autores da especificação HTTP decidiram, no fim, não fornecer esse cabeçalho, e isso deixou as duas especificações em conflito uma com a outra. O Grupo de Trabalho HTML do W3C acabou removendo o valor"Refresh".

Uma especificação deve indicar claramente que características sobrepõem-se àquelas controladas por outras especificações.

5.2. Extensibilidade

As informações na Web e as tecnologias usadas para representar tais informações mudam ao longo do tempo. Extensibilidade é a propriedade de uma tecnologia que promove evolução sem sacrificar interoperabilidade. Alguns exemplos de tecnologias de sucesso concebidas para permitir mudanças ao mesmo tempo em que minimizam a desorganização incluem:

Um exemplo de mecanismo de extensão que não funcionou foram as extensões obrigatórias de HTTP [HTTPEXT]. A comunidade buscava mecanismos para estender o HTTP, mas, aparentemente, os custos da proposta de extensões obrigatórias (principalmente em termos de complexidade) superavam os benefícios, e isso prejudicou a adoção.

A seguir, discutimos a propriedade “extensibilidade”, exibida por URIs, alguns formatos de dados e alguns protocolos (pela incorporação de novas mensagens).

Subconjunto de linguagem: uma linguagem é um subconjunto (ou “perfil”) de uma segunda linguagem se qualquer documento na primeira linguagem for também válido e tiver a mesma interpretação na segunda.

Linguagem estendida: Se uma linguagem é subconjunto de outra, esta outra é chamada de linguagem estendida; a diferença entre as linguagens é chamada de extensão. Claramente, estender-se uma linguagem é melhor para a interoperabilidade do que se criar uma linguagem incompatível.

Idealmente, muitos casos de uma linguagem estendida podem ser tranquilamente processados como se estivessem no subconjunto de linguagem. Linguagens que conseguem evoluir dessa forma, permitindo que aplicativos forneçam novas informações quando necessário e ainda interoperem com aplicativos que só entendem um subconjunto da linguagem corrente, são chamadas de “extensíveis”. Programadores de linguagem podem facilitar a extensibilidade definindo o comportamento padrão de extensões desconhecidas – por exemplo, que sejam ignoradas (de alguma forma definida), ou sejam consideradas como erros.

Por exemplo, desde cedo na Web, agentes de HTML seguiram a convenção de ignorar tags desconhecidas. Essa opção abriu espaço para inovações (ou seja, elementos não padrão) e incentivou a implantação do HTML. No entanto, também surgiram problemas de interoperabilidade. Neste tipo de ambiente, existe uma tensão inevitável entre interoperabilidade no curto prazo e o desejo por extensibilidade. A experiência mostra que projetos que alcançam o equilíbrio entre permissões de mudanças e a interoperabilidade preservante são mais propensos a prosperar e menos propensos a desorganizar a comunidade Web. Especificações Ortogonais (§5.1) ajudam a reduzir o risco de desorganização.

Para maestá discussões, ver a seção sobre versionamento e extensibilidade (§4.2). Ver também os boletins do TAG xmlProfiles-29 and Dialetos HTML.

5.3. Gerenciamento de Erros

Erros ocorrem em sistemas de informação em rede. Uma condição de erro pode ser bem caracterizada (por exemplo, erros de formação em XML ou erros no cliente 4xx em HTTP) ou surgir de forma imprevisível. Correção de erro significa que um agente repara um problema para que, dentro do sistema, pareça que o erro nunca ocorreu. Um exemplo de correção de erro envolve retransmissão de dados em resposta a uma falha de rede temporária. Recuperação de erro significa que um agente não repara uma condição de erro, mas continua o processamento cuidando do fato de ter ocorrido o erro.

Agentes frequentemente corrigem corrigem erros sem o conhecimento do usuário, poupando-lhe de detalhes de complexas comunicações de rede. Por outro lado, é importante que agentes recuperem o erro de uma maneira que seja evidente para os usuários, visto que os agentes atuam em seu nome.

Princípio: Recuperação de erro

Agentes que se recuperam de erro fazendo uma escolha sem o consentimento do usuário não estão agindo em nome do usuário.

Um agente não é obrigado a interromper o usuário (por exemplo, fazendo surgir uma caixa de confirmação) para obter seu consentimento. O usuário pode indicar o consentimento por meio de opções pré-selecionadas de configuração, modos ou alternações de interface de usuário selecionáveis, com comunicação adequada ao usuário quando o agente detectar um erro. Desenvolvedores de agentes não devem ignorar questões de usabilidade na concepção do comportamento de recuperação de erros.

Para promover a interoperabilidade, programadores de especificação devem identificar condições de erro previsíveis. A experiência levou às seguintes observações sobre abordagens de tratamento de erros.

Ver o boletim do TAG contentTypeOverride-24, que diz respeito à fonte de metadados oficial.

5.4. Interoperabilidade baseada em Protocolos

A Web segue a tradição da Internet de que suas interfaces importantes são definidas em termos de protocolos, especificando-se a sintaxe, a semântica e consequentes restrições das mensagens trocadas. Protocolos projetados para serem elásticos em face de ambientes muito diferentes ajudaram a expandir a Web e facilitaram a comunicação entre vários limites de confiança. Interfaces tradicionaestá de programação de aplicativos (APIs) nem sempre levam em conta essas limitações, nem devem ser forçados a tanto. Um efeito do projeto baseado em protocolos é que a tecnologia compartilhada entre agentes frequentemente dura mais tempo do que os próprios agentes.

É comum programadores que trabalham com Web escreverem códigos que geram e corrigem essas mensagens diretamente. É menos comum, mas não incomum, que usuários finais tenham exposição direta a essas mensagens. Muitas vezes é desejável fornecer aos usuários acesso a detalhes do formato e dos protocolos: isso lhes permite “ver a fonte”, em que podem ganhar conhecimento sobre o funcionamento do sistema subjacente.

6. Glossário

Negociação de conteúdo
A prática de oferecer múltiplas representações disponíveis pelo mesmo URI. A representação apresentada depende de negociação entre o agente requerente e o agente que oferece as representações.
Desreferenciar uma URI
Acessar uma representação do recurso identificado pelo URI.
Correção de erro
Um agente repara um erro para que, dentro do sistema, fosse como se o erro nunca tivesse ocorrido.
Recuperação de erro
Um agente invoca comportamento excepcional porque não se corrige o erro.
Linguagem estendida
Se uma linguagem é um subgrupo de outra, esta outra é chamada de linguagem estendida.
Identificador de fragmento
A parte de um URI que permite a identificação de um recurso secundário..
Recurso de Informação
Um recurso que tem a propriedade de que todas suas características essenciais podem ser transmitidas em uma mensagem.
Link
Uma relação entre dois recursos quando um recurso (representação) refere-se a outro por meio de um URI.
Mensagem
Uma unidade de comunicação entre agentes.
Documento de namespace
Um recurso de informação identificado por um URI de Namespace XML que contém informações úteis, acessíveis por máquina e/ou ser humano, sobre termos de determinado namespace XML. É útil, embora não obrigatório, que o URI empregado como nome de namespace identifique um documento de namespace.
Representação
Dados que codificam informações sobre o estado do recurso.
Recurso
Qualquer coisa que possa ser identificada por um URI.
Interação segura
Interação com um recurso em que o agente não assume qualquer obrigação além da interação.
Recurso Secundário
Um recurso relacionado a outro por meio do recurso primário, com informações de identificação adicionais (o identificador de fragmentos).
Subgrupo de linguagem
Uma linguagem é subgrupo de uma segunda linguagem se qualquer documento na primeira linguagem também é valido na segunda e tem a mesma interpretação que na segunda.
URI
Acrônimo para Uniform Resource Identifier (Identificador Uniforme de Recursos).
Aliases de URI
Dois ou maestá diferentes URIs que identificam o mesmo recurso.
Colisão de URI
O uso do mesmo URI para se referir a maestá de um recurso no contexto dos protocolos e formatos da Web.
Titularidade de URI
Uma relação entre um URI e uma entidade social, como uma pessoa, uma organização ou uma especificação.
Persistência de URI
A expectativa social de que, depois que um URI identifica determinado recurso, ele deve continuar indefinidamente a se referir àquele recurso.
Referência de URI
Um atalho operacional para um URI.
Uniform Resource Identifier (URI)
Um identificador global no contexto da World Wide Web.
Interação insegura
Interação com um recurso que não seja seguro.
Agente de usuário
Um tipo de agente da Web; um software específico agindo em nome de uma pessoa.
WWW
Acrônimo para World Wide Web.
Web
Abreviatura de World Wide Web.
Agente Web
Uma pessoa ou software específico atuando no espaço de informações em nome de uma pessoa, entidade ou processo.
World Wide Web
Um espaço de informações em que itens de interesse são identificados por Identificadores Uniformes de Recurso.
Formato baseado em XML
Um que se adeque às regras sintáticas definidas na especificação XML.

7. Referências

CGI
Common Gateway Interface/1.1 Specification. Disponível em http://hoohoo.ncsa.uiuc.edu/cgi/interface.html.
CHIPS
Common HTTP Implementation Problems, O. Théreaux, Janeiro 2003. This W3C Team Submission está disponível em http://www.w3.org/TR/chips/.
CUAP
Common User Agent Problems, K. Dubost, Janeiro 2003. This W3C Team Submission está disponível em http://www.w3.org/TR/cuap.
Cool
Cool URestá don't change T. Berners-Lee, W3C, 1998 Disponível em http://www.w3.org/Provider/Style/URI. Observem que o título é, de certa forma, enganoso. Não são os URIs que mudam, mas o que eles identificam.
Eng90
Knowledge-Domain Interoperability and an Open Hyperdocument System, D. C. Engelbart, Junho 1990.
HTTPEXT
Mandatory Extensions in HTTP, H. Frystyk Nielsen, P. Leach, S. Lawrence, 20 Janeiro 1998. Este rascunho está disponível em http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-mandatory.
IANASchemes
IANA's online registry of URI Schemes está disponível em http://www.iana.org/assignments/uri-schemes.
IETFXML
IETF Guidelines para a Use of XML in IETF Protocols, S. Hollenbeck, M. Rose, L. Masinter, eds., 2 Novembro 2002. This Internet Draft está disponível em http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt. Se não estiver disponível, vá a lista de e-mail ietf-xml-use.
INFOSET
XML Information Set (Second Edition), R. Tobin, J. Cowan, Editors,Recomendação do W3C, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-infoset-20040204. última versão Disponível em http://www.w3.org/TR/xml-infoset.
IRI
IETF Internationalized Resource Identifiers (IRIs), M. Dürst, M. Suignard, Eds., Novembro 2004. Em um anúncio feito em 8 Dezembro de 2004, o IESG aprovou draft-duerst-iri-11 como Padrão Proposto do IETF. Referências à especificação IRI no Volume Um de Arquitetura da Web são a esse Padrão Proposto. Como o IETF lançou inúmeros Pedidos de Comentários [Request For Comments – (RFC)] para a especificação, esta Recomendação W3C pode ser atualizada para se referir ao RFC. Ver também últimas informações sobre a especificação IRI..
MEDIATYPEREG
IANA's O Registro on-line de Tipos de Mídia de Internet está disponível em http://www.iana.org/assignments/media-types/index.html.
OWL10
OWL Web Ontology Language Reference, M. Dean, G. Schreiber, organizadores, Recomendação W3C, 10 de fevereiro de 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/. última versão Disponível em http://www.w3.org/TR/owl-ref/.
P3P10
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, M. Marchiori, Editor,Recomendação do W3C, 16 Abril 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/. última versão Disponível em http://www.w3.org/TR/P3P/.
RDDL
Resource Directory Description Language (RDDL), J. Borden, T. Bray, eds., 1 Junho 2003. Este documento está disponível em http://www.tbray.org/tag/rddl/rddl3.html.
RDFXML
RDF/XML Syntax Specification (Revised), D. Beckett, Editor,Recomendação do W3C, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. Última versão Disponível em http://www.w3.org/TR/rdf-syntax-grammar.
RELAXNG
The RELAX NG schema language project.
REST
Representational State Transfer (REST), Capítulo 5 de “Architectural Styles and the Design of Network-based Software Architectures”, Tese de Doutorado de R. T. Fielding, 2000. Programadores de especificações de protocolo, em especial, devem investir tempo na compreensão do modelo REST e da relevância de seus princípios em determinado projeto. Esses princípios incluem apatridia, clara atribuição de papéis às partes, espaço de endereçamento uniforme e um conjunto limitado e uniforme de verbos. Disponível em: http://www.ics.uci.edu/~fielding/pubs/dissertação/rest_arch_style.htm.
RFC2045
IETF RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, N. Freed, N. Borenstein, Novembro 1996. Disponível em http://www.ietf.org/rfc/rfc2045.txt.
RFC2046
IETF RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, N. Freed, N. Borenstein, Novembro 1996. Disponível em http://www.ietf.org/rfc/rfc2046.txt.
RFC2119
IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997. Disponível em http://www.ietf.org/rfc/rfc2119.txt.
RFC2141
IETF RFC 2141: URN Syntax, R. Moats, Maio 1997. Disponível em http://www.ietf.org/rfc/rfc2141.txt.
RFC2326
IETF RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne, A. Rao, R. Lanphier, Abril 1998. Disponível em: http://www.ietf.org/rfc/rfc2326.txt.
RFC2397
IETF RFC 2397: The “data” URL scheme, L. Masinter, August 1998. Disponível em: http://www.ietf.org/rfc/rfc2397.txt.
RFC2616
IETF RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Junho 1999. Disponível em http://www.ietf.org/rfc/rfc2616.txt.
RFC2717
IETF Registration Procedures for URL Scheme Names, R. Petke, I. King, Novembro 1999. Disponível em http://www.ietf.org/rfc/rfc2717.txt.
RFC2718
IETF RFC 2718: Guidelines for new URL Schemes, L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, Novembro 1999. Disponível em: http://www.ietf.org/rfc/rfc2718.txt.
RFC2818
IETF RFC 2818: HTTP Over TLS, E. Rescorla, Maio 2000. Disponível em: http://www.ietf.org/rfc/rfc2818.txt.
RFC3023
IETF RFC 3023: XML Media Types, M. Murata, S. St. Laurent, D. Kohn, Janeiro 2001. Disponível em: http://www.ietf.org/rfc/rfc3023.txt
RFC3236
IETF RFC 3236: The 'application/xhtml+xml' Media Type, M. Baker, P. Stark, Janeiro 2002. Disponível em: http://www.ietf.org/rfc/rfc3236.txt
RFC3261
IETF RFC 3261: SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo, et. al., Junho 2002. Disponível em: http://www.ietf.org/rfc/rfc3261.txt
RFC3920
IETF RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core, P. Saint-Andre, Ed., Outubro 2004. Disponível em: http://www.ietf.org/rfc/rfc3920.txt
RFC977
IETF RFC 977: Network News Transfer Protocol, B. Kantor, P. Lapsley, February 1986. Disponível em http://www.ietf.org/rfc/rfc977.txt.
SOAP12
SOAP Version 1.2 Part 1: Messaging Framework, J. Moreau, N. Mendelsohn, H. Frystyk Nielsen, et. al., Editors,Recomendação do W3C, 24 Junho 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. última versão available at http://www.w3.org/TR/soap12-part1/.
SVG11
Scalable Vector Graphics (SVG) 1.1 Specification, 藤沢 淳, J. Ferraiolo, D. Jackson, Editors,Recomendação do W3C, 14 Janeiro 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/. última versão Disponível em http://www.w3.org/TR/SVG11/.
UNICODE
The Unicode Consortium, The Unicode Standard, Version 4, ISBN 0-321-18578-1, atualizado de tempos em tempos pela publicação de novas versões. Veja http://www.unicode.org/unicode/standard/versions para a latest Unicode version Ver http://www.unicode.org/unicode/standard/versions
URI
IETF Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, Eds., Setembro 2004. Em 18 Outubro 2004, o IESG aprovou draft-fielding-uri-rfc2396bis-07 como padrão do IETF. Referências á especificação URI no volume um da Architecture of the World Wide Web são padrão completo. Veja também latest information about the URI specification.
UniqueDNS
IAB Technical Comment on the Unique DNS Root, B. Carpenter, 27 Setembro 1999. Disponível em http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm.
VOICEXML2
Voice Extensible Markup Language (VoiceXML) Version 2.0, B. Porter, A. Hunt, K. Rehor, et. al., Editors,Recomendação do W3C, 16 March 2004, http://www.w3.org/TR/2004/REC-voicexml20-20040316/. última versão Disponível em http://www.w3.org/TR/voicexml20.
XHTML11
XHTML™ 1.1 - Module-based XHTML, S. McCarron, M. Altheim, Editors,Recomendação do W3C, 31 Maio 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531. última versão Disponível em http://www.w3.org/TR/xhtml11/.
XLink10
XML Linking Language (XLink) Version 1.0, E. Maler, S. DeRose, D. Orchard, Editors,Recomendação do W3C, 27 Junho 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/. última versão Disponível em http://www.w3.org/TR/xlink/.
XML-ID
xml:id Version 1.0, D. Veillard, J. Marsh, Editors, W3C Rascunho(trabalho em andamento), 07 Abril 2004, http://www.w3.org/TR/2004/WD-xml-id-20040407. última versão Disponível em http://www.w3.org/TR/xml-id/.
XML10
Extensible Markup Language (XML) 1.0 (Third Edition), F. Yergeau, J. Paoli, C. M. Sperberg-McQueen, et. al., Editors,Recomendação do W3C, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204. última versão Disponível em http://www.w3.org/TR/REC-xml.
XML11
Extensible Markup Language (XML) 1.1, J. Paoli, C. M. Sperberg-McQueen, J. Cowan, et. al., Editors,Recomendação do W3C, 04 February 2004, http://www.w3.org/TR/2004/REC-xml11-20040204/. última versão Disponível em http://www.w3.org/TR/xml11/.
XMLNS
Namespaces in XML 1.1, R. Tobin, D. Hollander, A. Layman, et. al., Editors,Recomendação do W3C, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-names11-20040204. última versão Disponível em http://www.w3.org/TR/xml-names11/.
XMLSCHEMA
XML Schema Part 1: Structures, D. Beech, M. Maloney, H. S. Thompson, et. al., Editors,Recomendação do W3C, 02 Maio 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. última versão Disponível em http://www.w3.org/TR/xmlschema-1/.
XPTRFR
XPointer Framework, E. Maler, N. Walsh, P. Grosso, et. al., Editors,Recomendação do W3C, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/. última versão disponível em http://www.w3.org/TR/xptr-framework/.
XSLT10
XSL Transformations (XSLT) Version 1.0, J. Clark, Editor,Recomendação do W3C, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116. última versão Disponível em http://www.w3.org/TR/xslt.

7.1. Architectural Specifications

ATAG10
Authoring Tool Accessibility Guidelines 1.0, C. McCathieNevile, I. Jacobs, J. Treviranus, et. al., Editors, W3C Recommendation, 03 February 2000, http://www.w3.org/TR/2000/REC-ATAG10-20000203. última versão Disponível em http://www.w3.org/TR/ATAG10.
CHARMOD
Character Model para a World Wide Web 1.0: Fundamentals, R. Ishida, M. J. Dürst, M. Wolf, et. al., Editors, W3C Working Draft (trabalho em andamento), 25 February 2004, http://www.w3.org/TR/2004/WD-charmod-20040225/. última versão Disponível em http://www.w3.org/TR/charmod/.
DIPRINCIPLES
Device Independence Principles, R. Gimson, Editor, W3C Note, 01 Setembro 2003, http://www.w3.org/TR/2003/NOTE-di-princ-20030901/. última versão Disponível em http://www.w3.org/TR/di-princ/.
EXTLANG
Web Architecture: Extensible Languages, T. Berners-Lee, D. Connolly, 10 February 1998. This W3C Note está disponível em http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210.
Fielding
Principled Design of the Modern Web Architecture,R.T. Fielding and R.N. Taylor, UC Irvine. In Proceedings of the 2000 International Conference on Software Engineering (ICSE 2000), Limerick, Ireland, Junho 2000, pp. 407-416. Este documento está disponível em http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf.
QA
QA Framework: Specification Guidelines, D. Hazaël-Massieux, L. Rosenthal, L. Henderson, et. al., Editors, W3C Working Draft (trabalho em andamento), 30 August 2004, http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/. última versão available at http://www.w3.org/TR/qaframe-spec/.
RFC1958
IETF RFC 1958: Architectural Principles of the Internet, B. Carpenter, Junho 1996. Disponível em http://www.ietf.org/rfc/rfc1958.txt.
SPECVAR
Variability in Specifications, L. Rosenthal, D. Hazaël-Massieux, Editors, W3C Rascunho(trabalho em andamento), 30 August 2004, http://www.w3.org/TR/2004/WD-spec-variability-20040830/. última versão Disponível em http://www.w3.org/TR/spec-variability/.
UAAG10
User Agent Accessibility Guidelines 1.0, J. Gunderson, I. Jacobs, E. Hansen, Editors,Recomendação do W3C, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/. última versão Disponível em http://www.w3.org/TR/UAAG10/.
WCAG20
Web Content Accessibility Guidelines 2.0, W. Chisholm, J. White, B. Caldwell, et. al., Editors, W3C Rascunho(work in progress), 30 July 2004, http://www.w3.org/TR/2004/WD-WCAG20-20040730/. última versão Disponível em http://www.w3.org/TR/WCAG20/.
WSA
Web Services Architecture, D. Booth, F. McCabe, E. Newcomer, et. al., Editors, W3C Note, 11 February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. última versão Disponível em http://www.w3.org/TR/ws-arch/.
XAG
XML Accessibility Guidelines, S. B. Palmer, C. McCathieNevile, D. Dardailler, Editors, W3C Rascunho(trabalho em andamento), 03 Outubro 2002, http://www.w3.org/TR/2002/WD-xag-20021003. última versão Disponível em http://www.w3.org/TR/xag.

8. Agredecimentos

Este documento é de autoria do Grupo Técnico de Arquitetura W3C, que incluiu os seguintes participantes: Tim Berners-Lee (co-Presidente, W3C), Tim Bray (Antarctica Systems), Dan Connolly (W3C), Paul Cotton (Microsoft Corporation), Roy Fielding (Day Software), Mario Jeckle (Daimler Chrysler), Chris Lilley (W3C), Noah Mendelsohn (IBM), David Orchard (BEA Systems), Norman Walsh (Sun Microsystems) e Stuart Williams (co-Presidente, Hewlett-Packard).

O TAG agradece pelas muitas contribuições à lista pública do TAG , www-tag@w3.org, que ajudaram a melhorar este documento.

Além disso, temos de agradecer pelas contribuições de David Booth, Erik Bruchez, Kendall Clark, Karl Dubost, Bob DuCharme, Martin Duerst, Olivier Fehr, Al Gilman, Tim Goodwin, Elliotte Rusty Harold, Tony Hammond, Sandro Hawke, Ryan Hayes, Dominique Hazaël-Massieux, Masayasu Ishikawa, David M. Karr, Graham Klyne, Jacek Kopecky, Ken Laskey, Susan Lesch, Håkon Wium Lie, Frank Manola, Mark Nottingham, Bijan Parsia, Peter F. Patel-Schneider, David Pawson, Michael Sperberg-McQueen, Patrick Stickler e Yuxiao Zhao.