naming-principles-fr

Principes de Nomenclature

L'un des principes-clés des microformats est de réutiliser et en particulier, réutiliser les noms d'objets, de propriétés et de valeurs à partir de formats et de standards existants à chaque fois que cela est possible.

Introduction

L'un des principes-clés des microformats est de réutiliser et en particulier, réutiliser les noms d'objets, de propriétés et de valeurs à partir de formats et de standards existants à chaque fois que cela est possible. - Tantek

J'ai créé explicitement ce principe en réponse aux anti-modèles que j'ai vus dans beaucoup (la plupart ?) des efforts de standards existants tels que :

• Inventer des noms en l'air
• Ignorer tous les travaux précédents
• Hostilité véritable envers les noms/termes provenant d'autres standards
• Utiliser les noms des autres pour signifier des choses différentes
• Utiliser de nouveaux noms pour signifier la même chose
• Débattre sans fin et "forger-des-noms" afin de parvenir à un nom légèrement plus parfait.

Peut-être est-ce dans la nature humaine de créer de nouveaux noms, ou de nommer de nouvelles choses. Il y a certainement une quantité d'égo impliquée dans la création d'une nouvelle chose que vous pouvez ensuite proclamer avoir inventé ou nommé. Quelques-unes de ces tendances sont aussi une forme de syndrôme "Not Invented Here" (NIH) qui malheureusement est tout à fait commun parmi les ingénieurs logiciels.

Malheureusement, un tel désir pour la nouveauté est mauvais pour les standards, et certainement mauvais pour l'interopérabilité, qui dépend d'être capable de compter sur le même nom voulant dire la même chose. C'est aussi mauvais pour le langage et la communication entre humains. Même si les humains peuvent s'arranger avec quelque ambiguïté et la surcharge de termes (en utilisant le contexte pour la désambiguation), c'est plus facile pour les humains quand il y a moins d'ambiguïté et moins de surcharge).

Nous n'allons pouvoir pleinement éliminer de telles tendances "Tour de Babel", mais au moins nous pouvons les minimiser, tout spécialement quand elles sont mauvaises pour les standards et l'interopérabilité.

Avec l'expérience de développer de nouveaux microformats tels que xFolk, hReview et hAtom, il est devenu tout à fait clair que nous avons besoin de documenter explicitement quelques-uns des principes spécifiques de design qui en sont venus à nommer les objets et propriétés de quelques-uns de premiers microformats établis comme hCard et hCalendar, et c'est l'intention de ce document.

Auteur

• Tantek Çelik

(traduction en cours Christophe Ducamp)

Principes de nommage

Principes de Design XHTML Sémantique

Tout d'abord, il est important de remarquer les principes de nommages qui ont été définis et explicitement référencés dans (la plupart) des microformats mentionnés ci-dessus.

Note : les Principes de Design XHTML Sémantique ont été écrits initialement dans le contexte de développement de hCard et hCalendar, par conséquent il peut être plus facile de comprendre ces principes dans le contexte de la méthodologie de design hCard (ce qui veut dire, lisez ça d'abord). Tantek

XHTML est construit sur du XML, et par conséquent les formats fondés sur XHTML peuvent être utilisés non seulement pour une présentation d'affichage pratique, mais aussi à des fins d'échanges de données. A bien des façons, les formats fondés sur XHTML illustrent le meilleur des mondes tant du HTML que du XML. Néanmoins au moment de construire des formats basés sur XHTML, cela aide d'avoir un ensemble de principes directeurs.

1. Réutilisez autant que possible le schéma (noms, objets, propriétés, valeurs, types, hiérarchies, contraintes) à partir des standards de référence établis et bien supportés. Evitez de redéclarer les contraintes exprimées dans le standard source. Des mentions à titre d'information peuvent passer.
   1. Pour les types avec plusieurs composants, utilisez des éléments imbriqués avec des noms de classe équivalents aux noms des composants.
   2. Les composants pluriels sont produits au singulier, et par conséquent plusieurs éléments imbriqués sont utilisés pour représenter plusieurs valeurs de texte qui sont délimitées par des virgules.
2. Utilisez la sémantique XHTML la plus précise pour construire des blocs pour chaque objet, etc.
3. Autrement utilisez un élément générique structurel (par ex. <span> ou <div>), ou l'élément contextuel approprié (par ex. un <li> dans un <ul> ou <ol>).
4. Utilisez des noms de classes basés sur des noms extraits du schéma original, à moins que le XHTML sémantique de construction de bloc ne représente précisément cette partie du schéma original. Si les noms dans le schéma original ne sont pas sensibles la casse, alors mettez tout dans un équivalent en bas de casse. Les noms de composants implicites en prose (plutôt qu'explicites dans le schéma défini) devraient aussi utiliser les équivalents bas de casse pour une facilité d'utilisation. Les espaces dans les noms des composants deviennent des caractères tiret '-'.
5. Pour finir, si le format de la donnée selon le schéma original est trop long et/ou non amical sur le plan humain, utilisez <abbr> au lieu d'un élément générique structurel, et placez les données littérales dans l'attribut 'title' (là où vont les expansions abbr), et l'équivalent le plus bref et le plus lisible humainement dans l'élément lui-même. De plus amples explications de cet usage de <abbr> : Human vs. ISO8601 dates problem solved

Quelques Détails

• mots-en-minuscules-séparés-par-des-tirets. Les W3C CSS (feuilles de styles en cascades) ont introduit la convention de mettre en minuscules tous les noms de propriétés/valeurs (identifiants) et de séparer les mots avec des caractères trait d'union "-" pour des raisons de meilleure lisibilité humaine à comparer à d'autres approches comme la casse ChatMot (ou même casse chatMot). Les noms des propriétés des microformats adoptent tout aussi bien strictement cette approche.

Noms de Classe Racine Uniques

J'ai aussi écrit un peu à propos des principes de design qui sont allés à l'intérieur des noms de classe *racine* (qui requièrent un traitement un peu différent que les noms de classe propriété) dans les microformats, mais ceci est décrit actuellement dans la page hcard-parsing :

http://microformats.org/wiki/hcard-parsing-fr#nom_classe_racine

Besoin de copier un peu de ce texte ici et de faire que ce ne soit pas spécifique à hCard.

Vocabulaire Minimal

Ceci est l'un des deux autres principes-clés qui je pense a besoin d'être développé plus en détail. Le principe de "vocabulaire minimal" est en fait directement dérivé du principe de démarrer aussi simple que possible.

• vocabulaire minimal. Nous essaierons de présenter aussi peu de nouveaux termes de microforomats que possible.

Réutilisation des Microformats en Premier, Autres Standards en Second

Ceci est en fait développé tout à fait clairement dans les principes des microformats, mais mérite à la fois une répétition explicite ici avec une emphase appuyée :

• réutiliser des blocs de construction à partir de standards largement adoptés
  • sémantique (http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html), (X)HTML ayant du sens (http://tantek.com/presentations/2005/03/elementsofxhtml). Voir Principes de Design XTHML sémantique pour plus de détails.
  • microformats existants
  • schémas bien établis à partir de RFCs interopérables

La clé ici est que ce principe n'est pas seulement de réutiliser l'ensemble des microformats (par ex. n'inventez pas une propriété pour une nouvelle personne pour votre microformat, réutilisez simplement hCard), mais aussi de savoir où obtenir des noms pour les propriétés.

En particulier, si vous trouvez que votre nouveau microformat a une propriété qui veut dire la même chose qu'un microformat existant, vous DEVRIEZ (peut-être que je devrais faire de cela un DEVEZ) réutiliser le nom de classe pour ce microformat existant. Cette pratique suit aussi le principe du vocabulaire minimal, et le fait de réutiliser le même nom pour dire la même chose (au lieu d'utiliser deux noms pour signifier la même chose).

Pour les Autres Standards, Préférez les Plus Vieux aux Plus Récents

S'il n'existe pas de noms de microformat pour une propriété, et que nous réutilisons des noms fondés sur la recherche de microformats existants, alors il y a souvent plus d'un format avec plus qu'un nom pour le concept particulier.

Souvent les nouveaux standards sont développés à partir (la plupart du temps) de renommages inutiles noms provenant des standards plus anciens. De ce fait pour réparer une telle dérive de nom, toutes les choses étant égales par ailleurs (par ex. les deux standards ont été largement implémentés de manière interopérable), nous préférons le noms le plus ancien au nom le plus récent.

Exemples pour suivre les Conventions de Nommage

Nous avons suivi ces principes de nommage à partir du début, et produit les changements sur les microformats en développement. Par exemple, xFolk a été modifié de la v0.4 vers la v1RC. xFolk a laissé tomber le nouveau nom de classe "extended" pour lui préférer la réutilisation du nom de classe existant "description". Voir Changements depuis xFolk 0.4 pour les détails.

Modèles de Nommage en Considération en tant que Principes

Quelques modèles ont émergé dans le nommage de noms de classe pour les microformats, et alors que ces modèles ne sont pas des conventions (à cette heure), il peut être valable de les prendre en considération.

Propriétés dt

A ce stade, tous les noms de classe datetime commenent avec "dt", et tous les noms de classe qui démarrent avec "dt" sont de propriétés datetime ISO8601 par ex. :

• dtend - hCalendar
• dtstart - hCalendar
• dtreviewed - hReview

Notez que "dt" est aussi en considération pour le type XOXO.

Exceptions avec le préfixe dt

Néanmoins, quelques microformats proposés/en-développement ont actuellement des noms de classe pour les propriétés datetime sans le préfixe "dt" :

Brouillon :

• rev - hCard
• bday - hCard

Proposé :

• mis à jour - hAtom
• publié - hAtom

h word

A ce stade, toutes les utilisations d'un préfixe unique "h" dans un nom de propriété s'appliquent aux éléments racines (potentiels). Mais pas tous les éléments racines (potentiels) ne démarrent par "h" (ce qui est "ok").

Par ex. :

• hatom-fr
• hentry - hAtom
• hreview-fr
• hlisting (proposé)

Devrions nous appliquer la règle que seuls les éléments racines (potentiels) pourraient démarrer par un préfixe "h" ?

Les éléments racines non-préfixés-h :

• vcard - hCard
• vcalendar - hCalendar
• vevent - hCalendar
• xfolk-fr

Anti-Modèles

Voici des choses à ne pas faire au moment de créer des noms

Espaces-noms

Evitez les espaces-noms (par ex. les noms de classe des microformats-clés]) ; lisez expaces-noms considérés comme nuisibles. hAtom utilise une quantité limitée d'espace-nom réutiliser exactement une sémantique particulière extraite de la spec Atom.

Problématiques

• La concision ne devrait pas t'elle prise en considération ? Pas dans l'intention de perdre du sens (class="b") mais pour empêcher la verbosité gratutite (class="truc-dont-nous-n'avons-pas-de-nom-raccourci"). Plus pragmatiquement, les abréviations devraient avoir du sens et être appropriées (par ex. var pour variety comme c'est utilisé dans le nommage botanique) - Andy Mabbett

Voir aussi :

• classes existantes pour les noms de classes déjà utilisés
• class-design-pattern-fr pour voir les noms de classes sont utilisés dans les microformats
• principes de design xthml sémantique
• conventions de nommage pour les pages du site wiki microformats.org