minimal-vocabulary-fr: Difference between revisions
m (typo) |
m (Replace <entry-title> with {{DISPLAYTITLE:}}) |
||
Line 1: | Line 1: | ||
{{DISPLAYTITLE:vocabulaire minimum}} | |||
Un aspect des [[principles-fr|principes]] [[start-simple-fr|commencer-simple]] des [[microformats]], et l'un des nombreux [[naming-principles-fr|principes de nommage]]. | Un aspect des [[principles-fr|principes]] [[start-simple-fr|commencer-simple]] des [[microformats]], et l'un des nombreux [[naming-principles-fr|principes de nommage]]. | ||
Latest revision as of 16:30, 18 July 2020
Un aspect des principes commencer-simple des microformats, et l'un des nombreux principes de nommage.
Un moyen de maintenir une solution simple est de minimiser le vocabulaire que la solution utilise, et certainement, minimiser tout nouveau vocabulaire qui est introduit.
avantages
Minimiser le vocabulaire utilisé pour les propriétés (et valeurs) d'un microformat aide à produire et faire que les microformats soient plus plus faciles à comprendre.
Minimiser l'introduction d'un nouveau vocabulaire est particulièrement important. En faisant ainsi :
- Aide les microformats comme un tout plus facile à comprendre (le vocabulaire total de tous les microformats est plus petit)
- Réduit la confusion avec la ré-utilisation de technologies existantes.
préserver un vocabulaire littéral au momment de réutiliser le sens
Au moment de réutiliser le schéma ou sens tiré d'un format existant, ré-utilisez à chaque fois que possible le vocabulaire respectif.
Ceci est particulièrement important à illustrer, compte tenu du fait du nombre de fois où cela s'est passé (renommage non nécessaire/abréviation/ /déformation de termes existants). Cela arrive souvent pour mériter d'appeler cela comme un anti-modèle. Exemples :
Exemple org
hCard ré-utilise délibérément le nom de propriété littéral org
tiré de la vCard.
D'un autre côté, les renommages apparemment simples / voulus pour aider ont été trouvés :
- "company/name" (OpenID attribute exchange - pourrait être aussi un renommage de
organization-name
, voir plus bas - comment pouvons-nous en être certains ?) - "organization" (tant Une Ontologie pour les vCards et Portable Contacts)
- "affiliation" (Google propriétés information de contact)
Exemple organization name
hCard ré-utilise délibérément organization-name
tiré de vCard selon principes-de-design-du-xhtml-sémantique.
Les efforts malheureux de "ménage" :
- "company/name" (OpenID attribute exchange - pourrait être aussi un renommage de
org
, voir ci-dessus - comment pouvons-nous en être sûrs ?) - "Orgname" (Représentation des Objects vCard en RDF/XML)
éviter aussi l'anti-modèle anglo-centrique
Tous ces renommages/expansions/abréviations peuvent être (semi-)évidentes pour les lecteurs centrés-Anglais, mais provoquent des confusions non nécessaires quand un développeur non-natif-anglais rencontre différents termes qui veulent dire la même chose dans la vCard pour ces autres technologies.
Pour un développeur non-natif-anglais, "org" et "affiliation" sont deux séquences de caractères différentes, et semblent aussi différentes que "bet" et "nssvyvngvba" le font pour un développeur non-native-ROT13.
Le renommage anglais non nécessaire des propriétés d'un mot anglais tirées des standards précédents est une erreur de design Anglo-centrique (spécifiquement pour les concepteurs anglais) qui a besoin d'être décrite plus en profondeur comme un anti-modèle de design à éviter.
plus d'exemples
- voir autres variantes de RFC2426 pour plus d'exemples de renommages de propriétés non nécessaires.