Lisez-moi S.V.P. 

W3C

Le manuel de style du W3C

Une aide pour les rédacteurs et les auteurs des rapports techniques du W3C

Le crayon rouge et bleu du rédacteur

Cette version :
http://www.w3.org/2001/06/manual
Rédacteur :
Susan Lesch, W3C
Auteurs et contributeurs :
Cf. le chapitre Remerciements

Copyright © 1995-2004 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de nom de marque, d'utilisation des documents et d'octroi de licences de logiciels du W3C s'appliquent. Vous interagissez avec ce site conformément à notre politique de confidentialité vis-à-vis du public et de nos membres.

Statut de ce document

Voici le manuel de style du W3C qui s'appuie sur le document How to Write a W3C Technical Report (lien réservé aux membres du W3C). Ce manuel constitue un guide des bons usages actuels. Ce document ne contient aucune obligation concernant les publications du W3C. Toutes les obligations se trouvent dans le document W3C Publication Rules [PUBRULES].

Des ressources utiles aux rédacteurs et aux auteurs sont proposées sur W3C Editors Home Page [EDITORS]. Des notes concernant la gestion des documents sont mises à disposition [MANAGE]. En cas de doute, demandez de l'aide sur la liste de diffusion publique spec-prod@w3.org [SPEC-PROD].

Le manuel de style du W3C est le fruit d'un travail continu, et il peut être mis à jour, remplacé ou rendu obsolète à tout moment. Veuillez envoyer vos remarques à la liste de diffusion publique spec-prod@w3.org (archives). Le rédacteur accepte également les courriers privés à lesch@w3.org. Si pour une raison quelconque vous souhaitez que votre contribution ne soit pas mentionnée dans la rubrique Remerciements, veuillez le préciser dans votre message.

Dernière modification : $Date: 2005/11/21 02:51:41 $

Table des matières

1. Introduction

Écrit à l'intention des rédacteurs et auteurs des rapports techniques du W3C, ce document suppose du lecteur qu'il maîtrise la publication sur le site Web du W3C et qu'il ait une bonne connaissance du guide de style Style Guide for Online Hypertext [STYLE-GUIDE]. Il accompagne le document OBLIGATOIRE Les règles de publication du W3C [PUBRULES], abrégé en pubrules. Le respect des conseils prodigués par ce manuel offre des avantages :

Le chapitre 2 traite de la validation, les chapitres 3 et 4 traitent de l'accessibilité et de l'internationalisation, le chapitre 5 décrit les parties d'un rapport technique du W3C, les chapitres 6, 7 et 8 couvrent l'errata, les références et les révisions, le chapitre 9 introduit XMLspec et XSLT, le chapitre 10 aborde les mots-clés du document RFC 2119, le chapitre 11 présente un guide de rédaction et enfin le chapitre 12 donne des fautes d'othographe courantes.

Veuillez garder à l'esprit que vos rapports seront utilisés comme matériel de référence principal à l'échelle mondiale. La lisibilité sur une grande diversité de navigateurs et de plates-formes est beaucoup plus importante que des caractéristiques tapageuses. D'une certaine manière, ce que nous rédigeons devient histoire et demeure sur le Web au travers de la politique de persistence du W3C [PERSISTENCE].

2. La validation

Remarque : Le rédacteur a le devoir de s'assurer de la validité des documents avant de demander leur publication.

3. L'accessibilité

4. L'internationalisation

Suivez les travaux en cours du W3C sur Un modèle de caractères pour le World Wide Web 1.0 : Les principes de base [CHARMOD]. Votre spécification définit-elle des protocoles ou des éléments de formatage ? Si c'est le cas, définissez le moment où interviendra la conversion des caractères des appels d'adresse URI en caractères valides, et faites qu'elle ait lieu le plus tard possible.

4.1 Unicode

Pour la définition des caractères, reportez-vous au document Le standard Unicode ; cf. le chapitre 8 de Un modèle de caractères pour le World Wide Web 1.0 : Les principes de base [CHARMOD]. Le consortium Unicode donnent des instructions sur la façon de citer leurs standards (cf. [UNICODE]). Citez les caractères seuls des trois façons suivantes ; cf. le fil de discussion intitulé Les noms des caractères Unicode [CHARNAMES] :

  1. Au moyen d'un point de code (par exemple, U+002E) ;
  2. Au moyen d'un nom Unicode formel (par exemple, point final) ; cf. [CHARTS]
  3. Au moyen d'un alias Unicode (par exemple, point, ou point décimal, ou point ; cf. [CHARTS]

4.2 Les traductions

Le W3C ne propose pas de traductions officielles de ses rapports techniques. Le W3C encourage les traductions de ces rapports techniques et offre une aide pour rechercher les traducteurs et les traductions.

Bien que les rapports techniques soient rédigés en anglais américain, les exemples et le choix des mots ne devraient pas s'appuyer sur les conventions et les idiomes spécifiques des États-Unis (par exemple, code ZIP). Employez des exemples internationaux (par exemple, code postal) autant que possible.

Rendez votre spécification plus lisible en recourant à un balisage permettant de distinguer les mots communs des mots-clés de votre langage. Balisez toutes leurs apparitions. Par exemple :

L'attribut title de ces éléments
peut servir à fournir la forme
entière ou développée de l'expression.

Et ce qu'il faudrait faire :

L'attribut <code>title</code> de ces éléments
peut servir à fournir la forme
entière ou développée de l'expression.

Un traducteur français saura alors qu'il ne doit pas traduire title par titre.

On ne devrait pas employer de pronoms personnels à la première personne (je, nous) dans le texte des exemples, car ils sont difficiles à traduire. Cf. le message Les pronoms personnels dans les spécifications [PRONOUNS]. Évitez aussi les my et les me dans les exemples (par exemple, utilisez userResource plutôt que myResource).

De même, les spécifications ne devraient pas s'adresser directement aux lecteurs. La traduction des pronoms personnels singuliers à la deuxième personne est une tâche ardue si la langue distingue entre un usage formel et un usage informel ; évitez-donc les you.

N'inventez pas d'éléments en substitution des mots de la langue naturelle. Par exemple, ne recourrez pas à <must/> avec une feuille de style pour faire MUST. D'autres langues peuvent exiger un accord avec le sujet de la phrase. En français, par exemple, MUST deviendra DOIT, pour un sujet au singulier, et DOIVENT, au pluriel. Employez plutôt le balisage standard.

4.3 Le style des dates

Dans un contexte international, l'expression 5/6/03 pour indiquer une date est ambiguë (elle pourra signifier le 6 mai ou bien le 5 juin). Écrivez le mois en entier (6 mai 2003) ou bien employez une forme dérivée de la norme ISO-8601 (2003-05-06). La spécification Schéma XML tome 2 : Les types de données ([SCHEMA-DATATYPES], sections 3.2.9 jusqu'à 3.2.14.1) décrit l'écriture formelle des dates dans les documents XML.

5. Les parties d'un rapport technique

À compter de novembre 2005, les règles de publication (pubrules) comportent un modèle de rapport technique.

5.1 Le titre du document

Le titre de votre document, dans son en-tête et dans l'index des rapports techniques [TR], aura la forme suivante (les éléments optionnels entre crochets) :

Titre [(ABRÉVIATION)] ["Specification"] ["Part" numéro_de_partie] [ : Sous-titre] ["Module"] [(nth "Edition")] ["Version" numéro_de_version]

Cf. les règles de publication pour des précisions sur l'utilisation de version et edition. Les termes level et revised sont à éviter. Essayez de respecter la convention de titrage.

Mettez en capitale la première lettre des mots du titre selon l'usage américain.

5.2 Les rédacteurs et les auteurs

5.2.1 Les changements d'affiliations

Les affiliations des rédacteurs/auteurs changent au cours du temps. Voici des exemples illustrant l'approche suggérée pour les gérer :

Rédacteur actuel
Richard Ishida, W3C (and before at Xerox)
François Yergeau, Invited Expert (and before at Alis Technologies)
Jane Doe, MyCompany (and before at ThierCompany, and at HisCompany, and at HerCompany)
Rédacteur précédent
Martin J. Dürst (until Dec 2004 while at W3C)
Misha Wolf (until Dec 2002 while at Reuters Ltd.)
Tex Texin (until Dec 2004 while an Invited Expert, and before at Progress Software)
FitzChivalry Farseer (until Oct 2005 while at AnyCompany, and before at ThisCompany, and at ThatCompany)

5.3 Le résumé

Faites un résumé de chaque document (quelques paragraphes tout au plus) qui présente ce dont il est question dans le document. Le service des communications de l'Équipe peut utiliser tout ou une partie du résumé pour faire la publicité de votre travail. Écrivez-le pour un public de non spécialistes.

5.4 La section de statut

La section statut de ce document décrit le statut du document et le contexte de publication à la date de publication. Les règles de publication précisent les conditions requises pour la section de statut de chaque type de rapport technique (par exemple, l'emploi de textes personnalisés ou passe-partout).

Puisque la section de statut ne change pas avec le temps, exprimez-la dans des termes qui resteront valides par la suite (par exemple, évitez les mots comme nouveau). Indiquez la stabilité prévue pour le document tout en reconnaissant une incertitude pour le futur. Les lecteurs ont la responsabilité de s'informer sur le dernier statut (par exemple, en suivant le lien vers la dernière version ou en consultant l'index des rapports techniques du W3C [TR].

Le paragraphe personnalisé est très important dans la mesure où il contient effectivement des renseignements ! Vous devriez y indiquer à quoi une partie des efforts du groupe ont été consacrés. Ce paragraphe devrait décider un lecteur au point de penser Je devrais vraiment lire cette ébauche Cela implique de ne pas le recopier d'un autre document. Il devrait être singulier au document en question.

Tim Berners-Lee présentait la fonction du paragraphe personnalisé ainsi : N'ayez pas peur d'être honnête à propos de la situation techno-politique pertinente. Dans le paragraphe personnalisé, dites les raisons pour lesquelles quelqu'un devrait le lire.

Placez-y les réponses que vous donneriez à un membre ou à un collègue posant les questions suivantes :

5.4.1 Les notes des groupes de travail/d'intérêts/de coordination

Une note de groupe de travail, de groupe d'intérêts ou de groupe de coordination du W3C inclut les deux phrases suivantes, qui indiquent le niveau d'engagement au sein du W3C :

Ce document est une note de [groupe de travail/d'intérêts/de coordination] mise à disposition par le W3C dans un but de discussion seulement. La publication de cette note par le W3C n'implique pas une caution du W3C, y compris de l'Équipe et de l'ensemble des membres.

(N.D.T. This document is a [Working Group, Interest Group, Coordination Group] Note made available by W3C for discussion only. Publication of this Note by W3C does not imply endorsement by W3C, including the Team and Membership.)

Si le W3C n'a alloué aucune ressource au groupe de travail/d'intérêts/de coordination, alors inclure une déclaration dans la section de statut du genre :

Aucune ressource du W3C n'a été, n'est ou ne sera allouée aux questions traitées par cette note de [groupe de travail/d'intérêts/de coordination] du W3C.

Si la note de groupe de travail/d'intérêts/de coordination n'est pas préparée ni éditée par l'Équipe, inclure une déclaration dans la section de statut du type :

L'Équipe du W3C n'a exercé aucune contrôle de rédaction sur la préparation de cette note de [groupe de travail/d'intérêts/de coordination] du W3C.

6. La liste des errata

Toutes les recommandations comportent des erreurs. C'est pourquoi elles sont reliées à une page d'errata qui évolue au cours du temps. Puisque la page d'errata évolue et non la version spécifique d'une recommandation, placez la page d'errata en dehors de la hiérarchie /TR. Les documents dans la zone TR ne sont pas censés évoluer dans le temps [PERSISTENCE]. Par exemple, placez les pages d'errata dans la portion d'espace Web dédiée au groupe de travail ou à l'activité concernés.

Indiquez clairement sur la page d'errata :

Par exemple (présenté ici sans liens) :

This document:
http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata
Last revised:
$Date: 2005/11/21 02:51:41 $
This document records known errors in the document:
http://www.w3.org/TR/1998/REC-CSS2-19980512
The latest version of the CSS 2 Recommendation:
http://www.w3.org/TR/REC-CSS2

Listez les entrées les plus récentes au début de la page d'errata.

Les entrées dans une page d'errata

Pour chaque entrée dans la page d'errata, fournissez :

  1. Un identificateur unique ;
  2. La date d'apparition dans la page d'errata ;
  3. Une classification de l'erreur (par exemple, erreur de rédaction, éclaircissement, bogue, problème connu avec le document même) ;
  4. Une description brève du problème et la partie de la recommandation qui en est affectée ;
  5. Les éventuelles corrections proposées et si ces corrections affectent ou non la conformité des documents ou des logiciels ;
  6. Les éventuelles corrections normatives ; cf. le chapitre La gestion des erreurs dans le Document de processus du W3C ([PROCESS] section 7.6.1) pour des précisions sur les corrections normatives.

Ne retirez aucune entrée de la page d'errata ; si une correction s'avérait inexacte, ajoutez simplement une autre entrée (avec une référence croisée).

7. Les références

7.1 L'extracteur de bibliographie

L'extracteur de bibliographie du W3C (N.D.T. W3C Bibliography Extractor) [BIB-EXTRACT] générera automatiquement une liste de références dans le style du W3C.

7.2 Les citations

Les liens de références (par exemple, [XML]) mènent au chapitre concernant la bibliographie et ils prennent la forme suivante :

<cite><a href="http://www.example.org/example">Intitulé entier</a></cite> [<cite><a href="#ref-NOMREF">NOMREF</a></cite>]

On peut omettre les parenthèses autour des crochets, à moins que la référence ne contienne un numéro de section.

Les liens de références apparaissent au minimum à la première mention de la source. Écrivez en toutes lettres à quoi le lien de référence correspond, au moins à la première apparition. Par exemple, écrivez :

Ceci est traité dans Les espaces de nommage dans XML [XMLName].

Ou encore :

Ceci est traité dans la spécification des espaces de nommage XML [XMLName].

Mais pas :

Ceci est traité dans [XMLName].

7.3 La citation d'une référence externe depuis le document

Pour un lien depuis le document vers une ressource externe :

  1. Assurez-vous que le texte, le titre et le contexte du lien signalent une sortie du document, et ;
  2. À la suite du lien, donnez un lien de référence vers le chapitre des références et indiquez la section, la page ou toutes choses utiles les concernant au cas où le lien ne serait pas disponible (par exemple, si le document est imprimé).

Ainsi, par exemple :

[...] comme pour la propriété 'page' de CSS2 ([CSS2], section 13.3.2).

7.4 La section des références

7.5 Les références normatives et informatives

Les références normatives devraient désigner des ressources stables et matures (par exemple, uniquement des recommandations).

8. Les révisions

Cf. le Document de processus du W3C ([PROCESS] section 7.6) pour des instructions sur les modalités de révision d'un rapport technique.

Remarque : Lorsqu'un document est révisé, la date de publication originale reste la même (tout comme dans l'index des rapports techniques [TR]) ; cf. les règles de publication pour des précisions.

Veillez à ne pas rompre de liens au cours des révisions. Si votre document utilise les adresses URI des dernières versions avec un identificateur de fragment, les liens se rompront, sauf si les ancres sont conservées d'une version à l'autre.

9. XML, XMLspec, XSLT et la production

Même si les versions HTML ou XHTML de votre spécification sont toujours les versions définitives, beaucoup de rédacteurs estiment plus facile de travailler avec un original au format XML, et donc une version XML est parfois fournie comme format alternatif. La définition de type de document (DTD) de la spécification XML du W3C (XMLspec), utilisée pour produire nombre de recommandations apparentées XML du W3C, peut faciliter cette tâche. La spécification XMLspec est entièrement documentée [XMLSPEC]. Des feuilles de style XSLT diverses sont en vigueur et sont continuellement développées pour une sortie du rapport technique final [XSLT]. Pour une assistance dans ce processus, vous pouvez demander aux experts sur la liste de diffusion publique spec-prod@w3.org [SPEC-PROD].

10. Les mots-clés du document RFC 2119

Respectez et citez le document RFC 2119 Les mots-clés à utiliser dans les documents RFC pour indiquer les niveaux d'obligation [KEYWORDS] (par exemple, DOIT, NE DOIT PAS, OBLIGATOIRE).

Lorsque ces mots-clés sont employés au sens du RFC, écrivez-les en majuscules, placez-les dans un élément em et donnez leur un style à l'aide d'un feuille de style CSS pour améliorer la lisibilité des MAJUSCULES.

<em title="DOIT dans le contexte du RFC 2119"
       class="RFC2119">DOIT</em>

.RFC2119 {
  text-transform: lowercase;
  font-style: italic;
}

L'auteur peut indiquer, le cas échéant, les raisons pour lesquelles il n'emploie pas ces mots-clés au sens du document RFC.

Lorsqu'ils ne sont pas obligatoires pour le propos ou qu'il faut limiter un comportement susceptible d'être dommageable, ces mots-clés ne doivent pas être employés pour essayer d'imposer une méthode particulière aux développeurs dès lors que la méthode n'est pas obligatoire pour l'interopérabilité.

11. Le guide de rédaction

Ce chapitre est consacré aux conventions d'écriture au sein du W3C. Il traite de la grammaire, de l'orthographe, de la ponctuation, de la casse, des liens, de l'aspect et du balisage.

11.1 La grammaire

11.2 L'orthographe

11.3 La ponctuation

11.4 La casse, les mots-composés et les césures

11.5 Divers

11.6 Les liens

11.7 L'utilisation des exemples

11.8 Les images

11.9 Le balisage

11.10 Les documents volumineux

Les fichiers uniques et volumineux qui sont peut-être facile à imprimer et explorer le sont peut-être moins à télécharger. En ce qui concerne les documents volumineux :

12. Les fautes d'orthographe courantes

Le W3C révise ses rapports techniques un par un, depuis novembre 1999, à la recherche de coquilles. Les mots suivants apparaissent souvent au cours de ces révisions et on peut facilement se tromper sur leur orthographe.

anti-alias
mettre un trait d'union
ASCII
tout en majuscules
base64
en minuscules, en un seul mot
Bézier
toujours avec une majuscule initiale et un accent sur le premier e
braille
majuscule initiale seulement lorsqu'il s'agit de Louis Braille
built-in
mettre un trait d'union lorsqu'employé comme adjectif ou comme nom, pas comme un verbe
dingbat
en un seul mot
DTDs
pas d'apostrophe (cf. [PLURAL])
ECMAScript
en un seul mot, S majuscule
et al.
pas de point final après et
full stop (.)
Le terme full stop (N.D.T. point final) est le nom formel. Les termes dot (N.D.T. point) et period (N.D.T. point) constituent des synonymes acceptables.
heading
Le terme associé aux éléments h1-h6. Le termes headers se rapporte aux tables HTML (N.D.T. rubriques) comme au protocole HTTP (N.D.T. en-têtes).
HTTP/1.0
nécessite une barre oblique quand il s'agit du protocole, rien dans un texte normal
HTTP/1.1
nécessite une barre oblique quand il s'agit du protocole, rien dans un texte normal
home page
en deux mots
Java
J majuscule
JavaScript
S majuscule
Level 1, 2, 3
L majuscule quand se rapporte à un rapport technique du W3C
line feed
en deux mots
lowercase
en un mot
markup
en un mot
MIME type
en deux mots, MIME tout en majuscules
namespace
en minuscules, à moins qu'il ne s'agisse du nom de la spécification Namespaces in XML
number sign (#)
normalement sans le croisillon
on-line
mettre un trait d'union
PDF
tout en majuscules
PostScript
S majuscule
read-only
mettre un trait d'union
ruby
en minuscules
schema
en minuscules
schemas
préféré à schemata
semicolon
en un seul mot
stand-alone
mettre un trait d'union
style sheet
en deux mots
subset
pas de trait d'union
superset
pas de trait d'union
uppercase
en un seul mot
URI reference
normalement pas URI Reference ni URI-Reference
URIs
pas d'apostrophe (cf. [PLURAL])
user agent
en minuscules
user interface
en minuscules
Web
toujours avec majuscule initiale
Webmaster
en un seul mot, majuscule initiale
Web page
en deux mots, majuscule initiale pour Web
Web site
en deux mots, majuscule initiale pour Web (cf. [GRM])
well-formed
mettre un trait d'union
white space
en deux mots
worldwide
en un seul mot
World Wide Web
en trois mots, pas de trait d'union
W3C Note
pas W3C NOTE

13. Remerciements

Merci à Karl Dubost (W3C). Merci à Philip Gallo pour l'image du crayon, et à Paul Harmon et E.K. pour la maquette utilisée dans les versions précédentes. Les personnes suivantes ont contribué à cette compilation :

14. Références

[AH]
American Heritage® Dictionary, 4th Edition. Houghton Mifflin Company, 2000. Ce livre est en ligne à http://www.bartleby.com/61.
[BIB-EXTRACT]
W3C Bibliography Extractor, Dominique Hazaël-Massieux, 2003. Cet outil est en ligne à http://www.w3.org/2002/01/tr-automation/tr-biblio-ui.
[CHARMOD]
Un modèle de caractères pour le World Wide Web 1.0 : Les principes de base, M. Dürst, F. Yergeau, R. Ishida, M. Wolf et T. Texin, rédacteurs. Travaux en cours au W3C, 2004. Cette version du modèle de caractères : Les principes de base se trouve à http://www.w3.org/TR/2004/WD-charmod-20040225/. La dernière version du modèle de caractères : Les principes de base est disponible à http://www.w3.org/TR/charmod.
[CHARNAMES]
Les noms des caractères Unicode, M. Davis, M. Dürst, et al., 25-27 août 2001. Le fil de cette discussion électronique est en ligne à http://lists.w3.org/Archives/Public/www-international/2001JulSep/thread.html#133.
[CHARTS]
À propos des tableaux de code en ligne, The Unicode Standard, Version 1.1 ou ultérieure. The Unicode Consortium, 2001. Les tableaux de code Unicode sont en ligne à http://www.unicode.org/charts/About.html.
[CHECKLINK]
Le vérificateur de liens du W3C, H. Haas. W3C, 2000-2001. Ce service est en-ligne à http://www.w3.org/2000/07/checklink.
[CLICK-HERE]
N'utilisez pas cliquez ici comme texte d'un lien, Aaron Swartz. W3C QA Team, 2001. Cette astuce des questions-réponses est en ligne à http://www.w3.org/QA/Tips/noClickHere.
[COPYRIGHT1]
La notice de droits d'auteur du W3C, W3C MIT/INRIA/Keio, 1994-2004. La dernière version de cette notice est en ligne à http://www.w3.org/Consortium/Legal/ipr-notice#Copyright.
[COPYRIGHT2]
La licence d'utilisation des documents du W3C, W3C MIT/INRIA/Keio, 1994-2004. Cette notice est en ligne à http://www.w3.org/Consortium/Legal/copyright-documents-19990405.
La licence d'utilisation des logiciels du W3C, W3C MIT/INRIA/Keio, 1994-2004. Cette notice est en ligne à http://www.w3.org/Consortium/Legal/copyright-software-19980720.
[CSSVALIDATE]
Le service de validation CSS du W3C, W3C QA Activity, 1997-2004. Ce service est en ligne à http://jigsaw.w3.org/css-validator.
[DOMAINS]
Les noms DNS réservés de premier niveau, D. Eastlake et A. Panitz. The Internet Society, juin 1999. Ce document RFC est disponible à http://www.ietf.org/rfc/rfc2606.txt.
[EDITORS]
La page d'accueil des rédacteurs du W3C, Dominique Hazaël-Massieux pour le service des communications du W3C, 2003. Cette liste de ressources pour les rédacteurs est en ligne à http://www.w3.org/2003/Editors/.
[EVALUATE]
Les outils d'évaluation, W3C, 1997-2000. Cette liste d'outils d'évaluation de l'accessibilité des sites Web est en ligne à http://www.w3.org/WAI/ER/existingtools.html#Evaluation.
[GRM]
Les questions usuelles, The Gregg Reference Manual Instructor Site, Glencoe/McGraw-Hill, 2000. Cette foire aux questions est en ligne à http://www.glencoe.com/ps/grm/faqs.
[HOW-TO]
How to put information on the web, K. MacArthur. W3C, 1995. Ce guide est archivé à http://www.w3.org/Provider.
[IPRFAQ]
Intellectual Property FAQ, W3C, 20 juin 2000. La dernière version de ce document est à http://www.w3.org/Consortium/Legal/IPR-FAQ.
[KEYWORDS]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. The Internet Society, mars 1997. Ce document RFC est disponible à http://www.ietf.org/rfc/rfc2119.txt.
[M-W]
Merriam-Webster OnLine: Collegiate Dictionary, 10th Edition. Merriam-Webster, Incorporated, 2000. Ce livre est en ligne à http://www.m-w.com.
[MANAGE]
Document Management for Web Specs, D. Connolly. W3C, 1995-1999. Ce guide est en ligne à http://www.w3.org/MarkUp/SGML/spec-mgmt.
[PERSISTENCE]
La politique de persistence, T. Berners-Lee, 1999. Cette politique est en ligne à http://www.w3.org/Consortium/Persistence.
[PLURAL]
Infrequently Asked Questions Concerning the Proper Spelling of 'DTD' in its Plural Form, R. Cover, mis à jour le 4 janvier 2001 et ensuite. Ce document est en ligne à http://xml.coverpages.org/properSpellingForPluralOfDTD.html.
[PROCESS]
Le Document de processus du W3C, I. Jacobs, rédacteur. W3C, 5 février 2004. La dernière version de ce document est à http://www.w3.org/Consortium/Process.
[PRONOUNS]
Personal pronouns in specifications, M. Dürst, 13 mai 2000. Cette correspondance électronique est à http://lists.w3.org/Archives/Public/www-international/2000AprJun/0058.
[PUBRULES]
Les règles de publication, I. Jacobs et l'Équipe du W3C. W3C, 2000-2003. Ce document est en ligne à http://www.w3.org/Guide/pubrules.
[REF-TITLES]
please use titles, not addresses, as link text, D. Connolly, 10 février 2000. Cette correspondance électronique est en ligne à http://lists.w3.org/Archives/Public/www-html-editor/2000JanMar/0103.
[SAMPLE]
L'exemple de recommandation (lien réservé aux membres du W3C), H. W. Lie et B. Bos. W3C, 1 avril 1999. Ce document est en ligne à http://www.w3.org/StyleSheets/TR/REC-sample.
[SPEC-PROD]
spec-prod@w3.org. W3C, 1998-2001. S'inscrire à cette liste de diffusion publique à http://www.w3.org/Mail/Lists et en consulter les archives à http://lists.w3.org/Archives/Public/spec-prod.
[STYLE-GUIDE]
Style Guide for Online Hypertext, T. Berners-Lee. 1992-1998. Ce guide est en ligne à http://www.w3.org/Provider/Style.
[TR]
Les rapports techniques et les publications du W3C, W3C, 1995-2001. Cette page Web est en ligne à http://www.w3.org/TR.
[TRANSLATE]
Les traductions au W3C, W3C, 1997-2003. Cette page Web est en ligne à http://www.w3.org/Consortium/Translation.
[UNICODE]
Citations and References, The Unicode Consortium, 2001. Ces instructions pour citer le standard Unicode sont en ligne à http://www.unicode.org/unicode/standard/versions/.
[VALIDATE]
Le service de validation HTML du W3C, W3C QA Activity, 1997-2004. Ce service est en ligne à http://validator.w3.org.
[WCAG]
Les directives pour l'accessibilité du contenu Web 1.0, W. Chisholm, G. Vanderheiden et I. Jacobs, rédacteurs. W3C, 1999. Cette version de la recommandation WCAG est celle à http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. La dernière version de la recommandation WCAG est disponible à http://www.w3.org/TR/WAI-WEBCONTENT.
[XHTML1]
XHTMLTM 1.0 : le langage de balisage hypertexte extensible, S. Pemberton et al. W3C, 2000. Cette version de XHTML est à http://www.w3.org/TR/2000/REC-xhtml1-20000126. La dernière version de XHTML1XHTML1 est disponible à http://www.w3.org/TR/xhtml1.
[XMLSPEC]
Un guide du DTD de la spécification XML (XMLSpec) du W3C, version 2.1, E. Maler, rédacteur. W3C, 1997-2001. Cette documentation est en ligne à http://www.w3.org/XML/1998/06/xmlspec-report-v21. Le DTD est en ligne à http://www.w3.org/XML/1998/06/xmlspec-v21.dtd.
[XSLT]
Les feuilles de style XSLT, N. Walsh et al. 2000-2001. Ces feuilles de style XSLT pour XMLspec sont en ligne à http://dev.w3.org/cvsweb/spec-prod/html.

Les liens extérieurs

Les liens dans le texte pour illustration se rapportent aux références suivantes. Elles sont informatives et ne sont listées ici que pour être imprimées.

[CSS2]
Les feuilles de style en cascade niveau 2, section 13.3.2, B. Bos, H. W. Lie, C. Lilley et I. Jacobs, rédacteurs. W3C, 1998. Cet exemple est en ligne à http://www.w3.org/TR/1998/REC-CSS2-19980512/page.html#named-pages.
[EXCAL]
Excalibur, R. Zaccone, 2001. La page d'accueil d'Excalibur est à http://www.eg.bucknell.edu/~excalibr/excalibur.html.
[HTML]
Une présentation de HTML 3.2. W3C, 1996-1999. Cet exemple est en ligne à http://www.w3.org/MarkUp/Wilbur.
[ISPELL]
International Ispell, G. Kuenning et al. 1971-2001. La page d'accueil pour Ispell est à http://fmg-www.cs.ucla.edu/fmg-members/geoff/ispell.html.
[P3PFAQ]
Les questions usuelles à propos de P3P et de la confidentialité. W3C, 2000-2001. Cet exemple est en ligne à http://www.w3.org/P3P/p3pfaq.
[SCHEMA-DATATYPES]
XML Schema tome 2 : Les types de données, sections 3.2.9 à 3.2.14.1, P. V. Biron et A. Malhotra, rédacteurs. W3C, 2001. La dernière version de XML Schema : Les types de données est disponible à http://www.w3.org/TR/xmlschema-2.
[SCHEMA-PRIMER]
XML Schema tome 0 : Introduction, section 4.2, D. Fallside, rédacteur. W3C, 2001. Cet exemple est en ligne à http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#DerivExt.
[WEBDATA]
L'architecture Web : Description et échange de données, T. Berners-Lee, D. Connolly et R. R. Swick. W3C, 2001. Cet exemple est en ligne à http://www.w3.org/1999/06/07-WebData.
[XML]
Le langage de balisage extensible (XML) 1.0 (2e édition), section 2.5, T. Bray, J. Paoli, C. M. Sperberg-McQueen et E. Maler, rédacteurs. W3C, 2000. Cet exemple est en ligne à http://www.w3.org/TR/2000/REC-xml-20001006#sec-comments.

15. Historique des changements

16. La liste des choses à faire