https://microformats.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=OubobOc4td 2026-04-21T12:07:56Z User contributions MediaWiki 1.38.4 https://microformats.org/wiki/index.php?title=naming-principles-fr&diff=36811 2009-01-03T10:47:55Z

<p>OubobOc4td: racnoalviouc</p> <hr /> <div>ervirotrocdo<br /> &lt;h1&gt;Principes de Nomenclature&lt;/h1&gt;<br /> <br /> L'un des principes-clés des [[microformats-fr|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.<br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> L'un des principes-clés des [[microformats-fr|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<br /> <br /> 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 : <br /> <br /> * Inventer des noms en l'air<br /> * Ignorer tous les travaux précédents<br /> * Hostilité véritable envers les noms/termes provenant d'autres standards<br /> * Utiliser les noms des autres pour signifier des choses différentes<br /> * Utiliser de nouveaux noms pour signifier la même chose<br /> * Débattre sans fin et &quot;forger-des-noms&quot; afin de parvenir à un nom légèrement plus parfait.<br /> <br /> 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 &quot;Not Invented Here&quot; (NIH) qui malheureusement est tout à fait commun parmi les ingénieurs logiciels.<br /> <br /> 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).<br /> <br /> Nous n'allons pouvoir pleinement éliminer de telles tendances &quot;Tour de Babel&quot;, mais au moins nous pouvons les minimiser, tout spécialement quand elles sont mauvaises pour les standards et l'interopérabilité.<br /> <br /> Avec l'expérience de développer de nouveaux microformats tels que [[xfolk-fr|xFolk]], [[hreview-fr|hReview]] et [[hatom-fr|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-fr|hCard]] et [[hcalendar-fr|hCalendar]], et c'est l'intention de ce document.<br /> <br /> == Auteur ==<br /> * [http://tantek.com/ Tantek Çelik]<br /> <br /> (traduction en cours [[Christophe Ducamp]])<br /> <br /> = Principes de nommage =<br /> == Principes de Design XHTML Sémantique ==<br /> 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.<br /> <br /> {{semantic-xhtml-design-principles-fr}}<br /> <br /> === Quelques Détails ===<br /> * '''mots-en-minuscules-séparés-par-des-tirets'''. Les [http://w3.org/ W3C] [http://w3.org/Style/CSS/ 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 &quot;-&quot; 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.<br /> <br /> == Noms de Classe Racine Uniques ==<br /> 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 :<br /> <br /> http://microformats.org/wiki/hcard-parsing-fr#nom_classe_racine<br /> <br /> Besoin de copier un peu de ce texte ici et de faire que ce ne soit pas spécifique à hCard.<br /> <br /> == Vocabulaire Minimal ==<br /> 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 &quot;vocabulaire minimal&quot; est en fait directement dérivé du principe de [[microformats-fr#les_principes_des_microformats|démarrer aussi simple que possible]].<br /> <br /> * vocabulaire minimal. Nous essaierons de présenter aussi peu de nouveaux termes de microforomats que possible.<br /> <br /> == Réutilisation des Microformats en Premier, Autres Standards en Second ==<br /> Ceci est en fait développé tout à fait clairement dans les [[microformats-fr#les_principes_des_microformats|principes des microformats]], mais mérite à la fois une répétition explicite ici avec une &lt;strong&gt;emphase appuyée&lt;/strong&gt; :<br /> <br /> * réutiliser des blocs de construction à partir de standards largement adoptés<br /> ** sémantique (http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html), (X)HTML ayant du sens (http://tantek.com/presentations/2005/03/elementsofxhtml). Voir [[SemanticXHTMLDesignPrinciples-fr|Principes de Design XTHML sémantique]] pour plus de détails.<br /> ** &lt;strong&gt;microformats existants&lt;/strong&gt;<br /> ** &lt;strong&gt;schémas bien établis à partir de RFCs interopérables&lt;/strong&gt;<br /> <br /> 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-fr|hCard]]), mais aussi de savoir où obtenir des noms pour les propriétés.<br /> <br /> 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).<br /> <br /> === Pour les Autres Standards, Préférez les Plus Vieux aux Plus Récents ===<br /> 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.<br /> <br /> 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.<br /> <br /> == Exemples pour suivre les Conventions de Nommage ==<br /> Nous avons suivi ces principes de nommage à partir du début, et produit les changements sur les microformats en développement. Par exemple, [[xfolk-fr|xFolk]] a été modifié de la v0.4 vers la v1RC. xFolk a laissé tomber le nouveau nom de classe &quot;extended&quot; pour lui préférer la réutilisation du nom de classe existant &quot;description&quot;. Voir [[xfolk-fr#Changements_depuis_xFolk_0.4|Changements depuis xFolk 0.4]] pour les détails.<br /> <br /> == Modèles de Nommage en Considération en tant que Principes==<br /> 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.<br /> <br /> === Propriétés dt ===<br /> A ce stade, tous les noms de classe datetime commenent avec &quot;dt&quot;, et tous les noms de classe qui démarrent avec &quot;dt&quot; sont de propriétés datetime ISO8601 par ex. :<br /> <br /> * dtend - [[hcalendar-fr|hCalendar]]<br /> * dtstart - [[hcalendar-fr|hCalendar]]<br /> * dtreviewed - [[hreview-fr|hReview]]<br /> <br /> Notez que &quot;dt&quot; est aussi [http://microformats.org/wiki/rest/datatypes#Proposal en considération pour le type XOXO].<br /> <br /> ==== Exceptions avec le préfixe dt ====<br /> 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 &quot;dt&quot; :<br /> <br /> Brouillon : <br /> * rev - [[hcard-fr|hCard]]<br /> * bday - [[hcard-fr|hCard]]<br /> <br /> Proposé : <br /> * mis à jour - [[hatom-fr|hAtom]]<br /> * publié - [[hatom-fr|hAtom]]<br /> <br /> === h word ===<br /> A ce stade, toutes les utilisations d'un préfixe unique &quot;h&quot; 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 &quot;h&quot; (ce qui est &quot;ok&quot;).<br /> <br /> Par ex. :<br /> * [[hatom-fr]]<br /> * hentry - [[hatom-fr|hAtom]]<br /> * [[hreview-fr]]<br /> * [[hlisting-proposal-fr|hlisting]] (proposé)<br /> <br /> Devrions nous appliquer la règle que seuls les éléments racines (potentiels) pourraient démarrer par un préfixe &quot;h&quot; ?<br /> <br /> Les éléments racines non-préfixés-h :<br /> * vcard - [[hcard-fr|hCard]]<br /> * vcalendar - [[hcalendar-fr|hCalendar]]<br /> * vevent - [[hcalendar-fr|hCalendar]]<br /> * [[xfolk-fr]]<br /> <br /> == Anti-Modèles ==<br /> Voici des choses à ne ''pas'' faire au moment de créer des noms<br /> <br /> === Espaces-noms ===<br /> Evitez les espaces-noms (par ex. les noms de classe des ''microformats''-''clés'']) ; lisez [[namespaces-considered-harmful-fr|expaces-noms considérés comme nuisibles]]. [[hatom-fr|hAtom]] utilise une quantité limitée d'espace-nom [[hatom-faq-fr#Pourquoi_hAtom_utilise_les_noms_de_classes_espaces-noms|réutiliser exactement une sémantique particulière]] extraite de la spec Atom.<br /> <br /> =Problématiques =<br /> * La '''concision''' ne devrait pas t'elle prise en considération ? Pas dans l'intention de perdre du sens ('''class=&quot;b&quot;''') mais pour empêcher la verbosité gratutite ('''class=&quot;truc-dont-nous-n'avons-pas-de-nom-raccourci&quot;'''). 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<br /> <br /> = Voir aussi : =<br /> * [[existing-classes-fr|classes existantes]] pour les noms de classes déjà utilisés<br /> * [[class-design-pattern-fr]] pour voir les noms de classes sont utilisés dans les microformats<br /> * [[semantic-xhtml-design-principles-fr|principes de design xthml sémantique]]<br /> * [[naming-conventions-fr|conventions de nommage]] pour les pages du site wiki microformats.org</div>

OubobOc4td