Ceci est une traduction du résumé de la recommandation "Architecture of the World Wide Web, First Edition" du W3C, édition du 15 décembre 2004
Cependant, il ne s'agit pas de la version officielle en français. Seul le document original en anglais a valeur de référence. Il est disponible à l'adresse http://www.w3.org/TR/webarch/summary.html.
Des erreurs ont pu survenir malgré le soin apporté à ce travail.
Finalement, les liens menant à d'autres documents du W3C déjà traduits sont discrètement doublés vers leur traduction, de cette manière :
ex. un lien [vf.] vers un document du W3C.
<http://www.opikanoba.org/tr/w3c/webarch/summary.html>fl at opikanoba.org)Les traductions en français d'autres documents du W3C sont disponibles à l'adresse
http://www.w3.org/2003/03/Translations/byLanguage?language=fr
Copyright © 1994-2005 World Wide Web Consortium,
(Massachusetts Institute of Technology,
European Research Consortium for Informatics and Mathematics,
Keio University).
Tous droits réservés.
Consulter la notice de copyright pour les productions du W3C.
Copyright © 2002-2004 W3C ® (MIT, ERCIM, Keio), tous droits réservés. Les règles du W3C en termes de responsabilité, de marque commerciale, d'utilisation des documents et de licence logicielle s'appliquent. Vos interactions avec ce site sont en accord avec nos engagements sur le respect de la vie privée des membres et des visiteurs.
Ce document est un résumé du document "Architecture du World Wide Web, Volume Un". Le but de ce document est de présenter, dans un format concis, les principes, les contraintes et les bonnes pratiques relatives au document d'architecture. Chaque entrée possède un titre, un type (principe, contrainte ou bonne pratique), la section du document d'architecture où elle est abordée, suivie du texte de l'entrée. Le présent document est seulement un résumé et ne devrait pas être utilisé en tant que référence.
Ce document a été écrit par le groupe technique d'architecture (Technical Architecture Group ou TAG) (charte) du W3C.
La publication en tant que document de travail n'implique pas l'approbation par adhésion du W3C. Il s'agit d'une ébauche, qui peut être mise à jour, remplacée ou devenir obsolète à tout moment. Il est inapproprié de citer ce document en lui donnant un état autre que celui de "document de travail".
principe, 2
Le nommage global conduit aux effets de réseau global.
pratique, 2.1
Pour tirer parti du web global et en augmenter la valeur, les agents devraient fournir des URI comme identifiants de ressources.
contrainte, 2.2
Assignez des URI distincts à des ressources distinctes.
pratique, 2.3.1
Un propriétaire d'URI NE DEVRAIT PAS associer arbitrairement différents URI à la même ressource.
pratique, 2.3.1
Un agent qui reçoit un URI DEVRAIT se référer à la ressource associée en utilisant le même URI, caractère-par-caractère.
pratique, 2.4
Une spécification DEVRAIT réutiliser un schéma d'URI existant (plutôt que d'en créer un nouveau) lorsqu'il fournit les propriétés désirées pour les identifiants et leurs relations aux ressources.
pratique, 2.5
Les agents, utilisant des URI, NE DEVRAIENT PAS essayer de déduire des propriétés à partir de la ressource référencée.
pratique, 3.2
Les nouveaux protocoles créés pour le web DEVRAIENT transmettre les représentations en utilisant des flux d'octets typés avec les types de média Internet.
contrainte, 3.3
Les agents NE DOIVENT PAS ignorer les métadonnées des messages sans le consentement de l'utilisateur.
pratique, 3.3
Les gestionnaires de serveur DEVRAIENT permettre aux créateurs de représentation de contrôler les métadonnées liées à leurs représentations.
principe, 3.4
Les agents ne s'engagent pas en récupérant une représentation.
pratique, 3.5
Un propriétaire d'URI DEVRAIT fournir des représentations de la ressource qu'il identifie
principe, 3.5
Un développeur d'application ou un auteur de spécifications NE DEVRAIT PAS avoir besoin de récupérer les représentations à travers le réseau chaque fois qu'elles sont référencées.
pratique, 3.5.1
Un propriétaire d'URI DEVRAIT fournir des représentations consistantes et prédictibles de la ressource identifiée.
pratique, 4.2.1
Une spécification de format de données DEVRAIT fournir des informations relatives à la version.
pratique, 4.2.2
Une spécification de format XML DEVRAIT inclure des informations sur la politique de changement concernant les espaces de noms XML.
pratique, 4.2.3
Une spécification DEVRAIT fournir des mécanismes qui permettent à n'importe quelle partie de créer des extensions.
pratique, 4.2.3
L'extensibilité NE DOIT PAS interférer dans la conformité à la spécification originale.
pratique, 4.2.3
Une spécification DEVRAIT définir le comportement des agents face aux extensions non reconnues.
pratique, 4.3
Une spécification DEVRAIT permettre à des auteurs de séparer le contenu des aspects relatifs à la fois à la présentation et aux interactions.
pratique, 4.4
Une spécification DEVRAIT fournir des manières d'identifier des liens vers d'autres ressources, y compris vers les ressources secondaires (par l'intermédiaire d'identifiants de fragment).
pratique, 4.4
Une spécification DEVRAIT permettre des liens à l'échelle du web et non uniquement à l'intérieur d'un document.
pratique, 4.4
Une spécification DEVRAIT permettre aux auteurs de contenu d'utiliser des URI sans qu'ils soient contraints à un ensemble limité de schémas d'URI.
pratique, 4.4
Un format de données DEVRAIT incorporer des liens hypertextes si le paradigme attendu de l'interface utilisateur est hypertexte.
pratique, 4.5.3
Une spécification qui définit un vocabulaire XML DEVRAIT placer tous les noms d'élément et les noms globaux d'attribut dans un espace de noms.
pratique, 4.5.4
Le propriétaire d'un nom d'espace de noms XML DEVRAIT rendre disponible des informations destinées à être lues par des personnes et des informations optimisées pour les agents logiciels afin de satisfaire les besoins de ceux qui utiliseront ce vocabulaire d'espace de noms.
contrainte, 4.5.5
Ne permettez pas l'utilisation de QName et d'URI dans les valeurs d'attribut ou dans le contenu d'élément lorsqu'il est impossible de les distinguer.
pratique, 4.5.5
Une spécification dans laquelle les QName servent d'identifiant de ressource DOIT fournir une correspondance avec des URI.
pratique, 4.5.7
En général, un fournisseur de représentation NE DEVRAIT PAS assigner, à des représentations XML, des types de média Internet commençant par "text/".
pratique, 4.5.7
En général, un fournisseur de représentation NE DEVRAIT PAS spécifier, dans les en-têtes de protocole, l'encodage de caractères pour des données XML. En effet, les données se décrivent elles-mêmes.
principe, 5.1
Les abstractions orthogonales bénéficient des spécifications orthogonales.
principe, 5.3
Les agents qui font une reprise sur erreur en faisant un choix sans le consentement de l'utilisateur n'agissent pas au nom de cet utilisateur.