Les espaces de nommage dans XML 1.1

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é">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">

À 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 :

qui ont des noms identiques, ou
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

Tous les noms d'élément et d'attribut contiennent zéro ou un caractère deux-points (:) ;
Aucun nom d'entité, aucune cible d'instruction de traitement ou aucun nom de notation ne contient de caractère deux-points.

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 :

Aucun attribut dont le type déclaré est ID, IDREF(S), ENTITY(IES) ou NOTATION ne contient de caractère deux-points (:).

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 :]

les caractères Unicode du Plan 0 #xA0-#xD7FF, #xF900-#xFDCF et #xFDF0-#xFFEF
les caractères Unicode des Plans 1 à 14 #x10000-#x1FFFD ... #xD0000-#xDFFFD, #xE1000-#xEFFFD

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

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.
é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.

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

Statut du document traduit

Avertissement

Notes sur la traduction

Archives compressées et autres formats

Autres documents traduits

Avis légal

Les espaces de nommage dans XML 1.1

Recommandation du W3C du 4 février 2004

Résumé

Statut de ce document

Table des matières

Annexes