hcard-design-methodology-fr
hCard méthodologie de design
Cette page est une section d'explication informative de la spécification hCard.
Cette page rassemble quelques-unes des méthodologies de design qui sont rentrées dans le microformat hCard.
La plupart des détails de hCard ont été délibérément fondés sur des principes. En rassemblant quelques-uns de ces principes et techniques méthodologiques, nous espérons que les futurs microformats pourront en bénéficier par la réutilisation de certaines parties de cette méthodologie.
- Auteur
- Tantek Çelik
Principes de Design XHTML Sémantique
Les principes de design XHTML sémantique ont été largement créés et assimilés comme résultat de décisions explicites de design sur la façon de ré-utiliser au mieux la terminologie vCard RFC2426 dans le contexte du XHTML sémantique.
En particulier :
- Réutilisez autant que possible le schéma (noms, objets, propriétés, valeurs, types hiérarchies, contraintes) en partant des standards pré-existants, et bien supportés en référence. Evitez de re-déclarer des contraintes exprimées dans le standard source. Les mentions informatives sont ok.
Pour hCard, le standard pré-existant, établi, bien supporté, réutilisé a été / est vCard.
- Utilisez des noms de classes basés sur des noms provenant du schéma original, à moins que le bloc de construction XHTML sémantique ne représente précisément cette partie-là du schéma original. Si les noms dans le schéma source sont non-sensibles-à-la-casse, mettez alors tout en équivalent bas-de-casse. Les noms des composants implicites en prose (plutôt qu'explicites dans le schéma défini) devraient aussi utiliser des équivalents en bas de casse pour une facilité d'utilisation. Les espaces dans les noms de composants deviennent des caractères tirets'-'.
vCard utilise des identifiants non-sensibles-à-la-casse, mais par convention, la majorité des vCards ont, et les implémentations vCard produisent tous des identifiants en LETTRESMAJUSCULES, c'est-à-dire VCARD, N, FN etc. Du fait que l'attribut 'class' du HTML4 soit sensible à la casse, pour les microformats j'ai dû choisir un cas spécifique pour les noms de propriétés. J'ai décidé explicitement de suivre le précédent et l'exemple réglé par le XHTML à partir du HTML4 pour utiliser la version en bas de casse des noms d'élements provenant du HTML4 qui lui-même est similaire à ce que la vCard avait comme noms d'éléments non-sensibles-à-la-casse (du fait de son utilisation du SGML) et par convention utilisait tous les noms d'éléments en LETTRESMAJUSCULES dans la documentation.
De ce fait là où HTML4 vers XHTML ressemblait à ça :
<HTML>est devenu<html><HEAD>est devenu<head><BODY>est devenu<body>- ... etc.
vCard vers hCard ressemblait à cela :
BEGIN:VCARDest devenuclass="vcard"N:est devenuclass="n"FN:est devenuclass="fn"- ... etc.
- Pour les types avec plusieurs composants, utilisez des éléments imbriqués avec des noms de clases équivalents aux noms des composants.
Dans la spécification vcard, les propriétés font référence aux "types", et de ce fait le principe au-dessus invoque que le même langage fasse référence à de tels "types", spécificiquement ceux qui quelque structure vers eux, avec un ensemble de valeurs en rapport avec la sémantique spécifique.
L'exemple initial de cela dans hCard sont les propriétés "n" et "adr", chacune d'entre elles a des sous-propriétés (par ex. "given-name", "family-name", etc. pour "n", "street-address", "locality", etc. pour "adr").
- Les composants pluriels sont produits au singulier, et de ce fait plusieurs éléments imbriqués sont utilisés pour représenter plusieurs valeurs de texte qui sont délimitées par des virgules.
Il y a plusieurs propriéts dans la vCard qui sont soit au pluriel (par ex. CATEGORIES) ou qui sont simplement définies pour prendre plusieurs valeurs (par ex. NICKNAME), ou sont des sous-propriétés qui sont plurielles (par ex. additional names). Du fait du peu d'exception aux principes de design "reuse names exactly" aussi connu sous "don't change the names", les noms au pluriel des propriétés ou sous-propriétés sont explicitement changés en leurs équivalents au singulier, à savoir :
- CATEGORIES est devenu "category"
- NICKNAME est devenu "nickname"
- "additional names" est devenu "additional-name"
Et dans tous les cas de telles propriétés au pluriel ou à plusieurs-valeurs, la spécification hCard permet plusieurs instances de la forme au singulier qui sont ensuite combinées en leur propriété équivalente au moment de la transformation en vCard.
- Pour conclure, si le format de la donnée selon le schéma original est trop long ou non amical pour l'humain, utilisez
<abbr>au lieu d'un élément structurel générique, et placez la donnée littérale à l'intérieur de l'attribut 'title" (là où vont les expansion abbr) et l'équivalent le plus bref et lisible par un humain à l'intérieur de l'élément lui-même. Une explication informative plus approfondie de cet usage de<abbr>: Human vs. ISO8601 dates problem solved.
Motivé initialement par le développement du hCalendar qui lui-même est basé sur la RFC2445 iCalendar, qui avait besoin d'un moyen de capturer et représenter datetimes, cette technique est utilisée de la même façon dans plusieurs instances dans la hCard, à savoir
- la propriété "bday" par ex.:
<abbr class="bday" title="2005-06-20">20 juin</abbr>
- la sous-propriété "region" par ex.:
<abbr class="region" title="California">CA</abbr>
- la sous-propriété "country-name" par ex.:
<abbr class="country-name" title="United States of America">USA</abbr>