Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. Une liste des publications actuelles du W3C et la dernière révision de ce rapport technique peuvent être trouvées dans l'index des rapports techniques du W3C à l'adresse http://www.w3.org/TR/.
Voici la recommandation de 15 décembre 2004 de l'"architecture du World Wide Web, volume Un". Après la revue de ce document par des membres du W3C, des développeurs de logiciels, par d'autres groupes du W3C et d'autres tiers intéressés, le Directeur l'a approuvé comme recommandation du W3C. C'est un document stable, qui peut servir en tant que documentation de référence ou être cité dans un autre document. Le rôle du W3C, en produisant la recommandation, consiste à attirer l'attention sur la spécification et à en promouvoir le large déploiement. Elle participe à améliorer le fonctionnement et l'interopérabilité du Web.
Ce document a été produit par le groupe d'architecture technique [ndt. Technical Architecture Group ou TAG], qui, selon la charte, maintient une liste de discussions au sujet de l'architecture. La portée de ce document couvre un sous-ensemble utile de ces points. Il n'est pas prévu de les traiter tous. Le TAG prévoit d'aborder les questions en suspens (ainsi que les futures) maintenant que ce premier volume est édité en tant que recommandation W3C. Un historique complet des changements de ce document est disponible. Veuillez envoyer vos commentaires sur ce document à la liste public-webarch-comments@w3.org (archives publiques). Les discussions techniques du TAG ont lieu sur la liste www-tag@w3.org (archives publiques).
Ce document a été produit dans le cadre de la politique IPR du W3C du document de processus de juillet 2001. Le TAG maintient une liste publique de révélations de brevet concernant ce document ; cette page inclut également des instructions pour révéler un brevet. Quiconque aurait connaissance de l'existence d'un brevet susceptible de contenir une (ou plusieurs) revendication essentielle concernant cette spécification devrait divulguer cette information, conformément au chapitre 6 de la politique de brevetabilité du W3C.
Le World Wide
Web (WWW ou plus simplement le
Web) est
un espace d'informations composé d'éléments identifiés par des identifiants
globaux, nommés des identifiants de ressource uniforme [ndt. Uniform Resource
Identifier](URI).
Les exemples, à l'image du scénario de voyage suivant,
sont utilisés tout au long de ce document pour illustrer le comportement
typique d'agents
Web (personne ou logiciel agissant sur cet espace
d'informations). Un agent
utilisateur représente un utilisateur. Le terme agent logiciel
comprend les serveurs, les proxies, les robots de recherche, les
navigateurs et les lecteurs multimédia.
Scénario
Alors qu'elle organise un
voyage à Mexico, Nadia lit “les informations sur le temps à Oaxaca:
'http://weather.example.com/oaxaca'” dans son superbe magazine de
voyage. Nadia est suffisamment expérimentée avec l'utilisation du web pour
reconnaître que "http://weather.example.com/oaxaca" est un URI et qu'elle
obtiendra certainement l'information appropriée via son navigateur Web. Lorsqu'elle
saisit l'URI dans son navigateur :
- Le navigateur reconnaît que l'information saisie par Nadia est un
URI.
- Le navigateur exécute une action d'obtention de l'information. Il se
se base sur la configuration du comportement à adopter face aux ressources identifiées par le schéma d'URI "http".
- L'autorité responsable de "weather.example.com" fournit l'information
en réponse à cette demande.
- Le navigateur interprète la réponse, identifiée comme étant du XHTML
par le serveur et effectue des actions additionnelles de récupération
pour les graphiques intégrés ainsi que pour tout autre contenu nécessaire.
- Le navigateur affiche l'information recherchée, qui inclut des
liens hypertextes vers d'autres informations. Nadia peut alors suivre ces liens pour rechercher une information complémentaire.
Ce scénario illustre les trois bases architecturales du web qui sont abordées dans ce document :
Identification (§2).Les URI sont utilisés pour identifier des ressources. Dans ce scénario relatif au voyage, la ressource est un bulletin météo à Oaxaca mis à jour périodiquement. L'URI est “http://weather.example.com/oaxaca”.
Interaction (§3). Les agents web communiquent en s'appuyant sur des protocoles normalisés qui permettent des interactions grâce à l'échange de messages conformes à une syntaxe et une sémantique définies. En saisissant un URI dans un dialogue de récupération ou en choisissant un lien hypertexte, Nadia indique à son navigateur d'effectuer une action pour obtenir la ressource identifiée par l'URI. Dans cet exemple, le navigateur envoie une requête HTTP GET (qui fait partie du protocole HTTP) au serveur situé à l'adresse "weather.example.com", via le port TCP/IP 80. Le serveur retourne alors un message contenant ce qu'il détermine être une représentation de la ressource au moment de sa génération.
Notez que cet exemple est spécifique à la navigation dans des informations hypertextes — d'autres genres d'interaction sont possibles, que ce soit par l'intermédiaire de navigateurs ou d'autres types d'agent Web. Notre exemple sert à illustrer une interaction classique et non à définir la gamme des interactions possibles, ni à limiter les manières disponibles pour les agents pour utiliser le Web.
Formats (§4). La plupart des protocoles utilisés pour la récupération et/ou la soumission de représentation se servent d'une séquence d'un ou plusieurs messages. Pris ensemble, ils forment un certain volume de données et de métadonnées pour la représentation, qui est utilisé pour son transfert entre les agents. Le choix du protocole d'interaction induit des limites sur les formats des données et des métadonnées de la représentation qui peut être transmise. HTTP, par exemple, transmet typiquement un flux simple d'octets plus des métadonnées. Il emploie l'information "Content-Type" et les champs d'en-tête "Content-Encoding" pour l'identification à posteriori du format de la représentation. Dans ce scénario, la représentation est transférée en XHTML, comme l'indique le champ d'en-tête HTTP "Content-Type". Ce dernier contient, en effet, le type de média Internet "application/xhtml+xml". Il indique que les données de la représentation peuvent être traitées selon les spécifications de XHTML.
Le navigateur de Nadia est configuré et programmé pour interpréter la réception d'une représentation ayant le type "application/xhtml+xml" comme étant une instruction de formatage du contenu de cette représentation selon le modèle de rendu XHTML. Il en va de même pour toutes les interactions complémentaires (telles que les requêtes vers des feuilles externes ou encore des images intégrées) réclamées par la représentation. Dans ce scénario, les données de la représentation XHTML reçues, suite à la demande initiale, indiquent par ailleurs au navigateur de Nadia de récupérer et d'afficher les cartes météo incluses. Chacune est identifiée par un URI et cause, de ce fait, une action supplémentaire de récupération. Elle engendre d'autres représentations qui sont traitées par le navigateur selon leurs propres formats de données (par exemple, "application/svg+xml" indique le format de données de SVG). Ce processus continue jusqu'à ce que tous les formats de données aient été rendus. Le résultat de tous ces traitements, une fois que le navigateur a atteint un état stable répondant à l'action initiale demandée par Nadia, est généralement désigné par le terme de "Page Web".
La figure suivante montre les relations entre un identifiant, une ressource et une représentation.
Dans la suite de ce document, nous soulignerons les points importants d'architecture
ayant un rapport avec les identifiants Web, les protocoles et les formats. Nous
discuterons également des principes généraux d'architecture (§5) majeurs et comment ils s'appliquent au Web.
Ce document décrit les propriétés que nous désirons pour le web et les choix de conception faits pour les mettre en oeuvre. Il favorise la réutilisation de standards existants lorsqu'ils sont appropriés et donne des conseils sur la façon d'innover en étant en conformité avec l'architecture du Web.
Les termes DOIT (DOIVENT), NE DOIT (DOIVENT) PAS, DEVRA (DEVRONT), NE DEVRA (DEVRONT) PAS et PEUT (PEUVENT) sont utilisés dans les principes, contraintes et bonnes pratiques. Ils sont décrits dans le document [RFC2119].
Ce document n'inclut pas de dispositions de conformité pour les raisons suivantes :
- La conformité logicielle se doit d'être si diverse qu'il ne semble pas utile de pouvoir se référer à la classe de conformité des agents logiciels.
- Certaines notes de bonnes pratiques concernent les personnes. Les spécifications, quant à elles, définissent généralement la conformité pour le logiciel et non pour les personnes.
- Nous ne croyons pas que l'ajout d'une section ayant pour objet la conformité est susceptible d'augmenter l'utilité du document.
Le but de ce document est d'informer à propos des discussions liées à l'architecture du Web. Le public visé par ce document inclut :
- Les participants aux activités du W3C
- D'autres groupes et personnes concevant des technologies devant être intégrées au Web
- Les personnes mettant en oeuvre les spécifications du W3C
- Les auteurs et éditeurs de contenu Web
Note: Ce document ne fait aucune distinction formelle entre les termes "langage" et "format". Le contexte détermine l'utilisation de chacun. L'expression "concepteur de spécification" englobe les notions de conception de langage, de format et de protocole.
Ce document présente l'architecture générale du Web. D'autres groupes à l'intérieur et à l'extérieur du W3C se concentrent également sur des aspects spécifiques de l'architecture du Web, comme l'accessibilité, l'assurance qualité, l'internationalisation, l'indépendance des dispositifs et les services Web.
La section concernant les spécifications liées à l'architecture (§7.1) fait référence à ces spécifications.
Ce document essait d'atteindre un équilibre entre brièveté et précision tout en illustrant par des exemples. Les conclusions du TAG sont des documents d'information qui complètent le présent document en fournissant plus de détails sur des points précis. Ce document inclut quelques extraits de ces conclusions. Ces documents complémentaires évoluant indépendamment, celui-ci inclut des références aux conclusions approuvées par le TAG. Pour les autres discussions du TAG non approuvés mais abordés ici, les références sont incluses dans la liste des publications du TAG.
Beaucoup d'exemples dans ce document, impliquant la participation d'une personne, font l'hypothèse d'un modèle familier d'interaction avec le Web (illustré au début de l'introduction) dans lequel une personne suit un lien par l'intermédiaire d'un agent utilisateur, celui-ci récupère et présente les données, puis l'utilisateur suit un autre lien, etc... Ce document n'aborde aucun autre modèle d'interaction tel que la navigation avec la voix (voir, par exemple, [VOICEXML2]). Le choix du modèle d'interaction peut avoir un impact sur le comportement attendu d'un agent. Par exemple, lorsqu'un agent utilisateur graphique, s'exécutant sur un ordinateur portable ou sur un dispositif mobile, rencontre une erreur, il peut la rapporter directement à l'utilisateur par des manifestations visuelles et sonores et lui présenter des options pour la résoudre. D'autre part, lorsque quelqu'un navigue sur le web via la voix et ne dispose que d'un retour sonore, l'arrêt du dialogue pour attendre une information provenant de l'utilisateur peut réduire sa facilité d'utilisation. Il est en effet vraiment facile de "perdre le fil" en navigant qu'avec une sortie audio. Ce document ne traite pas de la façon dont les principes, les contraintes et les bonnes pratiques identifiés ici s'appliquent dans tous les contextes d'interaction.
Les points importants dans ce document sont classés par catégorie comme suit :
- Principe
- Un principe architectural est une règle fondamentale qui s'applique à un grand nombre de situations et de variables. Parmi ces principes architecturaux se trouvent la "séparation des problèmes", l'"interface générique", la "syntaxe auto-descriptive", une "sémantique évidente", l'"effet de réseau" (la loi de Metcalfe) et la loi d'Amdahl : "la vitesse d'un système est limitée par son composant le plus lent".
- Contrainte
- Dans la conception du Web, certains choix, comme les noms des éléments
p et li en HTML, le choix du caractère deux points (:) dans les URI ou encore le regroupement des bits en grappe de huit (octets) sont arbitraires. Si paragraph avait été choisi à la place de p ou l'astérisque (*) au lieu des deux points, le résultat à grande échelle aurait été, très probablement, identique. Ce document se concentre sur des choix de conception plus fondamentaux : les choix de conception qui mènent aux contraintes, c'est-à-dire des restrictions dans le comportement ou l'interaction dans le système. Ces contraintes peuvent être imposées pour des raisons techniques, politiques ou autres afin de réaliser des propriétés souhaitées dans le système, comme l'accessibilité, la portée globale, la relative facilité d'évolution, l'efficacité et l'extensibilité dynamique.
- Bonne pratique
- Les bonnes pratiques, énoncées par des développeurs de logiciel, les auteurs, les responsables de site, les utilisateurs et les concepteurs de spécification, augmentent la valeur du Web.
Pour sa communication interne, une communauté s'accorde (jusqu'à un degré raisonnable) sur un ensemble de termes et sur leur signification. Un des buts du Web, depuis sa génèse, a été d'établir une communauté globale dans laquelle n'importe quelle partie peut partager une information avec n'importe quelle autre partie. À dessein d'y parvenir, le web se sert d'un système simple et global d'identification : l'URI. Les URI sont une pierre angulaire de l'architecture du Web, fournissant une identification commune à travers le Web. La portée globale des URI favorise les "effets de réseau" à grande échelle : la valeur d'un identifiant augmente à mesure qu'il est utilisé de façon consistante (par exemple, plus il est employé dans les liens hypertextes (§4.4)).
Principe: Identifiants globaux
Le nommage global conduit aux effets de réseau global.
Ce principe date au moins du temps où Douglas Engelbart effectuait un travail séminal sur les systèmes hypertextes ouverts ; voir la section chaque objet accessible dans le document [Eng90].
Le choix de la syntaxe pour les identifiants globaux est quelque peu arbitraire ; l'important reste leur portée globale. L'identifiant de ressource uniforme, [URI], a été déployé avec succès depuis la création du Web. Il y a des avantages substantiels à participer au réseau existant d'URI, comme l'établissement de liens, de signets, de mise en mémoire cache et l'indexation par des moteurs de recherche. Par ailleurs, créer un nouveau système d'identification qui possède les mêmes propriétés que les URI, induit un coût non négligeable.
Bonne pratique : Identifier à l'aide d'URI
Pour tirer parti du web global et en augmenter la valeur, les agents devraient fournir des URI comme identifiants de ressources.
Une ressource devrait avoir un URI associé à partir du moment où une tierce partie peut vouloir créer un lien hypertexte vers elle, faire ou réfuter des affirmations à son sujet, rechercher ou mettre en mémoire cache une représentation la concernant, l'inclure en partie ou dans son ensemble en la référençant dans une autre représentation, l'annoter ou encore effectuer d'autres opérations. Les développeurs de logiciels devraient attendre une certaine utilité du partage d'URI à travers des applications, même si elle n'est pas évidente de prime abord. Les conclusions du TAG sur "les URI, la possibilité d'adressage et l'utilisation du HTTP GET et POST [URIs, Addressability, and the use of HTTP GET and POST]" montrent les avantages complémentaires et la possibilité d'adressage par les URI.
Note: Les schémas d'URI (tels que les spécifications du schéma "ftp") emploient le terme "désigner" alors que ce document utilise "identifier".
Par conception, un URI identifie une ressource. Nous ne limitons pas la portée de ce qui pourrait être une ressource. Le terme "ressource" est employé dans un sens général pour qualifier tout ce qui pourrait être identifié par un URI. Il est courant, sur le web hypertexte, de décrire des pages Web, des images, des catalogues de produits, etc... comme étant des “ressources”. Les caractéristiques essentielles qui différencient ces ressources peuvent être empaquetées dans un message. Nous identifions cet ensemble par l'expression “ressources de l'information”.
Ce document est un exemple de ressources d'information. Il se compose de mots, de symboles de ponctuation, de graphiques et d'autres objets qui peuvent être encodés en une séquence de bits, avec un degré variable de fidélité. En principe, tout ce qui compose l'essentiel de l'information de ce document peut transféré dans un message, dont la valeur ajoutée est une représentation de ce document.
Cependant, notre utilisation du terme ressource est intentionnellement plus large. D'autres choses, comme des voitures et des chiens (et, si vous avez imprimé ce document sur des feuilles de papier, l'objet que vous tenez dans vos mains), sont également des ressources. Mais il ne s'agit pas de ressources d'information, car leur essence n'est pas de l'information. Même s'il est possible de décrire un grand nombre de choses au sujet d'une voiture ou d'un chien dans une séquence de bits, la somme de ces choses sera toujours une approximation du caractère essentiel de la ressource.
Nous définissons le terme “ressource de l'information” car nous observons qu'il est utile lors des discussions à propos de la technologie web et peut l'être lors de l'élaboration de spécifications pour des équipements construits pour un usage sur le Web.
Contrainte : Les URI identifient une ressource simple
Assignez des URI distincts à des ressources distinctes.
Puisque la portée d'un URI est globale, la ressource identifiée par un URI ne dépend pas du contexte dans lequel elle apparaît (voir également la section au sujet de l'identification indirecte (§2.2.3)).
Un [URI] est un accord sur la façon dont la communauté Internet assigne des noms et les associe aux ressources qu'ils identifient. Les URI sont divisés en schémas (§2.4) qui définissent, par l'intermédiaire de leur spécification, le mécanisme par lequel des identifiants spécifiques au schéma sont associés aux ressources. Par exemple, le schéma d'URI "http" ([RFC2616]) utilise des serveurs DNS et HTTP, basés sur TCP, afin d'attribuer et de résoudre un identifiant. Par conséquent, les identifiants tels que "http://example.com/somepath#someFrag" signifie souvent, au vu de l'expérience de la communauté, l'exécution d'une requête HTTP GET à partir de l'identifiant et si la réponse est correcte, l'interprétation de la réponse comme étant une représentation de la ressource identifiée. (voir également les identifiants de fragment (§2.6)). Naturellement, une action de récupération comme un GET n'est pas la seule manière d'obtenir des informations au sujet d'une ressource. On pourrait également éditer un document qui prétend définir la signification d'un URI particulier. Ces autres sources d'information peuvent suggérer des significations pour de tels identifiants, cependant l'observation de ces suggestions relève d'une politique locale.
De la même façon que l'on pourrait souhaiter se référer à une personne par l'intermédiaire de différents noms (par son nom et son prénom, seulement par prénom, par un surnom lié au sport, par un surnom romantique et ainsi de suite), l'architecture du web permet d'associer plus d'un URI à une ressource. Les URI qui identifient la même ressource sont nommés des alias d'URI. La section les concernant (§2.3.1) revient sur certains coûts potentiels relatifs à la création d'URI multiples pour la même ressource.
Plusieurs sections de ce document abordent la relation entre les URI et les ressources, comme :
Par conception, un URI identifie une ressource. L'utilisation d'un même URI pour identifier directement différentes ressources produit une collision d'URI. Une collision induit souvent un coût dans la communication relatif à l'effort exigé par la levée des ambiguïtés.
Supposons, par exemple, qu'une organisation se sert d'un URI pour se référer au film "The Sting" et qu'une autre organisation emploie le même URI pour se rapporter à un forum de discussion au sujet de ce film. Pour un tiers, familier des deux organismes, cette collision crée une confusion au sujet de ce que l'URI identifie, diminuant ainsi la valeur de cet URI. Par exemple, si quelqu'un voulait parler de la date de création de la ressource identifiée par l'URI, il ne serait pas clair de savoir si elle signifie "quand le film a été créé" ou "quand le forum de discussion au sujet du film a été créé."
Des solutions sociales et techniques ont été conçues pour aider à éviter la collision d'URI. Cependant, le succès ou l'échec de ces différentes approches dépend de l'importance du consensus qui existe dans la communauté Internet à propos du respect des spécifications les définissant.
La section sur l'attribution d'URI (§2.2.2) examine des approches pour établir la source d'informations appropriée permettant de définir quelle ressource est identifiée par un URI.
Les URI sont parfois utilisés pour des identifications indirectes (§2.2.3). Cela ne conduit pas nécessairement à des collisions.
L'attribution d'URI est le processus consistant à associer un URI à une ressource. L'attribution peut tout aussi bien se faire par les propriétaires de ressource ou par d'autres parties. L'important est d'éviter les
collisions d'URI (§2.2.1).
La propriété d'URI est une relation entre un URI et une entité sociale, telle qu'une personne, une organisation ou une spécification. La propriété d'URI procure certains droits à l'entité sociale concernée, comme :
- la possibilité de transmettre, à un tiers, la propriété de certaines ou de toutes les URI possédés (délégation) et
- d'associer une ressource à un URI possédé (attribution d'URI).
Par convention sociale, la propriété d'URI est déléguée depuis le référentiel des schémas d'URI de l'IANA [IANASchemes], lui-même une entité sociale, aux spécifications de schémas d'URI enregistrés auprès de l'IANA. Certaines spécifications de schémas d'URI délèguent la propriété à des référentiels subordonnés ou à d'autres propriétaires explicitement nommés, qui peuvent, de la même façon déléguer cette propriété. Dans le cas d'une spécification, la propriété appartient finalement à la communauté qui maintient cette spécification.
L'approche adoptée pour le schéma d'URI "http", par exemple, suit le modèle selon lequel la communauté Internet délègue la responsabilité, par l'intermédiaire du référentiel de schémas d'URI de l'IANA et du DNS, au moyen d'un ensemble d'URI ayant un préfixe commun, pour un propriétaire particulier. La forte confiance du web dans le répertoire central DNS est une des conséquences de cette approche. Une approche différente est adoptée par le schéma de la syntaxe URN [RFC2141] qui délègue la propriété des différentes parties de l'espace d'URN aux spécifications de l'espace de noms URN, qui sont elles-mêmes enregistrées dans un référentiel d'identifiants d'espace de noms, maintenu par l'IANA.
Les propriétaires d'URI sont chargés d'éviter l'attribution d'URI équivalents à des ressources multiples. Ainsi, si des spécifications de schéma d'URI prévoient la délégation d'un URI ou d'ensembles organisés d'URI, il est nécessaire de prendre les mesures visant à s'assurer que la propriété réside finalement entre les mains d'une entité sociale unique. Permettre des propriétaires multiples augmente la probabilité de collisions d'URI.
Les propriétaires d'URI peuvent organiser ou déployer une infrastructure afin de s'assurer que les représentations des ressources associées sont disponibles et, le cas échéant, que l'interaction avec la ressource est possible par le biais d'échange de représentations.
La gestion [responsable] des représentations (§3.5) par les propriétaires d'URI est source d'attentes sociales. Les autres implications sociales concernant la propriété d'URI ne sont pas abordées ici.
Voir les discussions du TAG siteData-36, concernant l'expropriation d'autorité de nommage.
Certains schémas utilisent d'autres techniques que la propriété déléguée afin d'éviter les collisions. Par exemple, la spécification pour le schéma d'URL de données (sic) [RFC2397] indique qu'une ressource identifiée par un schéma d'URI de données ne possède qu'une seule représentation possible. Les données de la représentation composent l'URI qui identifie cette ressource. Ainsi, la spécification elle-même détermine comment les URI de données sont attribués ; aucune délégation n'est possible.
D'autres schémas (comme "news:comp.text.xml") se base sur un processus social.
Énoncer que l'URI "mailto:nadia@example.com" identifie à la fois une boîte aux lettres Internet et Nadia, introduit une collision d'URI. Par contre, l'URI peut servir à identifier indirectement Nadia. Et c'est de cette façon que les identifiants sont généralement employés.
En écoutant les actualités, il est possible d'entendre un reportage sur la Grande-Bretagne commençant ainsi : "Aujourd'hui, le 10 Downing Street a annoncé une série de nouvelles mesures économiques". En général, le "10 Downing Street" identifie la résidence officielle du premier ministre anglais. Dans ce contexte, le journaliste emploie cette formule (comme la rhétorique anglaise le permet) pour identifier indirectement le gouvernement britannique. De la même façon, les URI identifient des ressources, mais elles peuvent également servir, dans bien des cas, à désigner indirectement d'autres ressources. Les politiques d'attribution adoptées de façon globale font de certains URI des identifiants généraux. La politique locale, quant à elle, établit ce qu'ils identifient de façon indirecte.
Supposons que nadia@example.com soit l'adresse de courrier électronique de Nadia. Les organisateurs d'une conférence à laquelle elle assiste pourraient employer "mailto:nadia@example.com" pour se référer indirectement à elle (par exemple, en se servant de l'URI comme clef dans leur base de données des participants à la conférence). Cela ne constitue pas un cas de collision d'URI.
Les URI, qui sont identiques au caractère près, se réfèrent à la même ressource. L'architecture du web permet d'associer plusieurs URI à une ressource donnée. Ainsi deux URI non identiques (caractère pour caractère) peuvent se rapporter à une même ressource. Des URI différents ne se rapportent donc pas nécessairement à des ressources différentes. Cela induit cependant un coût informatique plus élevé pour déterminer que des URI différents se rapportent à la même ressource.
Pour réduire le risque de cas faussement négatif (c'est-à-dire, une conclusion erronée sur le fait que deux URI ne se rapportent pas à la même ressource) ou de cas faussement positif (c'est-à-dire, une conclusion inexacte sur le postulat que deux URI se rapportent effectivement à la même ressource), certaines spécifications décrivent des tests d'équivalence complémentaires à la comparaison caractère par caractère. Les agents qui tirent des conclusions en se basant sur des comparaisons non approuvées par les spécifications concernées engagent leur responsabilité pour tout problème potentiel résultant ; pour plus d'informations sur le comportement responsable à adopter face à des conclusions non autorisées, voir la section sur la gestion des erreurs (§5.3). La section 6 des [URI] fournit plus d'informations sur la comparaison d'URI et sur la réduction du risque de jugement faussement négatif et positif.
Voir également l'affirmation que deux URI identifient la même ressource (§2.7.2).
Bien que les alias d'URI présentent des avantages (comme la flexibilité en matière de nommage), il est bon de considérer également leurs coûts. Les alias d'URI sont nocifs quand ils divisent un ensemble (le Web) composé de ressources liées entre elles. Un corollaire du principe de Metcalfe (l'"effet de réseau") veut que la valeur d'une ressource donnée peut être mesurée par le nombre et la valeur des autres ressources dans son voisinage réseau, c'est-à-dire, les ressources qui font un lien vers elle.
Les alias posent un problème. Si une même ressource est désignée, grâce à un URI donné, par la moitié d'un ensemble et qu'elle est également désignée à l'aide d'un deuxième URI par la seconde moitié de cet ensemble, une division se crée. Non seulement la ressource perd de sa valeur en raison de cette fracture, mais c'est l'ensemble des ressources qui se dévalue en raison de l'absence des relations qui auraient dû exister entre les ressources faisant des références.
Bonne pratique : Éviter les alias d'URI
Un propriétaire d'URI NE DEVRAIT PAS associer arbitrairement différents URI à la même ressource.
Les consommateurs d'URI ont également un rôle à jouer en s'assurant de la cohérence de l'URI. Par exemple, lors de la transcription d'un URI, les agents ne devraient pas encoder, de façon gratuite, les caractères avec des pourcents. Le terme "caractère" se rapporte à des caractères d'URI (voir la définition dans la section 2 des [URI]). L'encodage avec des pourcents est discuté dans la section 2.1 de cette spécification.
Bonne pratique : Usage consistant des URI
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.
Lorsqu'un URI devient monnaie courante, le propriétaire de l'URI devrait utiliser des techniques se basant sur le protocole, telles que la redirection côté serveur, pour relier les deux ressources. Le support, par son propriétaire, de la redirection d'un alias d'URI vers l'URI "officiel" bénéficie à toute la communauté. Pour plus d'informations sur la redirection, voir la section 10.3, "Redirection", dans la [RFC2616]. Voir également [CHIPS] pour une discussion à propos de certaines des meilleures pratiques pour les administrateurs de serveur.
Le phénomène d'alias d'URI ne se produit que lorsque plus d'un URI est utilisé pour identifier la même ressource. Le fait que différentes ressources possèdent parfois la même représentation ne fait pas pour autant de ces URI des alias.
Scénario
Sur son site Web, Dirk voudrait ajouter un lien au site donnant la météo à Oaxaca. Il se sert alors de l'URI http://weather.example.com/oaxaca et étiquette son lien "temps à Oaxaca, le 1 août 2004". Nadia précise à Dirk qu'il se trompe vis-à-vis de la pertinence de l'URI employé. La politique de ce site définit que l'URI en question identifie le temps courant à Oaxaca (quel que soit le jour) et non le temps du 1 août. Naturellement, le premier jour d'août 2004, le lien de Dirk sera correct. Mais le reste du temps, il induira en erreur les visiteurs de son site Web. Nadia signale à Dirk que ce site météo fournit un URI différent, disponible de manière permanente et assigné à une ressource décrivant le temps du 1 août 2004.
Dans cette histoire, il y a deux ressources : "le temps courant à Oaxaca" et "le temps à Oaxaca le 1 août 2004". Le site donnant la météo à Oaxaca assigne deux URI à ces deux ressources différentes. Le 1 août 2004, les représentations pour ces ressources sont identiques. Le fait que le déréférencement de deux URI différents produit des représentations identiques ne permet pas de conclure que les deux URI sont des alias.
Dans l'URI "http://weather.example.com/", le terme "http" qui précède les deux points (":") nomme un schéma d'URI. Chacun de ces schémas d'URI possède une spécification particulière qui détaille comment les identifiants de ce schéma sont alloués et sont associés à une ressource. La syntaxe d'URI est ainsi un système d'appellation fédéré et extensible dans lequel la spécification de chaque schéma peut limiter la syntaxe et la sémantique des identifiants du schéma.
Exemples d'URI provenant de divers schémas :
- mailto:joe@example.org
- ftp://example.org/aDirectory/aFile
- news:comp.infosystems.www
- tel:+1-816-555-1212
- ldap://ldap.example.org/c=GB?objectClass?one
- urn:oasis:names:tc:entity:xmlns:xml:catalog
Même si l'architecture du web permet la définition de nouveaux schémas, une telle introduction est coûteuse. De nombreux aspects du traitement d'URI sont dépendants d'un schéma particulier. Par ailleurs, un grand nombre de logiciels déployés traite déjà les schémas d'URI bien connus. L'introduction d'un nouveau schéma d'URI exige le développement et le déploiement non seulement de logiciels clients pouvant manipuler le schéma, mais également d'agents auxiliaires tels que des passerelles, des proxies et des systèmes de mémoire cache. Voir la [RFC2718] pour d'autres considérations et les coûts liés à la conception de schéma d'URI.
En raison de ces coûts, si un schéma d'URI existant satisfait les besoins d'une application, les concepteurs devraient l'employer plutôt que d'en inventer un.
Bonne pratique : Réutiliser les schémas d'URI
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.
Considérons notre scénario de voyage : Est-ce que l'agent fournissant des informations au sujet du temps à Oaxaca devrait enregistrer un nouveau schéma d'URI "weather" pour identifier des ressources liées au temps ? Elles pourraient alors servir à des URI comme "weather://travel.example.com/oaxaca". Quand un agent logiciel déréférence ce type d'URI, si l'action réelle est un HTTP GET, servant à obtenir une représentation de la ressource, alors un URI "http" devrait suffire.
L'IANA (Internet Assigned Numbers Authority) maintient un référentiel [IANASchemes] des correspondances entre les noms de schéma d'URI et leur spécification. Par exemple, ce référentiel indique que le schéma "http" est défini par la [RFC2616]. Le processus pour enregistrer un nouveau schéma d'URI est, quant à lui, défini par la [RFC2717].
Les schémas d'URI non enregistrés NE DEVRAIENT PAS être utilisés pour un certain nombre de raisons :
- En général, il n'y a pas de moyen reconnu pour accéder à la spécification du schéma.
- Le schéma peut être utilisé par d'autres dans des buts différents.
- Il ne faut pas s'attendre à ce qu'un logiciel généraliste puisse faire quoi que ce soit d'utile avec ce type de schéma d'URI, mise à part la comparaison d'URI.
Une motivation malencontreuse qui pousse à enregistrer un nouveau schéma d'URI consiste à permettre à un agent logiciel de lancer une application particulière lorsqu'il obtient une représentation. Il est possible d'obtenir le même résultat, mais à moindre coût, en s'appuyant plutôt sur le type de la représentation, permettant alors l'utilisation de protocoles et de mises en oeuvre de transfert existants.
Même si un format inconnu empêche un agent de traiter des données liées à une représentation, il peut néanmoins la récupérer. Les données peuvent contenir des informations suffisantes pour permettre à un utilisateur ou à un agent utilisateur d'en faire une certaine utilisation. À contrario lorsqu'un agent ne sait pas traiter un nouveau schéma d'URI, il ne peut pas en obtenir de représentation.
Lors de la conception d'un nouveau format de données, le mécanisme de choix pour favoriser son déploiement sur le web est l'utilisation du type de média Internet (voir les types de représentation et les types de média Internet (§3.2)). Les types de média fournissent également des moyens pour construire de nouvelles applications d'information, comme décrit dans les futures directions pour les formats de données (§4.6).
Il est tentant de deviner la nature d'une ressource en examinant un URI qui l'identifie. Cependant, le web est construit de telle sorte que les agents communiquent l'état des ressources d'information à l'aide de représentations et non via des identifiants. En général, il n'est pas possible de déterminer le type de la représentation d'une ressource en examinant un URI de cette ressource. Par exemple, le ".html" terminant "http://example.com/page.html" ne fournit aucune garantie sur le fait que la représentation de la ressource identifiée sera servie avec le type de média Internet "text/html". L'éditeur est libre d'assigner des identifiants et de définir comment ils sont servis. Le protocole HTTP ne contraint pas le type de média Internet à se baser sur le composant chemin de l'URI. Le propriétaire de l'URI est libre de configurer le serveur pour renvoyer une représentation en utilisant par exemple PNG ou tout autre format de données.
L'état d'une ressource peut évoluer dans le temps. Exiger d'un propriétaire d'URI de publier un nouvel URI pour chaque changement d'état de la ressource conduirait à un nombre significatif de références cassées. Pour apporter plus de robustesse, l'architecture du web met en avant l'indépendance entre un identifiant et l'état de la ressource identifiée.
Bonne pratique : Opacité d'URI
Les agents, utilisant des URI, NE DEVRAIENT PAS essayer de déduire des propriétés à partir de la ressource référencée.
En pratique, un nombre restreint de déductions, explicitement autorisées par les spécifications sous-jacentes, peuvent être faites. Certaines de ces déductions sont abordées dans la section qui détaille l'obtention d'une représentation (§3.1.1).
L'URI d'exemple utilisé dans le scénario de voyage ("http://weather.example.com/oaxaca") suggère à un lecteur (humain) que la ressource identifiée a un rapport avec le temps à Oaxaca. Un site indiquant le temps à Oaxaca pourrait tout aussi bien être identifié par l'URI "http://vjc.example.com/315". Par ailleurs, l'URI "http://weather.example.com/vancouver" pourrait identifier la ressource "mon album photo".
D'un autre côté, l'URI "mailto:joe@example.com" indique que l'URI se réfère à une boîte aux lettres. La spécification du schéma d'URI "mailto" autorise les agents à déduire que les URI de cette forme identifient des boîtes aux lettres Internet.
Certaines autorités d'attribution d'URI documentent et éditent leur politique d'assignation d'URI. Pour plus d'informations sur l'opacité d'URI, voir les discussions du TAG metaDataInURI-31 et siteData-36.
Scénario
Lorsque Nadia lit le document XHTML qu'elle a reçu, comme étant une représentation de la ressource identifiée par "http://weather.example.com/oaxaca", elle constate que l'URI "http://weather.example.com/oaxaca#weekend" se réfère à la partie de la représentation qui donne des informations sur les perspectives du week-end. Cet URI inclut l'identifiant de fragment "weekend" (la chaîne de caractères après le "#").
Le composant identifiant de fragment d'un URI permet l'identification indirecte d'une ressource secondaire en se référant à une ressource primaire et à une information d'identification additionnelle. La ressource secondaire peut être une certaine partie ou un sous-ensemble de la ressource primaire, une certaine vue sur des représentations de la ressource primaire ou une autre ressource définie ou décrite par ces représentations. Les termes "ressource primaire" et "ressource secondaire" sont définis dans la section 3.5 du document [URI].
Les termes "primaire" et "secondaire" dans ce contexte ne limitent pas la nature de la ressource (ce ne sont pas des classes). Dans ce contexte, primaire et secondaire indiquent simplement qu'il existe une relation entre les ressources qui forment un URI : l'URI avec un identifiant de fragment. Toute ressource peut être identifiée comme étant une ressource secondaire. Elle pourrait également être identifiée en utilisant un URI sans identifiant de fragment. Une ressource peut être identifiée comme ressource secondaire par l'intermédiaire d'URI multiples. Le but de ces termes est de permettre de discuter de la relation entre de telles ressources et non de se limiter à la nature d'une ressource.
L'interprétation des identifiants de fragment est abordée dans la section concernant les types de représentation et sémantique de l'identifiant de fragment (§3.2.1).
Voir la discussion du TAG abstractComponentRefs-37, qui concerne l'utilisation des identifiants de fragment avec des espaces de noms pour l'identification des composants abstraits.
Il reste des questions en suspens concernant les identifiants sur le Web.
L'intégration des identifiants internationalisés (c'est-à-dire, composés de caractères outrepassant ceux permis par les [URI]) dans l'architecture web est un sujet important et ouvert. Voir la discussion du TAG, IRIEverywhere-27, abordant le travail mené à propos de cette problématique.
Les technologies sémantiques naissantes, comme "le Langage d'Ontologie Web (OWL)" [OWL10], définissent des propriétés RDF, telles que sameAs pour affirmer que deux URI identifient la même ressource ou inverseFunctionalProperty pour le suggérer.
La communication au sujet de ressources, entre des agents au travers d'un réseau, implique des URI, des messages et des données. Les protocoles du web (tels que HTTP, FTP, SOAP, NNTP et SMTP) sont basés sur l'échange de messages. Un message peut inclure des données, mais aussi des métadonnées (comme les en-têtes HTTP "Alternates" et "Vary"), au sujet d'une ressource, des données du message et du message lui-même (à l'image de l'en-tête HTTP "Transfer-encoding"). Un message peut même inclure des métadonnées relatives aux métadonnées du message (pour la vérification de l'intégrité du message, par exemple).
Scénario
Nadia suit un lien hypertexte, dont le nom est "image satellite". Elle s'attend ainsi à obtenir une photo satellite de la région d'Oaxaca. Le lien vers l'image satellite est un lien XHTML codé ainsi <a href="http://example.com/satimage/oaxaca">image satellite</a>. Le navigateur de Nadia analyse l'URI et détermine que son schéma est "http". La configuration du navigateur déduit la façon de localiser l'information identifiée. Ce peut être par l'intermédiaire d'une zone de cache, contenant des actions de récupération déjà effectuées, par le contact d'un intermédiaire (tel qu'un serveur proxy) ou par accès direct au serveur identifié par une partie de l'URI. Dans cet exemple, le navigateur ouvre une connexion réseau sur le port 80 du serveur situé à l'adresse "example.com". Puis, il envoie un message "GET", comme le protocole HTTP le spécifie, pour demander une représentation de la ressource.
Le serveur envoie alors un message de réponse au navigateur, en conformité une nouvelle fois avec le protocole HTTP. Le message se compose de plusieurs en-têtes et d'une image JPEG. Le navigateur lit les en-têtes, déduit du champ "Content-Type" que le type de média Internet de la représentation est "image/jpeg". Il lit alors la séquence d'octets qui composent les données de la représentation et affiche l'image.
Cette section décrit les principes et les contraintes d'architecture concernant les interactions entre les agents. Il s'agit de sujets comme les protocoles réseau et les modèles d'interaction, ainsi que les interactions entre le web en tant que système et les personnes qui s'en servent. Le fait que le web soit un système fortement réparti affecte les contraintes et les suppositions liées à l'architecture au sujet des interactions.
Les agents peuvent utiliser un URI pour accéder à la ressource référencée. C'est le concept de déréférencement d'URI. L'accès peut prendre diverses formes, comme l'obtention d'une représentation de la ressource (par exemple, en utilisant un GET ou un HEAD HTTP), l'ajout ou la modification une représentation de la ressource (par exemple, en utilisant un POST ou un PUT HTTP, qui dans certains cas peut changer l'état réel de la ressource si les représentations soumises sont interprétées comme étant des instructions destinées à cet effet) et la suppression d'une partie ou de toutes les représentations de la ressource (par exemple, via un DELETE HTTP, qui dans certains cas peut avoir comme conséquence la suppression de la ressource elle-même).
A partir d'un URI donné, il peut y avoir plusieurs façons d'accéder à une ressource. Le contexte de l'application détermine la méthode d'accès utilisée par un agent. Par exemple, un navigateur peut se servir d'un GET HTTP pour obtenir une représentation d'une ressource, tandis qu'un contrôleur de liens hypertextes pourrait utiliser un HEAD HTTP pour le même URI, dans le simple but de déterminer si une représentation est disponible. Certains schémas d'URI ont des exigences à propos des méthodes d'accès disponibles, d'autres n'en ont pas (tel que le schéma d'URN [RFC 2141]). La section 1.2.2 du document [URI] aborde, plus en détail, la séparation entre identification et interaction. Pour plus d'informations sur les relations entre les méthodes d'accès multiples et la possibilité d'adressage des URI, reportez-vous aux conclusions du TAG "URI, la possibilité d'adressage et l'utilisation du GET et du POST HTTP [URIs, Addressability, and the use of HTTP GET and POST]".
Bien que de nombreux schémas d'URI (§2.4) soient baptisés du nom des protocoles, l'utilisation d'un URI donné n'implique pas nécessairement l'accès à la ressource par l'intermédiaire du protocole nommé. Même lorsqu'un agent emploie un URI pour obtenir une représentation, cet accès peut se faire par l'intermédiaire de passerelles, de proxies, de zones de cache et de services de résolution de noms qui sont indépendants du protocole lié au schéma en question.
Beaucoup de schémas d'URI définissent un protocole par défaut pour tenter d'accéder à la ressource identifiée. Ce protocole d'interaction sert souvent de base pour attribuer des identifiants appartenant au schéma, comme les URI de "HTTP" sont définis en termes de serveurs HTTP basés sur TCP. Cependant, cela n'implique pas que chaque interaction avec de telles ressources est limitée au protocole d'interaction par défaut. Par exemple, les systèmes de récupération d'informations se servent souvent des proxies pour interagir avec une multitude de schémas d'URI. En effet, l'utilisation de proxies HTTP permet d'accéder à des ressources "ftp" et "wais". Ces proxies peuvent également fournir des services étendus, à l'image des proxies d'annotation. Ceux-ci combinent l'obtention classique d'information avec une récupération complémentaire de métadonnées afin de fournir une vue parfaite et multidimensionnelle des ressources qui utilisent les mêmes protocoles et les mêmes agents utilisateur que le web non annoté. De même, de futurs protocoles pourront être définis et engloberont nos systèmes actuels, utilisant des mécanismes d'interaction totalement différents, mais sans pour autant changer les schémas existants des identifiants. Voir également le principe des spécifications orthogonales (§5.1).
Déréférencer un URI implique généralement une succession d'étapes qui sont décrites dans de multiples spécifications et mises en oeuvre par les agents. L'exemple suivant illustre la série de spécifications qui régit le processus à suivre lorsqu'un agent utilisateur doit suivre un lien hypertexte (§4.4) faisant partie d'un document SVG. Dans cet exemple, l'URI est "http://weather.example.com/oaxaca" et le contexte d'application demande à l'agent utilisateur d'obtenir et d'afficher une représentation de la ressource identifiée.
- L'URI faisant partie d'un lien hypertexte dans un document SVG, la recommandation SVG 1.1 [SVG11] est la première spécification appropriée. La section 17.1 de cette spécification importe la sémantique du lien définie dans XLink 1.0 [XLink10] : "La ressource distante (la destination du lien) est définie par un URI spécifié par l'attribut XLink
href sur l'élément 'a'". La spécification de SVG va plus loin en déclarant que l'interprétation d'un élément a implique d'obtenir une représentation d'une ressource, identifiée par l'attribut href appartenant à l'espace de noms XLink : "En activant ces liens (en cliquant avec la souris, par une saisie clavier, une commande vocale, etc...), les utilisateurs peuvent visiter ces ressources."
- La spécification XLink 1.0 [XLink10], qui définit l'attribut
href dans la section 5.4, déclare que "La valeur de l'attribut href doit être une référence d'URI, comme défini dans le document [IETF RFC 2396], ou encore doit aboutir à une référence d'URI après que le processus d'échappement [ndt. escaping procedure] ci-dessous a été appliquée. La procédure s'applique lors du passage de la référence d'URI à un résolveur d'URI."
- La spécification d'URI [URI] annonce que "chaque URI commence par un nom de schéma qui se réfère à une spécification pour assigner des identifiants suivant ce schéma". Le nom de schéma d'URI, dans cet exemple, est "http".
- [IANASchemes] spécifie que le schéma "http" est défini par la spécification HTTP/1.1 (RFC 2616 [RFC2616], section 3.2.2).
- Dans ce contexte SVG, l'agent construit une requête HTTP GET (en se basant sur la section 9.3 de la [RFC2616]) pour obtenir la représentation.
- La section 6 de la [RFC2616] définit comment le serveur construit le message de réponse correspondant, y compris en ce qui concerne le champ 'Content-Type'.
- La section 1.4 de la [RFC2616] stipule que la "communication HTTP a lieu habituellement au-dessus des connexions TCP/IP". Cet exemple n'aborde ni cette étape du processus ni d'autres étapes telles que la résolution du DNS (Domain Name System).
- L'agent interprète la représentation retournée selon la spécification en corrélation avec le format de données, correspondant au type de média Internet de la représentation (§3.2) (la valeur du champ HTTP 'Content-Type') du registre IANA approprié [MEDIATYPEREG].
Dire avec précision la(les) représentation(s) obtenue(s) dépend d'un certain nombre de facteurs, en particulier :
- Si le propriétaire de l'URI rend disponibles toutes les représentations,
- Si l'agent, formulant la requête, possède les privilèges d'accès pour ces représentations (voir la section sur les liens et contrôle d'accès (§3.5.2)),
- Si le propriétaire de l'URI a fourni plus d'une représentation (dans différents formats tels que HTML, PNG ou RDF, dans différentes langues comme l'anglais et l'espagnol, ou si elle est issue d'une transformation dynamique selon les capacités matérielles ou logicielles du destinataire), la représentation résultante peut dépendre d'une négociation entre l'agent utilisateur et le serveur.
- La période de la demande ; le monde évolue à travers le temps, les représentations des ressources sont également susceptibles de changer dans le temps.
En supposant qu'une représentation a été récupérée avec succès, la puissance expressive du format de la représentation affectera la précision avec laquelle le fournisseur de représentation communique l'état de la ressource. Si la représentation communique l'état de la ressource de façon inexacte, cette inexactitude ou cette ambiguïté peut mener à une confusion pour les utilisateurs, à propos de ce qu'est vraiment la ressource. Si les différents utilisateurs aboutissent à des conclusions différentes à son sujet, ils peuvent alors l'interpréter comme une collision d'URI (§2.2.1). Certaines communautés, comme celle qui développe le web sémantique, cherchent à fournir un framework pour communiquer la sémantique exacte d'une ressource et ce d'une manière compréhensible par une machine. La sémantique compréhensible par une machine peut lever une partie de l'ambiguïté liée à la description des ressources en langage naturel.
Une représentation est une donnée qui encode l'information décrivant l'état d'une ressource. Les représentations ne décrivent pas nécessairement la ressource. Elles ne dépeignent pas forcement une image de la ressource ou ne représentent pas nécessairement la ressource dans des sens différents de celui du mot "représente".
Les représentations d'une ressource peuvent être envoyées ou reçues en utilisant des protocoles d'interaction. Ces protocoles déterminent à leur tour sous quelle forme les représentations sont véhiculées sur le Web. HTTP, par exemple, prévoit de transmettre des représentations comme des flux d'octets, en les typant avec des types de média Internet [RFC2046].
De la même manière qu'il est important de réutiliser les schémas d'URI existants chaque fois que possible, il y a des avantages significatifs à se servir de flux d'octets typés pour des représentations, même dans le cas peu courant de la définition d'un nouveau schéma d'URI et du protocole associé. Par exemple, si le temps d'Oaxaca arrivait au navigateur de Nadia par le biais d'un protocole différent de HTTP, alors le logiciel responsable de l'affichage des formats tels que text/xhmtl+xml et image/png serait toujours utilisable dans la mesure où le nouveau protocole prendrait en compte la transmission de ces types. C'est un exemple du principe des spécifications orthogonales (§5.1).
Bonne pratique : Réutiliser les formats de représentation
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.
Le mécanisme de type de média Internet a quelques limites. Par exemple, le type de média, chaîne de caractères, ne supporte ni les paramètres liés à la gestion des versions (§4.2.1) ni les autres paramètres. Voir les discussions du TAG à ce sujet : uriMediaType-9 et mediaTypeManagement-45 qui concernent des aspects de ce mécanisme.
Le type de média Internet définit la syntaxe et la sémantique de l'identifiant de fragment (introduit dans Identifiants de fragment (§2.6)). Il peut, le cas échéant, être utilisé en conjonction d'une représentation.
Scénario
Dans une de ses pages XHTML, Dirk crée un lien hypertexte vers une image que Nadia a publiée sur le Web. Il le crée en écrivant <a
href="http://www.example.com/images/nadia#hat">La chapeau de Nadia</a>. Emma regarde la page XHTML de Dirk dans son navigateur web et suit le lien. La mise en oeuvre HTML de son navigateur supprime le fragment de l'URI puis demande l'image "http://www.example.com/images/nadia". Nadia fournit une représentation SVG de l'image (avec le type de média Internet "image/svg+xml"). Le navigateur Web d'Emma démarre alors la mise en oeuvre SVG afin de voir l'image. Il lui passe l'URI original, comprenant le fragment, "http://www.example.com/images/nadia#hat", permettant ainsi de ne voir que le chapeau et non l'image complète.
Notez que la mise en oeuvre HTML du navigateur d'Emma n'a pas eu besoin de comprendre la syntaxe ou la sémantique du fragment SVG (et inversement, l'outil SVG n'a pas besoin de comprendre la syntaxe de fragment ou la sémantique HTML, WebCGM, RDF... ; il lui suffit de reconnaître le délimiteur # de la syntaxe d'URI [ URI ] et d'enlever le fragment pour accéder à la ressource). Cette orthogonalité (§5.1) est un fonctionnalité importante de l'architecture du Web. En effet, c'est ce qui permet au navigateur d'Emma de fournir un service utile sans pour autant exiger une mise à jour.
La sémantique d'un identifiant de fragment est définie par l'ensemble des représentations qui pourraient résulter d'une action de récupération de la ressource primaire. Le format et la résolution du fragment dépendent donc du type de la représentation potentiellement obtenue, même si une telle récupération n'est seulement effectuée que si l'URI est déréférencé. Si aucune représentation n'existe, alors la sémantique du fragment est considérée comme inconnue et, de fait, sans contrainte. La sémantique de l'identifiant de fragment est orthogonale au schéma d'URI et ne peut pas être redéfinie ainsi par une spécification de schéma d'URI.
L'interprétation de l'identifiant de fragment est seulement effectuée par l'agent qui déréférence un URI ; l'identifiant de fragment n'est pas passé à d'autres systèmes pendant le processus de récupération. Cela signifie que certains intermédiaires dans l'architecture du web (comme les proxies) n'ont aucune interaction avec les identifiants de fragment et que les redirections (dans HTTP [RFC2616] par exemple) ne s'appliquent pas aux fragments.
La négociation de contenu consiste à fournir de multiples représentations par l'intermédiaire d'un même URI. La négociation, entre l'agent émetteur de la requête et le serveur, détermine quelle représentation est servie (habituellement avec pour objectif de servir la "meilleure" représentation pouvant être traitée par un agent la recevant). HTTP est un exemple de protocole qui permet à des fournisseurs de représentation d'utiliser la négociation de contenu.
Les différents formats de données peuvent définir leurs propres règles pour l'usage de la syntaxe de l'identifiant de fragment afin de spécifier différents types de sous-ensembles, de vues ou de références externes qui sont identifiables, par ce type de média, en tant que ressources secondaires. Par conséquent, les fournisseurs de représentations doivent contrôler soigneusement la négociation de contenu lorsqu'elle est utilisée avec un URI qui contient un identifiant de fragment. Considérons un exemple dans lequel le propriétaire de l'URI "http://weather.example.com/oaxaca/map#zicatela" emploie la négociation de contenu pour délivrer deux représentations de la ressource identifiée. Trois cas sont possibles :
- L'interprétation de "zicatela" est définie de façon consistante par les spécifications des deux formats de données. Le fournisseur de la représentation décide quand les définitions de la sémantique de l'identifiant de fragment sont suffisamment cohérentes.
- L'interprétation de "zicatela" est définie de façon inconsistante par les spécifications des formats de données.
- L'interprétation de "zicatela" est définie dans une spécification de format de données mais pas dans l'autre.
La première situation (où la sémantique est consistante) ne pose aucun problème.
Le deuxième cas est une erreur de gestion du serveur : les fournisseurs de représentations ne doivent pas utiliser la négociation de contenu pour servir des formats de représentation dont la sémantique de l'identifiant de fragment est inconsistant. Cette situation conduit également à une collision d'URI (§2.2.1).
Le troisième cas n'est pas une erreur de gestion du serveur. C'est un moyen pour le Web de se développer. Puisque le Web est un système réparti dans lequel des formats et des agents sont déployés d'une façon non-uniforme, l'architecture du web ne contraint pas les auteurs à utiliser que des formats "ayant le plus petit dénominateur commun". Les auteurs de contenu peuvent tirer profit de nouveaux formats de données tout en s'assurant toujours d'une compatibilité ascendante raisonnable pour les agents qui ne les mettent pas encore en oeuvre.
Dans le troisième cas, le comportement de l'agent réceptionnant peut changer en fonction de la définition éventuelle, par le format négocié, de la sémantique de l'identifiant de fragment. Quand un format de données reçu ne définit pas cette sémantique, l'agent ne devrait pas passer sous silence la reprise sur erreur à moins que l'utilisateur ait donné son consentement ; voir [CUAP] pour la suggestion de comportements complémentaires de l'agent dans ce cas précis.
Voir les discussions associées du TAG, RDFinXHTML-35.
Une communication réussie entre deux parties dépend d'une compréhension raisonnablement partagée de la sémantique des messages échangés, non seulement au niveau des données mais également au niveau des métadonnées. Parfois, il peut y avoir des contradictions entre les données et les métadonnées d'un expéditeur de message. Voici des exemples, observés dans la pratique, de ce type d'inconsistance sont :
- L'encodage réel des caractères d'une représentation (par exemple, "iso-8859-1", spécifié par l'attribut
encoding dans une déclaration XML) est contradictoire avec le paramètre du jeu de caractères présent dans les métadonnées de la représentation (par exemple, "utf-8", indiqué par le champ "Content-Type" dans un en-tête HTTP).
- L'espace de noms (§4.5.3) de l'élément racine des données XML d'une représentation (par exemple, celui spécifié par l'attribut "xmlns") est contradictoire avec la valeur du champ "Content-Type" dans un en-tête HTTP.
D'un autre côté, il n'y a aucune contradiction à servir un contenu HTML en ayant un type de média "text/plain", par exemple, car cette combinaison est autorisée par les spécifications.
Les agents récepteurs devraient détecter les inconsistances liées au protocole et gérer une reprise sur erreur appropriée.
Contrainte: Inconsistance des données/métadonnées
Les agents NE DOIVENT PAS ignorer les métadonnées des messages sans le consentement de l'utilisateur.
Ainsi, par exemple, si les responsables du site "weather.example.com" marquent de manière erronée la photo satellite d'Oaxaca avec le type "image/gif" au lieu de "image/jpeg" et si le navigateur de Nadia détecte un problème, il ne doit pas l'ignorer (en affichant simplement l'image JPEG par exemple) sans le consentement de Nadia. Le navigateur de Nadia peut l'informer du problème ou peut non seulement l'en informer mais aussi prendre une mesure corrective.
En outre, les fournisseurs de représentation peuvent aider à réduire le risque d'inconsistance en attribuant soigneusement les métadonnées de la représentation (en particulier celles qui s'appliquent à plusieurs représentations). La section sur les types de média pour XML (§4.5.7) présente un exemple permettant de réduire le risque d'erreur, en ne fournissant aucune métadonnée concernant l'encodage de caractères lorsqu'il s'agit de délivrer du XML.
L'exactitude des métadonnées repose sur les administrateurs du serveur, les auteurs des représentations et le logiciel qu'ils utilisent. En pratique, les possibilités des outils et les relations sociales peuvent être des facteurs limitants.
L'exactitude de ces dernières et des autres champs de métadonnées est aussi importante pour les ressources dynamiques du Web, où un peu de réflexion et de programmation peuvent souvent assurer des métadonnées correctes pour un grand nombre de ressources.
Il y a souvent une séparation de contrôle entre les utilisateurs qui créent des représentations de ressources et les gestionnaires de serveur qui maintiennent le logiciel du site Web. Ceci étant dit, le logiciel du site web est généralement à l'origine des métadonnées qui sont associées à une ressource. Il en résulte qu'une coordination entre les gestionnaires de serveur et les créateurs de contenu est nécessaire.
Bonne pratique : Association de métadonnées
Les gestionnaires de serveur DEVRAIENT permettre aux créateurs de représentation de contrôler les métadonnées liées à leurs représentations.
En particulier, les créateurs de contenu doivent pouvoir définir le type de contenu (pour l'extensibilité) et l'encodage des caractères (pour une internationalisation appropriée).
Les conclusions du TAG, "métadonnées qui font autorité [Authoritative Metadata]", abordent plus en détail la façon de traiter la consistance données/métadonnées et la façon dont la configuration d'un serveur peut être employée pour l'éviter.
L'obtention par Nadia d'informations sur le temps (un exemple de requête en lecture seule ou d'une recherche) est qualifiée d'interaction sûre. Une interaction sûre implique que l'agent ne provoque aucune obligation en dehors de l'interaction. Un agent peut provoquer des obligations par d'autres moyens (comme par la signature d'un contrat). Si un agent n'a pas d'engagement avant une interaction sûre, il ne doit pas en avoir après.
D'autres interactions web ressemblent plus à des ordres qu'à des questions. Ces interactions non sûres peuvent induire un changement d'état d'une ressource et l'utilisateur peut être jugé responsable des conséquences de ces interactions. Les interactions non sûres incluent la souscription à un lettre d'actualité, l'envoi de message à une liste ou la modification d'une base de données. Note : Dans ce contexte, le mot "non sûr" ne signifie pas nécessairement "dangereux". Le terme "sûr" est employé dans la section 9.1.1 de la [RFC2616] et le terme "non sûr" constitue son opposé naturel.
Scénario
Nadia décide de réserver des vacances à Oaxaca via "booking.example.com". Elle saisit des données dans une série de formulaires en ligne et finalement les informations relatives à sa carte de crédit lui sont demandées, pour pouvoir acheter les billets d'avion. Elle les fournit dans un autre formulaire. Quand elle appuie sur le bouton "acheter", son navigateur ouvre une autre connexion réseau au serveur "booking.example.com" et envoie, en utilisant la méthode POST, un message avec des données issues du formulaire. C'est une interaction non sûre. Nadia souhaite changer l'état du système en échangeant de l'argent contre des billets d'avion.
Le serveur lit la requête POST et, après l'exécution de la transaction de réservation, renvoie un message au navigateur de Nadia qui contient une représentation des résultats de sa demande. Les données de la représentation sont en XHTML de sorte que Nadia puisse les sauver ou les imprimer.
Notez que ni les données transmises par POST, ni les données reçues dans la réponse ne correspondent nécessairement à une ressource identifiée par un URI.
Les interactions sûres sont importantes parce que ce sont des interactions parmi lesquelles les utilisateurs peuvent naviguer en toute confiance et où les agents (en incluant les moteurs de recherche et les navigateurs qui mettent en cache des données pour l'utilisateur) peuvent suivre des liens hypertextes sans risque. Les utilisateurs (ou les agents agissant en leur nom) ne s'engagent à rien en demandant une ressource ou en suivant un lien hypertexte.
Principe: Récupération sûre
Les agents ne s'engagent pas en récupérant une représentation.
Par exemple, il est incorrect de publier un URI qui contient des informations (une partie de l'URI) permettant d'inscrire un utilisateur à une liste de discussions. Rappelez-vous que les moteurs de recherche peuvent suivre de tels liens hypertextes.
Le fait qu'un GET HTTP, la méthode d'accès la plus souvent utilisée pour suivre un lien hypertexte, soit sûre n'implique pas que toutes les interactions sûres doivent être faites via des GET HTTP. Parfois, il peut y avoir de bonnes raisons (comme pour des besoins de confidentialité ou des limites pratiques quant à la longueur des URI) de mener une opération sûre, par un autre moyen, en utilisant un mécanisme généralement réservé aux opérations non sûres (par exemple, un POST HTTP).
Pour plus d'informations sur les opérations sûres et non sûres employant les méthodes GET et POST de HTTP ainsi que sur les aspects de traitement de la sécurité liés à l'utilisation du GET HTTP, reportez-vous aux conclusions du TAG : "URI, possibilité d'adressage et utilisation des commandes HTTP GET et POST [URIs, Addressability, and the use of HTTP GET and POST]".
Scénario
Nadia paie ses billets d'avion en ligne (par une interaction POST comme décrit ci-dessus). Elle reçoit une page web avec l'information de confirmation et souhaite la mettre dans ses favoris de sorte qu'elle puisse s'y référer quand elle calculera ses dépenses. Bien que Nadia puisse imprimer ces résultats ou encore les sauvegarder dans un fichier, elle voudrait également pouvoir les conserver en tant que favori.
Les requêtes et les résultats de transaction sont des ressources à valeur ajoutée et comme toutes les ressources de ce type, il est utile de pouvoir s'y rapporter à l'aide d'un URI persistant (§3.5.1). Cependant, dans la pratique, Nadia ne peut pas conserver sa confirmation de paiement (exprimée par l'intermédiaire d'une requête POST) ni la confirmation de la compagnie aérienne ni même l'engagement qu'une place lui est réservée (exprimé par l'intermédiaire de la réponse au POST).
Il existe des solutions pour fournir des URI persistants pour des requêtes de transaction et pour leurs résultats. Pour les requêtes, les agents utilisateur peuvent fournir une interface de gestion des transactions où l'agent utilisateur s'est engagé au nom de l'utilisateur. Pour les résultats de transaction, HTTP permet aux fournisseurs de représentation d'associer un URI aux résultats d'une requête POST HTTP en utilisant l'en-tête de "Content-Location" (décrit dans section 14.14 de la [RFC2616]).
Scénario
Comme Nadia trouve le site indiquant le temps d'Oaxaca utile, elle envoie son point de vue, par courrier électronique, à son ami Dirk en lui recommandant de regarder 'http://weather.example.com/oaxaca'. Dirk clique sur le lien hypertexte apparaissant dans le courriel qu'il reçoit mais une erreur 404 (non trouvé) le frustre. Dirk essaie de nouveau le jour suivant et reçoit une représentation avec des "nouvelles" vieilles de deux semaines. Il essaie une fois de plus le jour suivant et obtient une représentation clamant que le temps à Oaxaca est ensoleillé, alors que ses amis y habitant lui disent par téléphone, qu'en fait, il pleut. Dirk et Nadia concluent que les propriétaires de l'URI ne sont pas fiables ou sont imprévisibles. Bien que le propriétaire de cet URI ait choisi le web comme moyen de communication, il vient de perdre deux clients à cause d'une gestion inefficace de ses représentations.
Un propriétaire d'URI peut fournir aucune ou plusieurs représentations officielles de la ressource identifiée par cet URI. Fournir des représentations bénéficie cependant à la communauté.
Bonne pratique : Disponibilité des représentations
Un propriétaire d'URI DEVRAIT fournir des représentations de la ressource qu'il identifie.
Par exemple, les propriétaires des URI d'espace de noms XML devraient les utiliser pour identifier un document d'espace de noms (§4.5.4).
La disponilité de représentations ne signifie pas qu'il est toujours souhaitable de les récupérer. En fait, dans certains cas, c'est l'inverse.
Principe: La référence n'implique pas la déréférence
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.
Déréférencer un URI induit un coût (potentiellement significatif) au niveau des ressources informatiques et de la bande passante. Cela peut avoir des implications du point de vue de la sécurité et peut imposer une latence significative à l'application qui déréférence. Les URI déréférencés devraient être évités sauf lorsqu'ils sont nécessaires.
Les sections suivantes abordent quelques aspects de la gestion des représentations, comme la promotion de la persistance d'URI (§3.5.1), la gestion de l'accès aux ressources (§3.5.2) et le support de la navigation (§3.5.3).
Comme c'est le cas pour beaucoup d'interactions humaines, la confiance dans les interactions via le web dépend de la stabilité et de la prévisibilité. Pour une ressource d'information, la persistance dépend de la consistance des représentations. Le fournisseur de représentations décide lorsqu'elles sont suffisamment consistantes (même si cette détermination tient compte généralement des attentes des utilisateurs).
Bien que l'on puisse dans ce cas observer la persistance comme le résultat de l'obtention d'une représentation, le terme persistance d'URI est utilisé pour décrire une propriété vraiment souhaitable : un URI, une fois associé à une ressource, devrait continuer indéfiniment à se référer à cette ressource.
Bonne pratique : Représentation consistante
Un propriétaire d'URI DEVRAIT fournir des représentations consistantes et prédictibles de la ressource identifiée.
La persistance d'URI est une question de politique et d'engagement de la part du propriétaire d'URI. Le choix d'un schéma particulier d'URI ne garantit pas que ces URI seront persistants ou qu'ils ne le seront pas.
HTTP [RFC2616] a été conçu pour aider au contrôle de la persistance d'URI. Par exemple, la redirection HTTP (utilisant les codes de réponse 3xx) permet à des serveurs d'indiquer à un agent qu'il doit prendre d'autres mesures pour finaliser la requête (par exemple, un nouvel URI est associé à la ressource).
En outre, la négociation de contenu favorise également la consistance, car un gestionnaire de site n'est pas dans l'obligation de définir de nouveaux URI lorsqu'il ajoute le support d'une nouvelle spécification de format. Les protocoles, qui ne prennent pas en compte la négociation de contenu (tel que FTP), exigent un nouvel identifiant lors de l'introduction d'un nouveau format de données. La mauvaise utilisation de la négociation de contenu peut aboutir à des représentations inconsistantes.
Le document [Cool] présente davantage d'échanges au sujet de la persistance d'URI.
Il est raisonnable de limiter l'accès à une ressource (pour des raisons commerciales ou de sécurité, par exemple). Mais, l'identification d'une ressource se rapproche simplement de celle d'un livre par son titre. Dans des circonstances exceptionnelles, les personnes peuvent s'entendrent pour maintenir des titres ou des URI confidentiels (par exemple, un auteur de livre et un éditeur peuvent se mettre d'accord pour garder secret l'URI de la page, contenant des informations complémentaires, jusqu'à l'édition du livre). Dans le cas contraire, ces titres et ces URI sont librement échangeables.
Voici une analogie : Les propriétaires d'un bâtiment pourraient avoir une politique stipulant que le public ne peut entrer dans le bâtiment que par l'intermédiaire de la porte principale et seulement pendant les heures de bureau. Ceux qui travaillent dans le bâtiment et qui effectuent des livraisons pourraient se servir d'autres portes plus appropriées. Une telle politique serait renforcée par une sécurité effectuée par le personnel ainsi que par des dispositifs mécaniques tels que des serrures et des passages contrôlés par des cartes d'accès. Mettre en place cette politique ne requiert pas de cacher certaines entrées du bâtiment, ni de demander à la législation l'utilisation obligatoire de la porte principale et d'interdir toute autre porte d'accès au bâtiment.
Scénario
Nadia envoie à Dirk l'URI de l'article qu'elle est en train de lire. Avec son navigateur, Dirk suit le lien hypertexte et est invité à s'identifier en saisissant son nom d'utilisateur et son mot de passe. Dirk étant également un abonné des services fournis par "weather.example.com", il peut accéder aux mêmes informations que Nadia. Ainsi, l'autorité contrôlant "weather.example.com" peut limiter l'accès aux personnes autorisées et continuer à fournir les avantages des URI.
Le web fournit plusieurs mécanismes pour contrôler l'accès aux ressources ; ces mécanismes ne se basent pas sur le masquage ou la suppression des URI de ces ressources. Pour plus d'informations, voir les conclusions du TAG "Lien en profondeur dans le World Wide Web ["Deep Linking" in the World Wide Web]".
La possibilité de faire et de partager des liens est une force de l'architecture du Web. Un utilisateur, qui a trouvé une partie intéressante du Web, peut partager cette expérience simplement en republiant un URI.
Scénario
Nadia et Dirk veulent visiter le musée des prévisions météorologiques dans Oaxaca. Nadia se rend sur "http://maps.example.com", localise le musée et expédie par courriel l'URI "http://maps.example.com/oaxaca?lat=17.065;lon=-96.716;scale=6" à Dirk. Dirk se rend sur "http://mymaps.example.com", localise le musée et envoie, par courriel également, l'URI "http://mymaps.example.com/geo?sessionID=765345;userID=Dirk" à Nadia. Dirk lit le message de Nadia et peut suivre le lien vers la carte. Nadia lit celui de Dirk, suit le lien mais reçoit un message d'erreur 'session/utilisateur inexistant'. Nadia doit recommencer à partir de "http://mymaps.example.com" et trouver l'emplacement du musée une fois de plus.
Pour les ressources qui sont produites à la demande, la génération des URI par la machine est simple. Par contre, les gestionnaires de serveur devraient éviter de limiter inutilement la réutilisabilité des URI de ressources qu'il pourrait être utile de garder dans des signets pour une lecture postérieure ou utile de partager avec d'autres. Si l'intention est de limiter l'information à un utilisateur particulier, comme par exemple dans le cas d'une application d'opérations bancaires pour les particuliers, les concepteurs devraient employer les mécanismes appropriés du contrôle d'accès (§3.5.2).
Les interactions à base de POST HTTP (où le GET HTTP aurait pu être utilisé) limitent également les possibilités de navigation. L'utilisateur ne peut pas créer de signet ou partager l'URI car, les transactions ne fournissent pas d'URI différents de celui utilisé par l'utilisateur pour interagir avec le site.
Certaines questions concernant les interactions du web restent en suspens. Le TAG prévoit que les futures versions de ce document aborderont plus en détail les relations entre l'architecture décrite ci-dessus, les services Web, les systèmes point-à-point, les systèmes de messagerie instantanée (comme [RFC3920]), la lecture de flux audio (telle que RTSP [RFC2326]) et la voix sur IP (tel que SIP [RFC3261]).
Une spécification de format de données (par exemple, pour XHTML, RDF/XML, SMIL, XLink, CSS et PNG) est l'incarnation d'un accord sur l'interprétation correcte des données de représentation. Le premier format de données utilisé sur le web était HTML. Depuis, les formats de données se sont multipliés. L'architecture du web ne contraint pas les fournisseurs de contenu sur la nature des formats qu'ils peuvent employer. Cette flexibilité est importante car il existe une évolution constante dans les applications, ce qui implique de nouveaux formats de données et l'amélioration des formats existants. Bien que l'architecture du web tienne compte du déploiement de nouveaux formats de données, leur création (ainsi que celle des agents capables de les manipuler) est coûteuse. Avant d'inventer un nouveau format de données (ou un format "méta" tel que XML), les concepteurs devraient donc soigneusement considérer la réutilisation de ce qui est déjà disponible.
Pour qu'un format de données soit interopérable de façon utile entre deux parties, ces parties doivent s'accorder (jusqu'à un degré raisonnable) au sujet de sa syntaxe et de sa sémantique. La compréhension mutuelle d'un format de données favorise l'interopérabilité mais n'implique pas de contraintes sur l'utilisation. Par exemple, un expéditeur de données ne peut pas compter sur le fait de pouvoir contraindre le comportement d'un récepteur de ces données.
Nous décrivons, ci-dessous, certaines caractéristiques d'un format de données qui facilitent l'intégration dans l'architecture du Web. Ce document ne se préoccupe pas des avantages généraux d'une spécification tels que la lisibilité, la simplicité, la considération des objectifs du programmeur, la considération des besoins de l'utilisateur, l'accessibilité, ni l'internationalisation. La section sur les spécifications liées à l'architecture (§7.1) inclut des références à des directives complémentaires pour la spécification de format.
Les formats de données binaires sont ceux dans lesquels des parties de données sont codées pour un usage direct par un processeur d'ordinateur, comme par exemple les représentations petit-boutistes 32 bits à complément à deux [ndt. Little-endian] et les nombres IEEE, sur 64 bits, à virgule flottante en double précision. Les parties de données ainsi représentées incluent des valeurs numériques, des pointeurs et des données compressées de toutes sortes.
Dans un format de données textuel, les données sont spécifiées comme étant une séquence de caractères dans un encodage défini. Le HTML, les courriels Internet et tous les formats de données basés sur XML (§4.5) sont des formats textuels. De plus en plus, ces formats internationalisés se réfèrent au répertoire Unicode [UNICODE] pour la définition de caractères.
Le fait qu'un format de données soit textuel, tel qu'il est défini dans cette section, n'implique pas qu'il doive être servi avec un type de média commençant par "text/". Même si les formats basés sur XML sont textuels, beaucoup d'entre eux ne consistent pas en des expressions en langage naturel. Voir la section sur les types de média pour XML (§4.5.7) qui aborde les problèmes surgissant lorsque "text/" est utilisé en conjonction avec un format basé sur XML.
En principe, toutes les données peuvent être représentées en utilisant des formats textuels. Dans la pratique, quelques types de contenu (par exemple, l'audio et la vidéo) sont généralement représentés en utilisant des formats binaires.
Les différences entre les formats de données binaires et textuels sont complexes et dépendantes des applications. Les formats binaires peuvent être substantiellement plus compacts, en particulier pour les structures de données complexes, riches en pointeurs. En outre, ils peuvent être consommés plus rapidement par les agents puisqu'ils peuvent être chargés en mémoire et employés avec peu ou pas de conversion. Notons, cependant, que de tels cas sont relativement rares car ce type d'utilisation directe peut ouvrir la porte à des problèmes de sécurité solubles, de façon pratique, qu'en examinant en détail chaque aspect de la structure de données.
Les formats textuels sont habituellement plus portables et interopérables. Ils ont également l'avantage considérable de pouvoir être directement lus par les êtres humains (et même compris grâce à une documentation suffisante). Cela peut simplifier les tâches de création et de maintenance du logiciel et permettre une intervention humaine directe dans la chaîne de traitements, sans besoin d'avoir recours à des outils plus complexes qu'un simple éditeur de texte. Enfin, ils simplifient la tâche, nécessaire à chaque personne, d'apprentissage de nouveaux formats de données. On appelle ça l'effet "voir la source".
Il est important de souligner que les idées préconçues quant à la taille des données et la vitesse de traitement n'est pas un guide fiable dans la conception de format de données. Les études quantitatives sont essentielles pour une meilleure compréhension des différences. Par conséquent, les concepteurs de spécification de format de données devraient faire un choix considéré entre la conception d'un format binaire et celle d'un format textuel.
Voir les discussions du TAG à propos de binaryXML-30.
Dans un monde parfait, les langages seraient conçus de façon à répondre parfaitement aux besoins exprimés, ces besoins représenteraient un modèle parfait du monde, ils ne changeraient jamais au fil du temps et toutes les mises en oeuvre seraient parfaitement interopérables car les spécifications ne seraient sujet à aucune variabilité.
Dans le monde réel, les concepteurs répondent de façon imparfaite aux besoins, car ils les interprètent. Ces besoins modélisent le monde de façon inexacte. Qui plus est, certains besoins sont contradictoires et changent avec le temps. Par conséquent, les concepteurs négocient avec les utilisateurs, font des compromis et introduisent souvent des mécanismes d'extensibilité afin de pouvoir contourner les problèmes à court terme. À long terme, ils produisent de multiples versions de leur langage, à mesure que le problème et leur compréhension du problème évoluent. La variabilité induite dans les spécifications, les langages et les mises en oeuvre introduisent des coûts d'interopérabilité.
L'extensibilité et la gestion des versions sont des stratégies permettant d'aider à contrôler l'évolution naturelle de l'information sur le web et des technologies utilisées pour la représenter. Pour plus d'informations sur la façon dont ces stratégies introduisent de la variabilité et la façon dont cette variabilité a des impacts sur l'interopérabilité, voir Variabilité dans les spécifications [Variability in Specifications].
Voir les discussions du TAG XMLVersioning-41, qui concernent les bonnes
pratiques pour concevoir des langages XML extensibles et pour gérer les versions. Voir également l'"Architecture du Web : langages extensibles" [EXTLANG].
Il y a typiquement une (longue) période de transition durant laquelle de multiples versions d'un format, d'un protocole ou d'un agent sont simultanément en service.
Bonne pratique : Information à propos des versions
Une spécification de format de données DEVRAIT fournir des informations relatives à la version.
Scénario
Nadia et Dirk conçoivent un format de données XML pour encoder des données au sujet de l'industrie du film. Ils fournissent une certaine extensibilité en utilisant des espaces de noms XML et en créant un schéma qui permet l'inclusion, dans certains endroits, d'éléments appartenant à d'autres espaces de noms. Quand ils mettent à jour leur format, Nadia propose un nouvel attribut facultatif, lang, sur l'élément film. Dirk estime qu'après un tel changement, ils se doivent d'assigner un nouvel espace de nom, qui pourrait demander des changements aux logiciels déployés. Nadia explique à Dirk que leur choix stratégique d'extensibilité associé à leur politique d'espace de noms autorise certains changements, qui n'affectent pas la conformité du contenu et des logiciels existants. Aucun changement de l'identifiant d'espace de noms n'est alors nécessaire. Le choix de cette politique doit les aider à atteindre leurs objectifs de réduction des coûts relatifs au changement.
Dirk et Nadia ont choisi une politique d'évolution de l'espace de noms qui leur permet d'éviter de le changer à chaque fois qu'ils font des modifications qui n'affectent pas la conformité du contenu et des logiciels déployés. Ils pourraient très bien avoir choisi une politique différente. Par exemple, tout nouvel élément ou attribut doit appartenir à un espace de noms différents de l'original. Quelque soit la politique choisie, elle doit fixer clairement les règles pour les utilisateurs du format.
En général, le changement de l'espace de noms d'un élément change totalement le nom d'élément. Si "a" et "b" sont associés à deux URI différents, a:element et b:element sont aussi distincts que a:eieio et a:xyzzy. Dans la pratique, cela signifie que les applications déployées devront être mises à jour afin de reconnaître ce nouveau langage. Le coût induit peut être très élevé.
Ce qui implique qu'il y a des compromis significatifs à considérer lors du choix de la politique d'évolution d'un espace de noms. Si un vocabulaire ne vise pas l'extensibilité (c'est-à-dire, s'il n'autorise pas des éléments ou des attributs provenant d'espaces de noms étrangers ou s'il ne possède pas de mécanisme pour traiter des noms inconnus appartenant au même espace de noms), il peut être absolument nécessaire de changer le nom d'espace de noms. Les langages qui permettent une certaine forme d'extensibilité sans exiger un changement de nom d'espace de noms sont plus simples à faire évoluer de façon élégante.
Bonne pratique : Politique d'espace de noms
Une spécification de format XML DEVRAIT inclure des informations sur la politique de changement concernant les espaces de noms XML.
A titre d'exemple de politique de changement conçue pour refléter la stabilité variable d'un espace de noms, considérons la politique d'espace de noms du W3C appliquée aux documents sur le chemin de la recommandation. La politique spécifie que le groupe de travail responsable de l'espace de noms peut le modifier à volonté jusqu'à un certain point dans le processus ("recommandation candidate"). À partir de ce point, le W3C contraint l'ensemble des changements possibles de l'espace de noms afin de promouvoir des mises en oeuvres stables.
Notez que, les noms d'espace de noms étant des URI, le propriétaire de l'URI d'un espace de noms possède l'autorité pour décider de la politique d'évolution de cet espace de noms.
Les besoins changent avec le temps. Les technologies qui ont du succès sont adoptées et adaptées par de nouveaux utilisateurs. Les concepteurs peuvent faciliter le processus de transition en étant attentifs aux choix concernant l'extensibilité faits lors de la conception d'une spécification d'un langage ou d'un protocole.
En faisant ces choix, les concepteurs doivent prendre la mesure des différences entre extensibilité, simplicité et variabilité. Un langage sans mécanismes permettant l'extension peut être plus simple et moins variable, améliorant ainsi l'interopérabilité initiale. Cependant, dans ce cas, il est probable que les changements à apporter à ce langage seront plus difficiles, plus complexes et plus variables. L'interopérabilité peut alors diminuer sur le long terme.
Bonne pratique : Mécanismes permettant l'extension
Une spécification DEVRAIT fournir des mécanismes qui permettent à n'importe quelle partie de créer des extensions.
L'extensibilité introduit de la variabilité qui a un impact sur l'interopérabilité. Cependant, les moyens ad hoc d'étendre des langages, qui n'ont aucun mécanisme d'extensibilité, affectent aussi l'interopérabilité. Un critère clé de ces mécanismes, fournis par les concepteurs de langage, est qu'ils permettent aux langages de rester en conformité avec la spécification originale, ce qui est un facteur d'accroissement probable de l'interopérabilité.
Bonne pratique : Conformité d'extensibilité
L'extensibilité NE DOIT PAS interférer dans la conformité à la spécification originale.
Les applications ont besoin de déterminer la stratégie d'extension la plus appropriée pour une spécification. Par exemple, les concepteurs d'applications, fonctionnant dans des environnements clos, peuvent s'autoriser la définition d'une stratégie de gestion des versions qui serait inapplicable à l'échelle du web.
Bonne pratique : Extensions inconnues
Une spécification DEVRAIT définir le comportement des agents face aux extensions non reconnues.
Deux stratégies ont émergé et sont particulièrement utiles :
- "doit ignorer" : L'agent ignore tout contenu qu'il ne reconnaît pas.
- "doit comprendre" : L'agent traite les balises inconnues comme des conditions d'erreur.
Une approche de conception performante pour un langage est de permettre l'une ou l'autre forme d'extension, mais de les distinguer explicitement au niveau de la syntaxe.
La demande à l'utilisateur d'informations additionnelles et la recherche automatique de données à partir de liens hypertextes disponibles représente des stratégies complémentaires. D'autres, plus complexes, sont également possibles, comme des stratégies mixtes. Par exemple, un langage peut inclure des mécanismes afin de surcharger le comportement standard. Ainsi, un format de données peut spécifier "doit ignorer" la sémantique mais également permettre des extensions qui redéfinissent cette sémantique selon les besoins de l'application (par exemple, avec "doit comprendre" la sémantique pour une extension particulière).
L'extensibilité n'est pas gratuite. Fournir des leviers pour l'extensibilité est l'un des nombreux besoins qui induit des coûts de conception d'un langage. L'expérience suggère que les avantages à long terme d'un mécanisme d'extensibilité bien pensé sont généralement supérieurs aux coûts.
Voir “D.3
Extensibilité et extensions [Extensibility and Extensions]” dans [QA].
De nombreux formats de données modernes incluent des mécanismes pour la composition. Par exemple :
- Il est possible d'inclure des commentaires textuels dans plusieurs formats d'image, tels que JPEG/JFIF. Bien que ces commentaires soient embarqués dans les données, ils ne sont pas destinés à affecter l'affichage de l'image.
- Il y a des formats de conteneur comme SOAP qui s'attendent à un contenu composé d'espaces de noms multiples mais qui fournissent une relation sémantique globale pour l'enveloppe de message et le contenu.
- La sémantique de documents RDF combinés, contenant de multiples vocabulaires, est bien définie.
En principe, ces relations peuvent être mélangées et imbriquées de façon arbitraire. Un message SOAP, par exemple, peut contenir une image SVG qui contient un commentaire RDF qui se rapporte à un vocabulaire de termes permettant de décrire l'image.
Il est cependant bon de noter, que pour un XML général, aucun modèle sémantique ne définit les interactions, dans les documents XML, entre les éléments et/ou les attributs appartenant à une multitude d'espaces de noms. Chaque application doit définir comment les espaces de noms interagissent entre eux et quel effet l'espace de nom d'un élément a sur les ancêtres, les frères et les descendants de l'élément.
Voir les discussions du TAG mixedUIXMLNamespace-33 (au sujet de la signification d'un document composé d'un contenu provenant d'espaces de noms multiples), xmlFunctions-34 (au sujet d'une approche pour contrôler la transformation et la possibilité de composer du XML) et RDFinXHTML-35 (au sujet de l'interprétation de RDF une fois qu'il est incorporé dans un document XHTML).
Le web est un environnement hétérogène où une grande variété d'agents permettent, à des utilisateurs, d'accéder à un contenu via de multiples possibilités. C'est une bonne habitude pour des auteurs de créer un contenu qui peut atteindre une audience la plus large possible, que les utilisateurs soient équipés d'ordinateurs de bureau, mais également de périphériques portables et de téléphones mobiles, ou encore de dispositifs capables de prendre en charge une certaine incapacité (comme des synthétiseurs vocaux ou d'autres inexistants à l'heure actuelle). Qui plus est, dans certains cas, les auteurs ne peuvent pas prévoir comment un agent affichera ou traitera leur contenu. L'expérience prouve que la séparation du contenu, de la présentation et des interactions favorise la réutilisation et l'indépendance du contenu vis-à-vis d'un périphérique donné. Cette séparation suit le principe des spécifications orthogonales (§5.1).
Cette séparation facilite également la réutilisation de contenu au travers de contextes de diffusion multiples. Parfois l'expérience fonctionnelle des utilisateurs, quel que soit le contexte de diffusion, peut être le fruit d'un processus d'adaptation appliqué à une représentation indépendante du moyen d'accès. Pour plus d'informations à propos des principes d'indépendance vis-à-vis des périphériques, voir [DIPRINCIPLES].
Bonne pratique : Séparation du contenu, de la présentation et des interactions
Une spécification DEVRAIT permettre à des auteurs de séparer le contenu des aspects relatifs à la fois à la présentation et aux interactions.
Notez que quand la conception permet de séparer le contenu, la présentation et les interactions, les agents doivent les recombiner. Il existe un spectre de recombinaisons, allant de "le client fait tout" à "le serveur fait tout".
Chaque approche possède ses avantages. Par exemple, quand un client (comme un téléphone mobile) communique les caractéristiques de son équipement au serveur (en utilisant CC/PP, par exemple), le serveur peut fabriquer le contenu pour l'ajuster à ce client. Par exemple, le serveur peut permettre des téléchargements plus rapides en positionnant les liens vers des images ayant une résolution inférieure, vers des vidéos plus petites voire en supprimant les liens vers les vidéos. De même, si le contenu a été écrit avec des branches multiples, le serveur peut enlever les branches inutilisées avant de délivrer le contenu. En outre, en travaillant le contenu pour s'adapter aux caractéristiques d'un client cible, le serveur peut favoriser la réduction du temps de calcul côté client. Cependant, la spécialisation du contenu de cette façon réduit l'efficacité des techniques de cache.
D'un autre côté, concevoir un contenu pouvant être recombiné sur le client tend également à rendre ce contenu applicable à un éventail plus large de périphériques. Cette conception améliore également l'efficacité du système de cache et offre à des utilisateurs plus d'options quant à la présentation. Des feuilles de style dépendantes du média peuvent être utilisées pour fabriquer le contenu, au niveau client, pour des groupes particuliers de périphériques cibles. Pour un contenu textuel avec une structure régulière et récurrente, la taille combinée du contenu plus la feuille de modèle est typiquement moins importante que le contenu entièrement recombiné ; l'amélioration est encore plus grande, si la feuille de style est réutilisée par d'autres pages.
En pratique, une combinaison des deux approches est souvent utilisée. La décision conceptuelle de localiser une application dans ce spectre dépend de la puissance du client, de la puissance et de la charge du serveur et de la largeur de bande passante du médium qui les relie. Si le nombre de clients possibles est illimité, l'application gagnera en montée en charge, en déportant plus de calculs sur le poste client.
Evidemment, il peut ne pas être souhaitable d'atteindre un public le plus vaste possible. Les concepteurs devraient considérer les technologies appropriées, telles que le chiffrage et le contrôle d'accès (§3.5.2), pour limiter l'audience.
Certains formats de données sont conçus pour décrire la présentation (comme SVG et les objets de mise en forme XSL, XSL-FO). Les formats de ce type démontrent qu'on ne peut séparer que le contenu de la présentation (ou de l'interaction) ; à un certain point il devient nécessaire de parler de la présentation. En vertu des principes de spécifications orthogonales (§5.1), ces formats de données devraient seulement aborder les questions de présentation.
Voir les discussions du TAG, formattingProperties-19 (au sujet de l'interopérabilité dans le cas des propriétés et des noms de formatage) et contentPresentation-26 (au sujet de la séparation des balises sémantiques de celles relatives à la présentation).
Le fait qu'il soit possible d'inclure des références vers d'autres ressources par l'intermédiaire des URI est une caractéristique qui définit le web. La simplicité pour créer des liens hypertextes en utilisant des URI absolus (<a href="http://www.example.com/foo">) et des références à des URI relatifs (<a href="foo"> et
<a href="foo#anchor">) est en partie (et peut-être en grande partie) responsable du succès du web hypertexte tel que nous le connaissons aujourd'hui.
Quand une représentation d'une ressource contient une référence à une autre ressource, exprimée avec un URI identifiant cette autre ressource, cela constitue un lien entre les deux ressources. Des métadonnées complémentaires peuvent également faire partie du lien (voir [XLink10] par exemple). Note : Dans ce document, le terme "lien" signifie généralement "relation" et non "connexion physique".
Bonne pratique : Identification de lien
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).
Les formats qui permettent aux auteurs de contenu d'utiliser des URI à la place d'identifiants locaux favorisent l'effet de réseau : la valeur de ces formats se développe avec la taille du web déployé.
Bonne pratique : Faire des liens vers le web
Une spécification DEVRAIT permettre des liens à l'échelle du web et non uniquement à l'intérieur d'un document.
Bonne pratique : URI Générique
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.
L'exploitation des liens hypertextes par les agents n'est pas contraint par l'architecture du web et peut dépendre du contexte de l'application. Les utilisateurs des liens hypertextes s'attendent à pouvoir naviguer parmi les représentations en suivant des liens.
Bonne pratique : Liens hypertextes
Un format de données DEVRAIT incorporer des liens hypertextes si le paradigme attendu de l'interface utilisateur est hypertexte.
Les formats de données qui ne permettent pas aux auteurs de contenu de créer des liens hypertextes conduisent à la création "de noeuds terminaux" sur le web.
Les liens sont généralement exprimés en utilisant des références d'URI (définies dans la section 4.2 de [URI]), qui peuvent être combinées avec un URI de base pour fournir un URI exploitable. La section 5.1 de [URI] explique différentes façons d'établir un URI de base pour une ressource et d'établir une priorité parmi eux. Par exemple, l'URI de base peut être un URI pour la ressource ou bien elle peut être spécifiée dans une représentation (voir les éléments base fournis par HTML et XML et l'en-tête HTTP 'Content-Location'). Voir également la section sur les liens en XML (§4.5.2).
Les agents résolvent une référence d'URI avant d'employer l'URI réel pour interagir avec un autre agent. Les références d'URI aident dans la gestion de contenu en permettant aux auteurs de concevoir une représentation localement, c'est-à-dire, sans se soucier de l'identifiant global qui pourra être employé plus tard pour se référer à la ressource associée.
De nombreux formats de données sont basés sur XML, c'est-à-dire qu'ils se conforment aux règles de syntaxe définies dans les spécifications XML [XML10] ou [XML11]. Cette section discute de points spécifiques à de tels formats. Quiconque cherche des conseils dans ce secteur est invité à consulter les "directives pour l'usage de XML dans les protocoles IETF" [IETFXML], qui contient une discussion complète relative aux choix d'utiliser ou de ne pas utiliser XML, ainsi que des directives spécifiques sur la façon dont il doit être employé. Même si le document concerne les applications Internet avec des références spécifiques aux protocoles, la discussion est généralement tout aussi applicable aux scénarios du Web.
La présente discussion devrait être vue comme un auxiliaire au document [IETFXML]. Référez-vous également aux "directives d'accessibilité XML" [XAG] pour une aide à la conception de formats XML qui minimisent les barrières à l'accessibilité du web pour des personnes handicapées.
XML définit des formats de données textuels qui sont naturellement adaptés à la description des objets de données hiérarchiques et traités dans un ordre choisi. C'est largement, mais non universellement, applicable pour des formats de données. Par exemple, un format audio ou vidéo est peu susceptible d'être bien adapté à une expression en XML. Les contraintes de conception qui suggéreraient l'utilisation de XML sont :
- Nécessité d'une structure hiérarchique.
- Besoin d'un éventail d'outils important sur diverses plates-formes.
- Besoin de données qui peuvent survivre aux applications qui les traitent actuellement.
- Capacité de supporter l'internationalisation d'une façon qui se décrit elle-même et qui supprime la confusion à propos des options de codage.
- Détection précoce des erreurs d'encodage ne nécessitant pas de trouver une "solution de contournement" pour ce genre d'erreurs.
- Une forte proportion à fournir un contenu textuel lisible pour l'homme.
- Composition potentielle du format de données avec d'autres formats encodés en XML.
- Le désir d'avoir des données facilement analysables par les hommes et les machines.
- Le désir d'avoir des vocabulaires pouvant être inventés d'une façon distribuée et combinés avec souplesse.
Les mécanismes de liaison sophistiqués ont été inventés pour les formats XML. XPointer permet de faire des liens vers un contenu qui ne possède pas d'ancre nommée explicite. [XLink] est une spécification appropriée pour représenter des liens dans des applications hypertextes (§4.4) XML. XLink permet aux liens d'avoir des extrémités multiples et d'être exprimés soit en ligne soit via des "bases de liens" stockées à l'extérieur de tout ou partie des ressources identifiées par les liens qu'elles contiennent.
Les concepteurs de formats basés sur XML peuvent considérer l'usage de XLink ainsi que l'utilisation du framework XPointer et du schéma XPointer element() pour définir la syntaxe des identifiants de fragment.
XLink n'est ni la seule conception de liaison qui a été proposée pour XML, ni celle universellement acceptée en tant que bonne conception. Voir également le point du TAG xlinkScope-23.
Le but d'un espace de noms XML (défini dans [XMLNS]) est de permettre le déploiement de vocabulaires XML (dans lesquels des noms d'élément et d'attribut sont définis) dans un environnement global et de réduire le risque de collisions nommées dans un document donné, lorsque les vocabulaires sont mélangés. Par exemple, les spécifications MathML et SVG définissent toutes les deux l'élément set. Étant entendu que des données XML provenant de différents formats tels que MathML et SVG peuvent être combinées dans un document simple, il pourrait y avoir une ambiguïté au sujet de la nature de l'élément set. Les espaces de noms XML réduisent le risque de collisions des noms en tirant profit des systèmes existants pour assigner globalement des noms : le système d'URI (voir également la section sur l'attribution d'URI (§2.2.2)). En utilisant des espaces de noms XML, chaque nom local d'un vocabulaire XML est couplé à un URI (appelé l'URI d'espace de noms) afin de distinguer le nom local des autres noms locaux appartenant à d'autres vocabulaires.
L'utilisation d'URI apporte des avantages supplémentaires. D'abord, chaque paire d'URI/nom local peut être associée à un autre URI, construisant les fondations du vocabulaire du web. Ces termes peuvent être des ressources importantes, il est ainsi approprié de pouvoir leur associer des URI.
[RDFXML] utilise la concaténation simple de l'URI d'espace de noms et du nom local pour créer un URI pour le terme identifié. D'autres correspondances sont susceptibles d'être plus appropriés aux espaces de noms hiérarchiques ; voir le point du TAG qui s'y rapporte, abstractComponentRefs-37.
Les concepteurs des formats de données basés sur XML, qui déclarent des espaces de noms, permettent ainsi de réutiliser ces formats de données et de les combiner dans de nouvelles façons que l'on imagine pas encore. La non déclaration d'espace de noms rend une telle réutilisation plus difficile, voire impossible dans certains cas.
Bonne pratique : Adoption des espaces de noms
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.
Les attributs se situent toujours dans la portée de l'élément sur lequel ils apparaissent. Un attribut qui est « global », c'est-à-dire, un attribut qui pourrait clairement apparaître sur des éléments de plusieurs types, y compris sur des éléments appartenant à d'autres espaces de noms, devrait être explicitement placé dans un espace de noms. Des attributs locaux, associés avec un seul type particulier d'élément, n'ont pas besoin d'être inclus dans un espace de noms puisque leur signification sera toujours claire grâce au contexte fourni par cet élément.
L'attribut type de l'espace de noms des instances de schéma XML du W3C, "http://www.w3.org/2001/XMLSchema-instance", ([XMLSCHEMA] section 4.3.2) est un exemple d'attribut global. Il peut être employé par des auteurs de n'importe quel vocabulaire pour faire une affirmation, dans des instances de données, au sujet du type de l'élément sur lequel il apparaît. Comme c'est un attribut global, il doit toujours être qualifié. L'attribut frame dans un tableau HTML est un exemple d'attribut local. Placer cet attribut dans un espace de noms n'a aucun intérêt, puisque l'attribut est peu susceptible d'être utile sur un élément différent d'un tableau HTML.
Les applications se basant sur le traitement d'une DTD doivent imposer des contraintes supplémentaires à l'utilisation des espaces de noms. Les DTD effectuent la validation en s'appuyant sur la forme lexicale des noms d'élément et d'attribut dans le document. Cela rend les préfixes significatifs au niveau de la syntaxe, d'une façon qui n'était pas anticipée par [XMLNS].
Scénario
Nadia reçoit des données d'une représentation provenant de "weather.example.com" dans un format peu familier. Elle en sait suffisamment au sujet de XML pour identifier à quel espace de noms les éléments appartiennent. Comme il est identifié par l'URI "http://weather.example.com/2003/format", elle demande à son navigateur d'obtenir une représentation de la ressource identifiée. Elle récupère quelques données utiles qui lui permettent d'en savoir plus au sujet du format de données. Le navigateur de Nadia est également capable d'exécuter certaines opérations automatiquement (c'est-à-dire sans surveillance par une personne) à partir de données qui ont été optimisées pour des agents logiciels. Par exemple, son navigateur pourrait, au nom de Nadia, télécharger des agents complémentaires pour traiter et afficher le format.
Le fait que l'URI d'espace de noms puisse être employé pour identifier une ressource d'information qui contient une information utile, exploitable par la machine et/ou par les personnes, au sujet de termes de l'espace de noms, est un autre avantage de l'utilisation des URI pour construire des espace de noms. Ce type de ressource s'appelle un document d'espace de noms. Quand un propriétaire d'URI d'espace de noms fournit un document d'espace de noms, il fait autorité pour cet espace de noms.
Il y a beaucoup de raisons de fournir un document d'espace de noms. Une personne pourrait vouloir :
- comprendre le but de cet espace de noms,
- apprendre comment se servir du vocabulaire de balise dans l'espace de noms,
- découvrir qui le contrôle et ses politiques associées,
- demander à l'autorité l'accès aux schémas ou aux informations complémentaires le concernant, ou
- reporter un bogue ou une situation qui peut être considéré comme une erreur
Un processeur pourrait vouloir :
- obtenir un schéma pour la validation,
- obtenir une feuille de style pour la présentation, ou
- obtenir des ontologies pour faire des inférences.
En général, il n'y pas de meilleure pratique établie pour créer des représentations d'un document d'espace de noms. Les attentes des applications influenceront les formats ou les formats de données utilisés. Elles influenceront également la localisation de l'information appropriée, soit directement dans une représentation soit dans une référence qu'elle fera.
Bonne pratique : Documents d'espace de noms
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.
Voici quelques exemples de formats de données pour des documents d'espace de noms : [OWL10], [RDDL], [XMLSCHEMA] et [XHTML11]. Chacun de ces formats répond à différentes exigences décrites ci-dessus pour satisfaire les besoins d'un agent qui souhaite obtenir plus d'informations sur l'espace de noms. Notez cependant certains problèmes relatifs aux identifiants de fragment et à la négociation de contenu (§3.2.2) si cette dernière est utilisée.
Voir les points du TAG, namespaceDocument-8 (au sujet des caractéristiques désirées pour les documents d'espace de noms) et abstractComponentRefs-37 (au sujet de l'utilisation des identifiants de fragment avec des noms d'espace de noms pour identifier des composants abstraits).
La section 3 du document "Les espaces de noms dans XML" [XMLNS] fournit une construction syntaxique, connue sous le nom de QName, pour exprimer de façon compacte des noms qualifiés dans des documents XML. Un nom qualifié est une paire se composant d'un URI, qui désigne un espace de noms et d'un nom local défini dans cet espace de noms. La documentation "Les espaces de noms dans XML" prévoit l'utilisation de QName comme des noms pour des éléments et des attributs XML.
D'autres spécifications, en commençant par [XSLT10], ont utilisé l'idée d'employer des QName dans des contextes différents que les noms d'élément et d'attribut, par exemple dans les valeurs d'attribut et dans le contenu des éléments. Cependant, les processeurs XML généraux ne peuvent pas identifier les QName de façon sûre lorsqu'ils sont utilisés dans des valeurs d'attribut et dans le contenu des éléments. Par exemple, la syntaxe des QName se chevauche avec celle des URI. L'expérience a également montré d'autres limitations concernant les QName, comme la perte des correspondances d'espace de noms après la canonisation XML.
Contrainte : QName se confondant avec un URI
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.
Pour plus d'informations, voir les conclusions du TAG "Utiliser les QName comme identifiants dans le contenu [Using QNames as Identifiers in Content]".
Les QName étant compacts, certains concepteurs de spécification ont adopté cette syntaxe pour identifier des ressources. Cependant même si cette notation raccourcie est commode, elle a un coût. Il n'y a pas de manière classique de convertir un QName en un URI ou vice versa. Bien que les QName soient pratiques, ils ne remplacent pas les URI comme système d'identification du web. L'utilisation de QName pour identifier des ressources web, sans fournir de correspondance à des URI, est inconsistante avec l'architecture du web.
Bonne pratique : Correspondance de QName
Une spécification dans laquelle les QName servent d'identifiant de ressource DOIT fournir une correspondance avec des URI.
Voir le paragraphe Les espace de noms XML (§4.5.3) pour quelques exemples de stratégies de correspondance.
Voir également les discussions du TAG, rdfmsQnameUriMapping-6 (au sujet de la correspondance des QName/URI), qnameAsId-18 (au sujet de l'utilisation de QName comme identifiants dans le contenu XML) et abstractComponentRefs-37 (au sujet de l'utilisation des identifiants de fragment avec les noms d'espace de noms pour identifier les composants abstraits).
Considérons le fragment XML suivant : <section name="foo">. L'élément section possède-t-il ce que la recommandation XML désigne comme un ID foo (c'est-à-dire que "foo" ne doit pas apparaître dans le document XML global plus d'une fois) ? On ne peut pas répondre à cette question en examinant seulement l'élément et ses attributs. En XML, la qualité "être un identifiant (ID)" est associée au type d'un attribut, pas à son nom. Trouver les identifiants dans un document demande un traitement complémentaire.
- Le traitement du document avec un processeur qui reconnaît les déclarations de liste d'attributs provenant de la DTD (dans le sous-ensemble externe ou interne) pourrait indiquer une déclaration qui identifie l'attribut
name comme étant un ID. Note : Ce traitement ne fait pas nécessairement partie de la validation. Un processeur non validant, gérant les DTD, peut identifier les ID.
- Le traitement du document avec un schéma XML W3C pourrait indiquer une déclaration d'élément qui identifie l'attribut
name comme étant un ID de schéma XML.
- En pratique, le traitement du document avec un autre langage de schéma, comme RELAX NG [RELAXNG], pourrait également indiquer les attributs déclarés en tant qu'ID, comme le schéma XML le définit. Beaucoup de spécifications récentes commencent à traiter le XML au niveau de l'Infoset [INFOSET] et ne spécifient pas de façon normative comment un Infoset est construit. Pour ces spécifications, tout processus établissant le type ID dans l'Infoset (et dans l'infoset de post validation avec un schéma (Post Schema Validation Infoset ou PSVI, défini dans [XMLSCHEMA]) peut identifier de façon utile les attributs de type ID.
- En pratique, les applications peuvent avoir des moyens indépendants (comme ceux définis dans la section 3.2 de la spécification XPointer [XPTRFR]) de localiser des identifiants à l'intérieur d'un document.
Pour compliquer un peu plus les choses, les DTD établissent le type ID dans l'Infoset alors que le schéma XML W3C produit un PSVI mais ne modifie pas l'Infoset original. Cela laisse la porte ouverte pour un processeur de ne regarder que dans l'Infoset et par conséquent de ne pas reconnaître les ID assignés par le schéma.
Voir les discussions du TAG, xmlIDSemantics-32, pour des informations de fond supplémentaires et [XML-ID] pour une solution en cours de développement.
La RFC 3023 définit les types de média Internet "application/xml" et "text/xml" et décrit une convention selon laquelle les formats de données basés sur XML emploient des types de média Internet avec un suffixe "+xml", comme par exemple "image/svg+xml".
Les types de média "text" posent deux problèmes : premièrement, pour les données identifiées en tant que "text/*", les intermédiaires web sont autorisés à les "transcoder", c'est-à-dire, convertir les caractères dans un autre encodage. Le transcodage peut rendre l'auto-description fausse ou peut rendre un document mal formé.
Bonne pratique : XML et "text/*"
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/".
Deuxièmement, les représentations dont les types de média Internet commencent par "text/" sont supposées, à moins que le paramètre de jeux de caractères (charset) soit indiqué, être encodées en US-ASCII. Par ailleurs, la syntaxe XML étant conçue pour rendre les documents auto-descriptifs, l'omission du paramètre charset est donc une bonne pratique. Mais très souvent, XML n'est pas encodé en US-ASCII, l'utilisation des types de média Internet "text/" est donc contradictoire avec cette bonne pratique.
Bonne pratique : XML et les encodages de caractères
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.
La section sur les types de représentation et sur la sémantique des identifiants de fragment (§3.2.1) aborde l'interprétation des identifiants de fragment. Les concepteurs de spécification de format de données basé sur XML devraient définir la sémantique des identifiants de fragment dans ce format. Le framework XPointer [XPTRFR] fournit un point de départ interopérable.
Quand le type de média assigné aux données de représentation est "application/xml", aucune sémantique n'est définie pour les identifiants de fragment. Les auteurs ne devraient donc pas s'en servir pour ce type de données. C'est également vrai si le type de média assigné possède le suffixe "+xml" (défini dans "Types de média XML" [RFC3023]). La spécification du format de données ne définit pas la sémantique des identifiants de fragment. En bref, le simple fait de savoir que le contenu est du XML ne fournit pas d'informations au sujet de la sémantique des identifiants de fragment.
De nombreuses personnes supposent que l'identifiant de fragment #abc, lorsqu'il se rapporte à des données XML, identifie un élément du document possédant l'ID "abc". Cependant, aucun support normatif ne corrobore cette supposition. Une révision de la RFC 3023 est attendue et devrait résoudre ce point.
Voir les discussions du TAG, fragmentInXML-28.
4.6. Futures directions pour les formats de données
Les formats de données permettent la création de nouvelles applications autorisant l'utilisation de l'infrastructure de l'espace de l'information. Le web sémantique en est une application, construite sur RDF [RDFXML]. Ce document ne discute pas du web sémantique en détail. En revanche, le TAG compte le développer dans de futurs volumes de ce document. Voir les discussions du TAG qui y sont relatives dans httpRange-14.
Un certain nombre de principes généraux d'architecture s'appliquent à chacune des trois bases de l'architecture du web.
L'identification, l'interaction et la représentation sont des concepts orthogonaux. Cela signifie que les technologies utilisées pour l'identification, l'interaction et la représentation peuvent évoluer de façon indépendante. Par exemple :
- Les ressources sont identifiées par des URI. Les URI peuvent être publiés sans établir de représentation de la ressource ou déterminer si des représentations sont disponibles.
- Une syntaxe générique d'URI permet à des agents de fonctionner dans de nombreux cas sans avoir plus de détails sur les schémas d'URI.
- Dans de nombreux cas, la représentation d'une ressource peut être changée sans qu'il y ait de conséquence sur les références à la ressource (par exemple, en utilisant la négociation de contenu).
Quand deux spécifications sont orthogonales, l'une peut être changée sans impact sur la seconde, même s'il existe des dépendances à cette autre spécification. Par exemple, bien que la spécification de HTTP dépende de la spécification des URI, les deux peuvent évoluer indépendamment. Cette orthogonalité augmente la flexibilité et la robustesse du Web. Ainsi, il est possible de se référer à une image par l'intermédiaire d'un URI sans avoir de connaissances sur le format choisi pour représenter l'image. L'introduction de formats d'image, tels que PNG et SVG, est facilitée car elle ne perturbe pas les références existantes aux ressources d'image.
Principe : Orthogonalité
Les abstractions orthogonales bénéficient des spécifications orthogonales.
L'expérience démontre que les problèmes surviennent lorsque les concepts orthogonaux sont définis dans une seule et même spécification. Considérerons, par exemple, les spécifications de HTML qui incluent la spécification orthogonale x-www-form-urlencoded. Les développeurs de logiciel (d'applications [CGI] par exemple) pourraient gagner du temps pour trouver la spécification si elle était publiée séparément puis citée dans les spécifications de HTTP, des URI et de HTML.
Les problèmes apparaissent également quand les spécifications essaient de modifier des abstractions orthogonales décrites ailleurs. Une version historique de la spécification de HTML a ajouté la valeur "Refresh" à l'attribut http-equiv de l'élément meta. Elle a été définie comme étant équivalente à l'en-tête HTTP du même nom. Les auteurs de la spécification HTTP ont finalement décidé de ne pas fournir cet en-tête. Ainsi les deux spécifications ont été discordantes l'une avec l'autre. Par la suite, le groupe de travail HTML du W3C a supprimé la valeur "Refresh".
Une spécification devrait clairement indiquer quelles fonctionnalités en recouvrent d'autres, définies et gérées par d'autres spécifications.
L'information sur le web et les technologies utilisées pour représenter cette information évoluent dans le temps. L'extensibilité est la propriété d'une technologie qui favorise l'évolution sans sacrifier l'interopérabilité. Voici quelques exemples de technologies réussies permettant le changement tout en réduisant au minimum la rupture :
- la spécification de manière orthogonale de schémas d'URI,
- l'utilisation d'un ensemble ouvert de types de média Internet dans le courrier électronique et HTTP pour spécifier l'interprétation des documents,
- la séparation de la grammaire générique de XML et de l'ensemble ouvert des espaces de noms XML pour les noms d'élément et d'attribut,
- modèles d'extensibilité dans les feuilles de style en cascade (CSS), dans XSLT 1.0 et SOAP,
- les plug-in des agents utilisateur.
Les extensions HTTP obligatoires [HTTPEXT] sont un exemple de mécanisme non réussi. La communauté a cherché des mécanismes pour étendre HTTP, mais apparemment les coûts de la proposition d'extension obligatoire (notamment en terme de complexité) étaient supérieurs aux avantages qu'elle apportait et ont ainsi entravé leur adoption.
Nous revenons, plus loin, sur la propriété d'"extensibilité", portée par les URI, certains formats de données et par quelques protocoles (par l'incorporation de nouveaux messages).
Sous-ensemble de langage: un langage est un sous-ensemble (ou "profil") d'un deuxième langage si tout document valide avec le premier langage est également valide avec le deuxième et que les interprétations sont identiques.
Langage étendu: Si un langage est un sous-ensemble d'un autre, le dernier super-ensemble s'appelle un langage étendu. La différence entre les langages est appelée l'extension. Clairement, l'extension d'un langage est meilleure, en terme d'interopérabilité, que la création d'un langage incompatible.
Dans le meilleur des cas, de nombreuses instances du langage du super-ensemble peuvent être traitées sans risque et de façon utile, comme s'ils appartenaient au langage du sous-ensemble. Les langages qui peuvent évoluer de cette façon, en permettant à des applications de fournir de nouvelles informations lorsque nécessaire tout en pouvant interopérer avec des applications qui ne comprennent qu'un sous-ensemble du langage courant, sont dits "extensibles". Les développeurs de langage peuvent faciliter l'extensibilité en définissant le comportement par défaut des extensions inconnues (par exemple, celles qui doivent être ignorées d'une certaine façon ou qui devraient être considérées comme des erreurs).
Par exemple, au début du Web, les agents HTML ont suivi la convention d'ignorer les balises inconnues. Ce choix a laissé une place à l'innovation (c'est-à-dire aux éléments non standard) et a encouragé le déploiement du HTML. Cependant, les problèmes d'interopérabilité ont également surgi. Dans ce type d'environnement, il y a une tension inévitable entre l'interopérabilité à court terme et le désir d'extensibilité. L'expérience prouve que les conceptions qui touchent le bon équilibre entre la possibilité de changement et la préservation de l'interopérabilité sont plus susceptibles de prospérer et risquent moins de perturber la communauté Web. Les spécifications orthogonales (§5.1) aident à réduire le risque de rupture.
Pour aller plus loin, voir la section sur la gestion des versions et l'extensibilité (§4.2). Voir également les discussions du TAG, xmlProfiles-29 ainsi que les dialectes HTML.
Des erreurs se produisent dans les systèmes d'information gérés en réseau. Une condition d'erreur peut être correctement caractérisée (par exemple, des erreurs syntaxiques en XML ou des erreurs 4xx en HTTP) ou apparaître de manière imprévisible. La correction d'erreurs signifie qu'un agent répare une condition de sorte que dans le système, tout se passe comme si l'erreur ne s'était jamais produite. La retransmission de données, en réponse à une indisponibilité temporaire du réseau, est un exemple de correction d'erreur. La reprise sur erreur signifie qu'un agent ne répare pas une condition d'erreur mais continue son traitement en avertissant du fait qu'une erreur s'est produite.
Les agents corrigent fréquemment les erreurs sans que les utilisateurs en soient conscients, leur épargnant les détails relatifs aux communications réseau complexes. D'un autre côté, il est important que les agents fassent de la reprise sur erreur d'une manière évidente pour les utilisateurs, puisqu'ils agissent en leur nom.
Principe : Reprise sur erreur
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.
Un agent ne doit pas obligatoirement interrompre l'utilisateur (en affichant par exemple une boîte de dialogue de confirmation) pour obtenir son consentement. L'utilisateur peut indiquer son consentement par des options de configuration pré-sélectionnées, des modes ou des choix graphiques sélectionnables, qui lui donnent un rapport approprié quand l'agent détecte une erreur. Les développeurs d'agent ne devraient pas ignorer ces questions relatives à l'utilisation lorsqu'ils conçoivent le comportement de reprise d'erreur.
Pour favoriser l'interopérabilité, les concepteurs de spécifications devraient identifier des conditions d'erreur prévisibles. L'expérience a conduit aux observations suivantes au sujet des approches de traitement d'erreur.
- Les concepteurs de protocole devraient fournir assez d'informations au sujet d'une condition d'erreur de sorte qu'un agent puisse la relayer. Par exemple, un code de statut HTTP 404 (non trouvé) est utile car il permet à des agents utilisateur de présenter l'information appropriée aux utilisateurs, leur permettant d'entrer en contact avec le fournisseur de la représentation en cas de problèmes.
- L'expérience des coûts de développement d'un agent d'utilisateur pouvant traiter les diverses formes de contenu HTML mal formé a convaincu les concepteurs des spécifications XML que les agents se devaient de soulever une erreur face à un contenu mal formé. Les utilisateurs étant peu susceptibles de tolérer de tels échecs, ce choix de conception a mis la pression sur chacune des parties, dans le but de respecter les contraintes XML, pour le bénéfice de tous.
- Un agent qui rencontre un contenu non reconnu peut le manipuler de plusieurs façons, y compris le considérer comme une erreur. Voir également la section sur la gestion des versions et l'extensibilité (§4.2).
- Le comportement face à une erreur, qui est approprié pour une personne, peut ne pas l'être pour un logiciel. Les personnes sont capables d'exercer un jugement à l'instar des logiciels. Une réponse d'erreur informelle peut suffire à une personne mais pas à un processeur.
Voir les discussions du TAG, contentTypeOverride-24, qui concernent la source des métadonnées qui font autorité.
Le web suit la tradition d'Internet, en ce sens que ses interfaces importantes sont définies en termes de protocoles, en spécifiant la syntaxe, la sémantique et des contraintes ordonnées de messages échangés. Les protocoles conçus pour être souples face aux environnements considérablement variables ont favorisé l'accroissement du web. Ils ont également facilité la communication à travers des frontières multiples de confiance. Les interfaces de programmation d'application (API) traditionnelles ne tiennent pas toujours compte de ces contraintes. Elles ne le devraient pas forcement non plus. Un effet de la conception basée sur un protocole est que la technologie partagée entre les différents agents dure souvent plus longtemps que les agents eux-mêmes.
Il est classique pour des programmeurs travaillant avec le web d'écrire un code produisant et analysant ces messages directement. Il est moins commun, mais pas inconcevable, que les utilisateurs soient exposés directement à ces messages. Il est souvent souhaitable de permettre l'accès aux utilisateurs aux détails des formats et des protocoles : les autoriser à "voir la source" peut ainsi leur faire gagner en expertise dans les fonctionnements du système sous-jacent.
Ce document a été édité (authored) par le
Groupe d'Architecture Technique (TAG) du W3C qui inclut les participants suivants : Tim Berners-Lee (co-Président, 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) et Stuart Williams (co-Chair,
Hewlett-Packard).
Le TAG apprécie les nombreuses participations sur sa liste de discussions publique, www-tag@w3.org
(archives), qui ont aidées à améliorer ce document.
Enfin, nous remercions 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 et
Yuxiao Zhao pour leurs contributions.
