hcard-design-methodology-fr

Jump to: navigation, search

hCard méthodologie de design

Contents


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 :

Pour hCard, le standard pré-existant, établi, bien supporté, réutilisé a été / est vCard.

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 :

vCard vers hCard ressemblait à cela :


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").


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 :

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.


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


voir aussi

hcard-design-methodology-fr was last modified: Saturday, December 15th, 2007

Views