‘Namespaces in XML 1.1’ (4 février 2004) en version française

Statut du document traduit

Ceci est une traduction de la recommandation XML-Names 1.1 du W3C traitant des espaces de nommage dans XML 1.1.

Cependant, il ne s'agit pas de la version officielle en français. Seul le document original en anglais a valeur de référence. On peut l'obtenir à : http://www.w3.org/TR/2004/REC-xml-names11-20040204.

Avertissement

Des erreurs ont pu survenir malgré le soin apporté à ce travail.

Notes sur la traduction

Certains concepts sont difficiles à rendre en français, ou peuvent bénéficier d'une explication. Par moment, les expressions originales en anglais viennent en renfort dans le texte sous cette forme :
ex. traduction [ndt. translation]

D'autres expressions intègrent également les versions originales en anglais, qui apparaissent d'une manière ou d'une autre (selon le navigateur), lorsque l'on laisse le pointeur de la souris au-dessus d'elles. Elles se présentent sous cette forme :
ex. Agent utilisateur

Finalement, les liens menant à d'autres documents du W3C déjà traduits sont discrètement doublés vers leur traduction, comme ceci :
ex. un lien vf  vers un document du W3C.

Archives compressées et autres formats

Cette traduction est disponible au format HTML sous forme d'archive compressée et, le cas échéant, dans d'autres formats à l'adresse http://www.yoyodesign.org/doc/w3c/w3c.html.

Autres documents traduits

On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/2003/03/Translations/byLanguage?language=fr

Avis légal

Copyright © 1994-2004 World Wide Web Consortium,
(Massachusetts Institute of Technology,
European Research Consortium for Informatics and Mathematics,
Keio University).
Tous droits réservés. Consulter la notice de copyright pour les productions du W3C.


Page d'accueil du W3C

Les espaces de nommage dans XML 1.1

Recommandation du W3C du 4 février 2004

Cette version :
http://www.w3.org/TR/2004/REC-xml-names11-20040204
Dernière version :
http://www.w3.org/TR/xml-names11
Version précédente :
http://www.w3.org/TR/2003/PR-xml-names11-20031105
Rédacteurs :
Tim Bray, Textuality <tbray@textuality.com>
Dave Hollander, Contivo, Inc. <dmh@contivo.com>
Andrew Layman, Microsoft <andrewl@microsoft.com>
Richard Tobin, University of Edinburgh et Markup Technology Ltd <richard@cogsci.ed.ac.uk> - version 1.1

Veuillez consulter l'errata de ce document, qui peut recéler des corrections normatives.

Voir des traductions le cas échéant.

Le document est également disponible dans ce format non normatif : XML.


Résumé

Les espaces de nommage XML représentent une méthode simple pour la qualification des noms des éléments et attributs utilisés dans les documents XML, en les associant à des espaces de nommage identifiés par des adresses IRI.

Statut de ce document

Cette section décrit le statut du document au moment de sa publication. D'autres documents peuvent venir le remplacer. On trouvera une liste des publications actuelles du W3C et la dernière mise à jour de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ce document est une recommandation du W3C. Il a été revu par les membres du W3C et des tiers intéressés et approuvé par le Directeur en tant que recommandation du W3C. C'est un document stable qui peut être employé comme matériel de référence ou cité comme référence normative à partir d'un autre document. Le rôle du W3C en produisant cette recommandation est d'attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Ceci participe à l'amélioration des fonctionnalités et de l'interopérabilité du Web.

Ce document est un produit de l'activité XML du W3C. Cette version en anglais est la seule normative. Cependant, pour d'éventuelles traductions de ce document, voyez à http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names11.

La documentation des éventuels droits de propriété intellectuelle concernant cette recommandation se trouve sur la page de divulgation des droits de propriété intellectuelle publique du groupe de travail.

Les mises en œuvre connues sont documentées dans le rapport de mise en œuvre des espaces de nommage 1.1. Un ensemble de test est également disponible via la page de l'ensemble de test XML.

Veuillez signaler les erreurs dans ce document sur la liste de diffusion xml-names-editor@w3.org. On peut également en consulter les archives publiques. La liste des erreurs dans ce document est disponible à http://www.w3.org/XML/2004/xml-names11-errata.

Table des matières

  1. La motivation et le sommaire
    1. Remarque sur la notation et l'usage
  2. Les espaces de nommage XML
    1. Les concepts de base
    2. L'utilisation d'adresses IRI comme noms d'espace de nommage
    3. La comparaison des adresses IRI
  3. La déclaration des espaces de nommage
  4. Les noms qualifiés
  5. L'utilisation des noms qualifiés
  6. L'application des espaces de nommage aux éléments et attributs
    1. La portée de l'espace de nommage
    2. L'espace de nommage par defaut
    3. L'unicité des attributs
  7. La conformité des documents
  8. La conformité des processeurs
  9. Les identificateurs de ressource internationnalisés (IRI)

Annexes


1 La motivation et le sommaire

Nous envisageons les applications du langage de balisage extensible (XML) pour lesquelles un seul document XML peut contenir des éléments et des attributs (que l'on appellera vocabulaire de balisage) définis et utilisés par plusieurs modules logiciels. C'est la modularité qui motive ce choix : si un tel vocabulaire de balisage existe, lequel est bien compris et exploité utilement par un logiciel, alors il est préférable de réutiliser ce balisage plutôt que de le réinventer.

Les documents de ce genre, qui contiennent plusieurs vocabulaires de balisage, créent des problèmes de reconnaissance et de collision. Les modules logiciels doivent pouvoir reconnaître les éléments et attributs pour le traitement desquels ils sont conçus, même si des collisions surviennent lorsque le balisage destiné à un autre ensemble logiciel utilise un même nom d'élément ou d'attribut.

Ces considérations obligent à des structures de document ayant des noms construits de manière à éviter les accès concurrents de noms issus de vocabulaires de balisage différents. Cette spécification décrit les espaces de nommage XML, un mécanisme qui accomplit cette tâche en assignant des noms développés aux éléments et aux attributs.

1.1 Remarque sur la notation et l'usage

Dans le document, quand ils sont MIS EN ÉVIDENCE de cette manière, les mots-clés DOI(VEN)T, NE DOI(VEN)T PAS, OBLIGATOIRE, DEVRAI(EN)T, NE DEVRAI(EN)T PAS et PEU(VEN)T doivent se comprendre comme décrit dans le document [Keywords].

Remarquez que nombre de non-terminaux ne sont pas définis dans les productions de cette spécification, mais dans la spécification XML [XML]. Lorsque les non-terminaux définis ici ont les mêmes noms que les non-terminaux définis dans la spécification XML, les productions du présent document correspondent dans tous les cas au sous-ensemble des chaînes de caractères filtrées par les productions correspondantes de la spécification XML.

Dans les productions de ce document, les contraintes d'espace de nommage (CEN) s'ajoutent aux autres règles que les documents DOIVENT suivre pour être conformes à cette spécification.

2 Les espaces de nommage XML

2.1 Les concepts de base

[Définition : Un espace de nommage XML est identifié par une adresse IRI ; les noms d'élément et d'attribut peuvent se placer dans un espace de nommage XML à l'aide des mécanismes décrits dans cette spécification.]

[Définition : Un nom développé est le couple constitué par un nom d'espace de nommage et par un nom local.] [Définition : Pour un nom, noté N, dans un espace de nommage identifié par une adresse IRI, notée I, le nom d'espace de nommage est I. Pour un nom N qui ne se trouve pas dans un espace de nommage, le nom d'espace de nommage n'a pas de valeur.] [Définition : Dans tous les cas, le nom local est N.] C'est cette combinaison entre l'espace de nommage IRI géré universellement et les noms locaux du vocabulaire qui concourt à éviter les conflits de noms.

Les adresses IRI peuvent contenir des caractères non admis pour les noms et leur manipulation du fait de leur longueur est souvent peu pratique. C'est la raison pour laquelle on n'utilise pas directement les noms développés pour nommer les éléments et les attributs dans les documents XML et on leur préfère des noms qualifiés. [Définition : Un nom qualifié est un nom susceptible d'interprétation dans un espace de nommage.] Dans les documents conformes à cette spécification, les noms d'élément et d'attribut apparaissent comme noms qualifiés. Du point de vue syntaxique, ce sont soit des noms préfixés, soit des noms sans préfixe. Une syntaxe de déclaration à partir d'attributs est fournie afin de relier les préfixes aux noms d'espace de nommage et les noms d'élément sans préfixe à un espace de nommage implicite ; ces déclarations se cantonnent aux éléments sur lesquels elles apparaissent, de sorte que des relations différentes peuvent s'appliquer à des parties différentes d'un document. Les processeurs conformes à cette spécification DOIVENT reconnaître ces déclarations et préfixes et réagir en conséquence.

2.2 L'utilisation d'adresses IRI comme noms d'espace de nommage

Bien qu'elle soit une adresse IRI légale, la chaîne vide ne peut s'utiliser comme nom d'espace de nommage.

On déconseille l'utilisation d'adresses IRI relatives dans les déclarations d'espace de nommage, y compris pour les appels internes au document.

Remarque :

La décision de déconseiller les adresses IRI relatives est intervenue lors d'un vote plénier XML du W3C [Contre-indication des adresses URI relatives]. Celle-ci dit aussi que les spécifications ultérieures, comme les spécifications DOM, XPath, etc., n'en donnerons aucune interprétation.

2.3 La comparaison des adresses IRI

Les adresses IRI, identifiant les espaces de nommage, sont comparées pour déterminer l'appartenance d'un nom ou non à un espace de nommage donné et si deux noms appartiennent au même espace de nommage. [Définition : Les deux adresses IRI sont traitées comme des chaînes de caractères et elles sont considérées comme identiques si et seulement si les chaînes le sont, c'est-à-dire s'il s'agit de la même séquence de caractères.] La comparaison est sensible à la casse et aucun échappement au moyen de caractères signe pour cent (%) n'est effectué ni défait.

Par conséquent, les adresses IRI qui ne sont pas identiques, au sens précédent, peuvent se résoudre en une même ressource. Comme exemple, les adresses IRI qui ne diffèrent que par leur casse ou par des caractères échappés avec un caractère %, ou celles qui se trouvent dans des entités externes ayant des adresses URI de base différentes (notez toutefois que les adresses IRI relatives sont déconseillées comme noms d'espace de nommage).

Dans une déclaration d'espace de nommage, l'adresse IRI est représentée par la valeur normalisée de l'attribut, et ainsi le remplacement des appels de caractère et des appels d'entité a déjà eu lieu avant la comparaison.

Exemples :

Les adresses IRI suivantes sont toutes différentes en ce qui concerne l'identification des espaces de nommage, car elles diffèrent par la casse :

  • http://www.example.org/wine

  • http://www.Example.org/wine

  • http://www.example.org/Wine

Les adresses IRI suivantes sont également toutes différentes :

  • http://www.example.org/rosé

  • http://www.example.org/ros%c3%a9

  • http://www.example.org/ros%c3%A9

  • http://www.example.org/ros%C3%a9

  • http://www.example.org/ros%C3%A9

De même :

  • http://www.example.org/~wilbur

  • http://www.example.org/%7ewilbur

  • http://www.example.org/%7Ewilbur

Si l'entité eacute est définie comme étant é, alors les balises ouvrantes suivantes contiennent toutes des déclarations d'espace de nommage liant le préfixe p à la même adresse IRI http://example.org/rosé.

  • <p:foo xmlns:p="http://example.org/rosé">

  • <p:foo xmlns:p="http://example.org/ros&#xe9;">

  • <p:foo xmlns:p="http://example.org/ros&#xE9;">

  • <p:foo xmlns:p="http://example.org/ros&#233;">

  • <p:foo xmlns:p="http://example.org/ros&eacute;">

À cause du risque de confusion entre des adresses IRI qui, si résolues, seraient équivalentes, on décourage fortement l'utilisation de caractères échappés au moyen de caractères % dans les noms d'espace de nommage.

3 La déclaration des espaces de nommage

[Définition : Un espace de nommage (ou, plus précisément, une liaison à un espace de nommage) se déclare au moyen d'une famille d'attributs réservés. Le nom de ce type d'attribut doit soit être xmlns, soit commencer par xmlns:. Ces attributs, comme tous les autres attributs XML, peuvent être fournis directement ou implicitement.]

Les noms d'attribut pour la déclaration d'un espace de nommage
[1]   NomAttEspNom   ::=   NomAttPréfixé
| NomAttImpl
[2]   NomAttPréfixé   ::=   'xmlns:' NomEspCondensé[CEN : Noms de préfixe et d'espace de nommage réservés]
[3]   NomAttImpl   ::=   'xmlns'
[4]   NomEspCondensé   ::=   CarNomInitEspCondensé CarNomEspCondensé*/* Une valeur XML de type Nom vf, moins le caractère ":" */
[5]   CarNomEspCondensé   ::=   CarNom vf - ':'
[5a]   CarNomInitEspCondensé   ::=   CarNomInit vf - ':'

La valeur normalisée d'un attribut DOIT être soit une adresse IRI (le nom d'espace de nommage identifiant l'espace de nommage), soit une chaîne vide. Pour faire son office, le nom d'espace de nommage DEVRAIT se caractériser par son unicité et sa persistance. Il n'est pas destiné à être directement utilisable pour la recherche d'un schéma (le cas échéant). Les adresses URN [RFC2141] représentent un exemple de syntaxe conçue pour cet usage. À noter, cependant, que les adresses URL ordinaires peuvent s'utiliser dans certaines conditions pour obtenir la même chose.

[Définition : Si le nom d'attribut correspond à la production NomAttPréfixé, alors la production NomEspCondensé donne le préfixe d'espace de nommage, utilisé pour associer les noms d'élément et d'attribut au nom d'espace de nommage dans la valeur d'attribut, dans la sphère de l'élément auquel la déclaration est attachée.]

[Définition : Si le nom d'attribut correspond à la production NomAttImpl, alors le nom d'espace de nommage dans la valeur d'attribut est celui de l'espace de nommage implicite, dans la sphère de l'élément auquel la déclaration est attachée.] Les espaces de nommage implicites et l'annulation des déclarations sont abordés au chapitre 6 L'application des espaces de nommage aux éléments et attributs.

Voici un exemple de déclaration d'espace de nommage qui associe le préfixe d'espace de nommage edi au nom d'espace de nommage http://ecommerce.example.org/schema :

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- le préfixe "edi" est lié à http://ecommerce.example.org/schema
       pour l'élément "x" et son contenu -->
</x>

Contrainte d'espace de nommage : Noms de préfixe et d'espace de nommage réservés

Le préfixe xml est par définition lié au nom d'espace de nommage http://www.w3.org/XML/1998/namespace. On PEUT le déclarer, ce n'est pas obligatoire, mais on NE DOIT PAS en supprimer la déclaration ou le lier à un quelconque autre espace de nommage. On NE DOIT PAS lier d'autres préfixes à ce nom d'espace de nommage.

Le préfixe xmlns n'est utilisé que pour déclarer les liaisons aux espaces de nommage et il est lié par définition au nom d'espace de nommage http://www.w3.org/2000/xmlns/. On NE DOIT PAS le déclarer ou en supprimer la déclaration. On NE DOIT PAS lier d'autres préfixes à ce nom d'espace de nommage.

Tous les autres préfixes commençant par la séquence des trois lettres x, m et l, quelle que soit leur casse, sont réservés. Cela signifie que :

  • les utilisateurs NE DEVRAIENT PAS les employer, sauf selon les définitions de spécifications ultérieures

  • les processeurs NE DOIVENT PAS les traiter comme entraînant des erreurs irrémédiables.

Même s'ils ne sont pas eux-mêmes réservés, il n'est pas judicieux d'employer des noms préfixés dont la valeur de type PartieLocale commence par les lettres x, m et l, quelle que soit leur casse, puisque ces noms seraient réservés s'ils étaient utilisés sans préfixe.

4 Les noms qualifiés

Dans les documents XML conformes à cette spécification, certains noms (des structures correspondant au non-terminal Nom) DOIVENT être donnés comme noms qualifiés, définis comme suit :

Les noms qualifiés
[6]   NomQualifié   ::=   NomPréfixé
| NomSansPréfixe
[6a]   NomPréfixé   ::=    Préfixe ':' PartieLocale
[6b]   NomSansPréfixe   ::=    PartieLocale
[7]   Préfixe   ::=   NomEspCondensé
[8]   PartieLocale   ::=   NomEspCondensé

La production Préfixe fournit la partie préfixe d'espace de nommage du nom qualifié et DOIT être associée à une adresse IRI d'espace de nommage dans une déclaration d'espace de nommage. [Définition : La production PartieLocale donne la partie locale du nom qualifié.]

Remarquez que le préfixe fonctionne seulement comme paramètre de substitution pour un nom d'espace de nommage. Les applications DEVRAIENT utiliser le nom d'espace de nommage, et non le préfixe, lors de la construction de noms dont la portée déborde du document conteneur.

5 L'utilisation des noms qualifiés

Dans les documents XML conformes à cette spécification, les noms d'élément sont donnés comme noms qualifiés, comme suit :

Les noms d'élément
[9]   BaliseO   ::=   '<' NomQualifié (S Attribut)* S? '>'[CEN : Préfixe déclaré]
[10]   BaliseF   ::=   '</' NomQualifié S? '>'[CEN : Préfixe déclaré]
[11]   BaliseÉlémVide   ::=   '<' NomQualifié (S Attribut)* S? '/>'[CEN : Préfixe déclaré]

Voici un exemple de nom qualifié servant de nom d'élément :

<!-- l'espace de nommage de l'élément price est http://ecommerce.example.org/schema -->
  <edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>

Les attributs sont soit des déclarations d'espace de nommage, ou bien leurs noms sont donnés comme noms qualifiés :

Les attributs
[12]   Attribut   ::=   NomAttEspNom Égal ValeurAtt
| NomQualifié Égal ValeurAtt[CEN : Préfixe déclaré]

Voici un exemple de nom qualifié servant comme nom d'attribut :

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- l'espace de nommage de l'attribut 'classeTaxe' http://ecommerce.example.org/schema -->
  <lineItem edi:classeTaxe="exempt">Aliment pour bébé</lineItem>
</x>

Contrainte d'espace de nommage : Préfixe déclaré

Le préfixe d'espace de nommage, à moins qu'il ne s'agisse de xml ou de xmlns, DOIT avoir été déclaré dans un attribut de déclaration d'espace de nommage, soit dans la balise ouvrante de l'élément dans lequel le préfixe est utilisé, soit dans un élément ancêtre (c'est-à-dire, un élément dans le contenu duquel le balisage préfixé apparaît). En outre, la valeur d'attribut dans cette déclaration la plus intérieure NE DOIT PAS être une chaîne vide.

Cette contrainte peut conduire à des difficultés d'exploitation dans le cas où l'attribut de déclaration d'espace de nommage n'est pas fourni directement dans l'entité de document XML mais via un attribut implicite déclaré dans une entité externe. Ces déclarations peuvent ne pas être lues par un logiciel basé sur un processeur XML non validant. Beaucoup d'applications XML, y compris vraisemblablement celles sensibles aux espaces de nommage, ne demandent pas de processeurs validants. Si une exploitation correcte est exigée avec de telles applications, les déclarations d'espace de nommage DOIVENT avoir lieu soit directement, soit via des attributs implicites déclarés dans le sous-ensemble interne du DTD.

Les noms des éléments et des attributs sont aussi donnés comme noms qualifiés lorsqu'ils apparaissent dans des déclarations à l'intérieur du DTD :

Les noms qualifiés dans les déclarations
[13]   déclTypeDoc   ::=   '<!DOCTYPE' S NomQualifié (S IDExterne)? S? ('[' (déclBalisage | AppelEP | S)* ']' S?)? '>'
[14]   déclÉlément   ::=   '<!ELEMENT' S NomQualifié S specContenu S? '>'
[15]   pc   ::=   (NomQualifié | choix | séq) ('?' | '*' | '+')?
[16]   Mixte   ::=   '(' S? '#PCDATA' (S? '|' S? NomQualifié)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[17]   DéclListeAtt   ::=   '<!ATTLIST' S NomQualifié DéfAtt* S? '>'
[18]   DéfAtt   ::=   S (NomQualifié | NomAttEspNom) S TypeAtt S DéclImplicite

Remarquez que la validation fondée sur les DTD ne tient pas compte des espaces de nommage, selon le sens suivant : un DTD contraint les éléments et attributs qui peuvent apparaître dans un document par rapport à leurs noms non interprétés, et pas par des couples (espace de nommage, nom local). Pour valider un document utilisant des espaces de nommage contre un DTD, on doit utiliser les mêmes préfixes dans le DTD comme dans l'instance. Un DTD peut toutefois contraindre indirectement les espaces de nommage utilisés dans un document valide, en donnant des valeurs "#FIXED" aux attributs qui déclarent les espaces de nommage.

6 L'application des espaces de nommage aux éléments et attributs

6.1 La portée de l'espace de nommage

La portée d'une déclaration d'espace de nommage définissant un préfixe s'étend du début de la balise ouvrante, dans laquelle elle apparaît, jusqu'à la fin de la balise fermante correspondante, à l'exclusion des portées des éventuelles déclarations internes ayant la même partie NomAttEspNom. Dans le cas d'une balise vide, la portée se réduit à la balise en question.

Une telle déclaration d'espace de nommage s'applique à tous les noms d'élément et d'attribut dans son champ d'action, dont le préfixe correspond à celui spécifié dans la déclaration.

Le nom développé qui correspond à un nom d'élément ou d'attribut préfixé a, comme nom d'espace de nommage, l'adresse IRI à laquelle le préfixe est lié, et, comme nom local, la partie locale.

<?xml version="1.1"?>

<html:html xmlns:html='http://www.w3.org/1999/xhtml'>

  <html:head><html:title>Frobnostication</html:title></html:head>
  <html:body><html:p>Déplacé 
    <html:a href='http://frob.example.com'>ici.</html:a></html:p></html:body>
</html:html>

On peut déclarer plusieurs préfixes d'espace de nommage comme attributs d'un seul élément, ainsi que le montre cet exemple :

<?xml version="1.1"?>
<!-- les deux préfixes d'espace de nommage sont disponible tout du long -->
<bk:book xmlns:bk='urn:loc.gov:books'
         xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <bk:title>Cheaper by the Dozen</bk:title>
    <isbn:number>1568491379</isbn:number>
</bk:book>

La valeur d'attribut dans la déclaration d'espace de nommage d'un préfixe PEUT être vide. Cela a pour effet, dans la portée de la déclaration, de supprimer toute association du préfixe à un nom d'espace de nommage. Des déclarations postérieures PEUVENT redéfinir à nouveau le préfixe :

<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
    <n1:a/>               <!-- légal : le préfixe n1 est lié à http://www.w3.org -->
    <x xmlns:n1="">
        <n1:a/>           <!-- illégal : ici le préfixe n1 n'est pas lié -->
	<x xmlns:n1="http://www.w3.org">
            <n1:a/>       <!-- légal : le préfixe n1 est à nouveau lié -->
        </x>
    </x>
</x>

6.2 L'espace de nommage implicite

La portée de la déclaration d'un espace de nommage implicite s'étend depuis le début de la balise ouvrante, dans laquelle elle apparaît, jusqu'à la fin de la balise fermante correspondante, à l'exclusion de la portée d'éventuelles déclarations d'espace de nommage implicites internes. Dans le cas d'une balise vide, la portée se réduit à la balise en question.

Une déclaration d'espace de nommage implicite s'applique à tous les noms d'élément non préfixés dans son champ d'action. Les déclarations d'espace de nommage implicite ne s'appliquent pas directement aux noms d'attribut. L'interprétation des attributs non préfixés est déterminée par l'élément sur lequel ils apparaissent.

S'il existe une déclaration d'espace de nommage implicite dans le champ d'action, le nom développé correspondant à un élément non préfixé a comme nom d'espace de nommage l'adresse IRI de l'espace de nommage implicite. S'il n'y a aucune déclaration d'espace de nommage implicite dans le champ d'action, le nom d'espace de nommage n'a pas de valeur. Le nom d'espace de nommage d'un nom d'attribut non préfixé n'a jamais de valeur. Dans tous les cas, le nom local correspond à la partie locale (qui, bien entendu, est la même que celle du nom non préfixé en question).

<?xml version="1.1"?>
<!-- les éléments sont dans l'espace de nommage HTML implicite dans ce cas-ci -->
<html xmlns='http://www.w3.org/1999/xhtml'>
  <head><title>Frobnostication</title></head>
  <body><p>Déplacé 
    <a href='http://frob.example.com'>ici</a>.</p></body>
</html>
<?xml version="1.1"?>
<!-- les types d'élément non préfixés sont issus de "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
</book>

Un exemple plus conséquent du champ d'action d'un espace de nommage :

<?xml version="1.1"?>
<!-- au départ, l'espace de nommage implicite est "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
    <notes>
      <!-- l'espace de nommage implicite devient HTML pour un commentaire -->
      <p xmlns='http://www.w3.org/1999/xhtml'>
          C'est un livre <i>amusant</i> !
      </p>
    </notes>
</book>

La valeur d'attribut dans une déclaration d'espace de nommage implicite PEUT être vide. Cela a le même effet, dans le champ d'action de la déclaration, que l'absence d'espace de nommage implicite.

<?xml version='1.1'?>
<Beers>
  <!-- l'espace de nommage implicite à l'intérieur de la table est HTML -->
  <table xmlns='http://www.w3.org/1999/xhtml'>
   <th><td>Nom</td><td>Origine</td><td>Description</td></th>
   <tr> 
     <!-- aucun espace de nommage implicite dans les cellules de la table -->
     <td><brandName xmlns="">Huntsman</brandName></td>
     <td><origin xmlns="">Bath, UK</origin></td>
     <td>
       <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
         <pro>Houblon merveilleux, faiblement alcoolisée, bonne bière d'été</pro>
         <con>Fragile, varie excessivement d'un pub à l'autre</con>
       </details>
     </td>
   </tr>
  </table>
</Beers>

6.3 L'unicité des attributs

Dans les documents XML conformes à cette spécification, aucune balise ne peut contenir deux attributs :

  1. qui ont des noms identiques, ou

  2. qui ont des noms qualifiés avec la même partie locale et avec des préfixes liés à des noms d'espace de nommage qui sont identiques.

Cette contrainte équivaut à exiger qu'aucun élément n'ait deux attributs avec le même nom développé.

Par exemple, toutes les balises ouvrantes inexact suivantes sont illégales :

<!-- http://www.w3.org est lié à n1 et n2 -->
<x xmlns:n1="http://www.w3.org" 
   xmlns:n2="http://www.w3.org" >
  <inexact a="1"     a="2" />
  <inexact n1:a="1"  n2:a="2" />
</x>

Toutefois, toutes les déclarations suivantes sont légales, et la seconde parce que l'espace de nommage implicite ne s'applique pas aux noms d'attribut :

<!-- http://www.w3.org est lié à n1 et c'est l'espace de nommage implicite -->
<x xmlns:n1="http://www.w3.org" 
   xmlns="http://www.w3.org" >
  <exact a="1"     b="2" />
  <exact a="1"     n1:a="2" />
</x>

7 La conformité des documents

Cette spécification s'applique aux documents XML 1.1. Pour être conforme à celle-ci, un document DOIT être bien formé selon la spécification XML 1.1 [XML 1.1].

Dans les documents XML conformes à cette spécification, les noms d'élément et d'attribut DOIVENT correspondre à la production NomQualifié et DOIVENT satisfaire aux contraintes d'espace de nommage. Tous les autres atomes dans ce document, qui, pour être bien formés selon XML 1.1, sont OBLIGÉS de vérifier la production Nom de la spécification XML, DOIVENT aussi vérifier la production NomEspCondensé de la présente spécification.

[Définition : Un document est bien formé en contexte d'espace de nommage s'il est conforme à cette spécification.]

Il s'ensuit, dans un document bien formé en contexte d'espace de nommage, que 

Un document bien formé en contexte d'espace de nommage peut, en outre, être valide en contexte d'espace de nommage.

[Définition : Un document bien formé en contexte d'espace de nommage est valide en contexte d'espace de nommage s'il est valide par rapport à la spécification XML 1.1 et que tous les atomes autres que les noms d'élément et d'attribut, qui sont OBLIGÉS, pour la validité avec XML 1.1, de vérifier la production Nom de la spécification XML, vérifie aussi la production NomEspCondensé de la présente spécification.]

Il s'ensuit, dans un document valide en contexte d'espace de nommage, que :

8 La conformité des processeurs

Pour être conforme à cette spécification, un processeur DOIT signaler les violations aux contraintes de format dans le contexte d'un espace de nommage, sauf vérifier si les noms des espaces de nommage sont des adresses IRI légales, ce qui n'est pas OBLIGATOIRE.

[Définition : Un processeur XML validant conforme à cette spécification est validant d'espace de nommage si, en plus, il signale les violations de validité de l'espace de nommage.]

9 Les identificateurs de ressource internationnalisés (IRI)

La production d'un document RFC définissant les identificateurs de ressource internationnalisés (IRI) fait toujours l'objet de travaux. Puisque ces travaux ne sont pas encore terminés, ce chapitre donne une définition syntaxique des adresses IRI pour les besoins de cette spécification. Le groupe de travail XML Core prévoit de faire un amendement remplaçant ce chapitre par une référence au document RFC quand celui-ci sera publié.

On conseille aux utilisateurs définissant des espaces de nommage de restreindre les noms d'espace de nommage aux adresses URI jusqu'à ce que le document RFC soit publié et les logiciels puissent interpréter couramment les adresses IRI. De la même façon, on conseille aux développeurs de ne pas rejeter les noms d'espace de nommage qui violeraient les versions préliminaires relativement aux caractères admis.

Pour une définition plus générale et des discussions au sujet des adresses IRI, voir le document [IRI draft 5] (travail en cours).

Les adresses URI se restreignent à un sous-ensemble du jeu de caractères ASCII, tandis que les adresses IRI autorisent la plupart des caractères Unicode, à commencer par le caractère #xA0. Les versions préliminaires précédentes du document RFC traitant des adresses IRI (par exemple, [IRI draft 3]) autorisaient aussi certains des caractères ASCII interdits, au contraire de la version courante ([IRI draft 5]).

[Définition : Les caractères supplémentaires permis dans les adresses IRI par la version [IRI draft 5] comprennent :]

[Définition : Une adresse IRI est une chaîne de caractères convertible en une adresse URI en suivant les étapes suivantes :]

  1. Convertir la partie nom d'hôte, le cas échéant, en effectuant l'opération ToASCII spécifiée au chapitre 4.1 du document [RFC3490] avec les drapeaux UseSTD3ASCIIRules et AllowUnassigned mis sur TRUE.

  2. échapper tous les caractères supplémentaires comme suit :

    1. Chaque caractère supplémentaire est converti vers le codage UTF-8 [RFC3629] sur un ou plusieurs octets

    2. Les octets résultants sont échappés selon le mécanisme d'échappement des adresses URI (c'est-à-dire convertis en %HH, où HH représente la notation hexadécimale de la valeur d'octet).

    3. Le caractère original est remplacé par la séquence de caractères résultante.

Remarque :

L'algorithme de la version [IRI draft 5] comporte une étape de normalisation UCS, mais cela ne fait aucune différence pour les chaînes qui sont des adresses IRI.

A Références normatives

Keywords
RFC 2119 : Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'obligation, S. Bradner, ed. IETF (Internet Engineering Task Force), mars 1997. Disponible à http://www.rfc-editor.org/rfc/rfc2119.txt
RFC2141
RFC 2141 : La syntaxe URN, R. Moats, ed. IETF (Internet Engineering Task Force), mai 1997. Disponible à http://www.rfc-editor.org/rfc/rfc2141.txt.
RFC2396
RFC 2396 : Les identificateurs de ressource uniformes (URI) : syntaxe générique, T. Berners-Lee, R. Fielding, and L. Masinter, eds. IETF (Internet Engineering Task Force), août 1998. Disponible à http://www.rfc-editor.org/rfc/rfc2396.txt
RFC2732
RFC 2732 : Format des adresses littérales IPv6 dans les URL, R. Hinden, B. Carpenter, and L. Masinter, eds. IETF (Internet Engineering Task Force), décembre 1999. Disponible à http://www.rfc-editor.org/rfc/rfc2732.txt.
RFC3490
RFC 3490 : Internationalisation des nom de domainde dans les applications (IDNA), P. Faltstrom, P. Hoffman, and A. Costello, eds. IETF (Internet Engineering Task Force), mars 2003. Disponible à http://www.rfc-editor.org/rfc/rfc3490.txt
RFC3629
RFC 3629 : UTF-8, un format de transformation de ISO 10646, F. Yergeau, ed. IETF (Internet Engineering Task Force), novembre 2003. Disponible à http://www.rfc-editor.org/rfc/rfc3629.txt
XML
Le langage de balisage extensible (XML) 1.0 (Troisième édition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler et François Yergeau eds. W3C (World Wide Web Consortium), 4 février 2004. Disponible à http://www.w3.org/TR/REC-xml.
XML 1.1
Le langage de balisage extensible (XML) 1.1 vf, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler et John Cowan eds. W3C (World Wide Web Consortium), 4 février 2004. Disponible à http://www.w3.org/TR/xml11.

B Autres références (non normatif)

IRI draft 3
Les identificateurs de ressource internationnalisés (IRI), M. Duerst et M. Suignard eds., 2 mars 2003. Disponible à http://www.w3.org/International/iri-edit/draft-duerst-iri-03.txt.
IRI draft 5
Les identificateurs de ressource internationnalisés (IRI), M. Duerst et M. Suignard eds., 26 octobre 2003. Disponible à http://www.w3.org/International/iri-edit/draft-duerst-iri-05.txt.
1.0 Errata
Errata des espaces de nommage dans XML. W3C (World Wide Web Consortium). Disponible à http://www.w3.org/XML/xml-names-19990114-errata.
Contre-indication des adresses URI relatives
Résultats du vote plénier XML du W3C au sujet des adresses URI relatives dans les déclarations d'espace de nommage 3-17 juillet 2000, Dave Hollander et C. M. Sperberg-McQueen, 6 septembre 2000. Disponible à http://www.w3.org/2000/09/xppa.
Requirements
Les nécessités des espaces de nommage dans XML 1.1, Jonathan Marsh, ed. W3C (World Wide Web Consortium), mars 2002. Disponible à http://www.w3.org/TR/2002/WD-xml-names11-req-20020403/.

C La structure interne des espaces de nommage XML (non normatif)

Cette annexe est supprimée.

D Les changements depuis la version 1.0 (non normatif)

Cette version incorpore les corrections d'erreur de la version 1.0 en date du 6 décembre 2002 [1.0 Errata]. Deux changements importants viennent s'y ajouter :

Plusieurs changements rédactionnels ont été effectués, dont un certain nombre ayant trait à la terminologie et des ajouts destinés à améliorer la cohérence. L'annexe non normative La strucutre interne des espaces de nommage XML a été supprimée.

E Remerciements (non normatif)

Ce travail reflète les suggestions d'un très grand nombre de personnes, comprenant en particulier les participants du groupe de travail et du groupe d'intérêts spécial XML du World Wide Web Consortium et les participants de l'activité Métadonnées du W3C. Les contributions de Charles Frankston de Microsoft ont été particulièrement précieuses.