hcard-design-methodology-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m ([fr: sync'd and translation to be achieved])
 
m ([fr:sync'd and first draft translation to be reviewed])
Line 1: Line 1:
<h1>hCard méthodologie de design</h1>
<h1>hCard méthodologie de design</h1>
{{TOC-right}}
Cette page est une section d'expliction ''informative'' de la [[hcard-fr|spécification hCard]].


Cette page rassemble quelques-unes des méthodologies de design qui sont rentrées dans le [[hcard-fr|microformat hCard]].
Cette page rassemble quelques-unes des méthodologies de design qui sont rentrées dans le [[hcard-fr|microformat hCard]].
Line 19: Line 23:




* Use class names based on names from the original schema, unless the [[semantic-xhtml|semantic XHTML]] building block precisely represents that part of the original schema. If names in the source schema are case-insensitive, then use an all lowercase equivalent. Components names implicit in prose (rather than explicit in the defined schema) should also use lowercase equivalents for ease of use. Spaces in component names become dash '-' characters.
* Utilisez des noms de classes basés sur des noms provenant du schéma original, à moins que le bloc de construction [[semantic-xhtml-fr|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 uses case-insensitive identifiers, but by convention most vCards have, and [[vcard-implementations|vCard implementations]] produce, all UPPERCASE identifiers, e.g. VCARD, N, FN etc.  Since the HTML4 'class' attribute is case-sensitive, for microformats I had to pick a specific case to use for property names. I decided to explicitly follow the precedent and example set by XHTML from HTML4 of using the lowercase version of element names from HTML4 which itself similar to vCard had case-insensitive element names (due to its use of SGML) and by convention used all UPPERCASE element names in documentation.
vCard utilise des identifiants non-sensibles-à-la-casse, mais par convention, la majorité des vCards ont, et les [[vcard-implementations-fr|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.  


Thus where HTML4 to XHTML looked like this:
De ce fait là où HTML4 vers XHTML ressemblait à ça :  
* <code>&lt;HTML&gt;</code> became <code>&lt;html&gt;</code>
* <code>&lt;HTML&gt;</code> est devenu <code>&lt;html&gt;</code>
* <code>&lt;HEAD&gt;</code> became <code>&lt;head&gt;</code>
* <code>&lt;HEAD&gt;</code> est devenu <code>&lt;head&gt;</code>
* <code>&lt;BODY&gt;</code> became <code>&lt;body&gt;</code>
* <code>&lt;BODY&gt;</code> est devenu <code>&lt;body&gt;</code>
* ... etc.
* ... etc.


vCard to hCard looked like this:
vCard vers hCard ressemblait à cela :  
* <code>BEGIN:VCARD</code> became <code>class="vcard"</code>
* <code>BEGIN:VCARD</code> est devenu <code>class="vcard"</code>
* <code>N:</code> became <code>class="n"</code>
* <code>N:</code> est devenu <code>class="n"</code>
* <code>FN:</code> becamse <code>class="fn"</code>
* <code>FN:</code> est devenu <code>class="fn"</code>
* ... etc.
* ... etc.






* For types with multiple components, use nested elements with class names equivalent to the names of the components.
* Pour les types avec plusieurs composants, utilisez des éléments imbriqués avec des noms de clases équivalents aux noms des composants.
 
In the [[vCard-fr|vcard]] specification, properties are referred to has "types", and thus the above principle invokes that same language to refer to such "types", specifically those that have some structure to them, with a set of values that relate specific semantics.


The primary example of this in hCard are the "n" and "adr" properties, each of which have sub-properties (e.g. "given-name", "family-name", etc. for "n", "street-address", "locality", etc. for "adr").
Dans la spécification [[vCard-fr|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").




* Plural components are made singular, and thus multiple nested elements are used to represent multiple text values that are comma-delimited.


There are several properties in vCard that are either plural (e.g. CATEGORIES) or are simply defined to take multiple values (e.g. NICKNAME), or are sub-properties that are plural (e.g. additional names).  As one of few exceptions to the "reuse names exactly" aka "don't change the names" design [[principle]], plural names of properties or sub-properties are explicitly changed to their singular equivalents, e.g.:
* 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.
* CATEGORIES became "category"
* NICKNAME became "nickname"
* "additional names" became "additional-name"
And in all cases of such plural or multi-valued properties, the hCard specification permits multiple instances of the singular form which are then combined as appropriate to the equivalent property when transforming to vCard.


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 [[principle-fr|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.




* Finally, if the format of the data according to the original schema is too long and/or not human-friendly, use <code>&lt;abbr&gt;</code> instead of a generic structural element, and place the literal data into the 'title' attribute (where abbr expansions go), and the more brief and human-readable equivalent into the element itself. Further informative explanation of this use of <code>&lt;abbr&gt;</code>:  [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved].
* Pour conclure, si le format de la donnée selon le schéma original est trop long ou non amical pour l'humain, utilisez <code>&lt;abbr&gt;</code> 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 <code>&lt;abbr&gt;</code> :  [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved].


Motivated originally by the development of [[hcalendar-fr|hCalendar]] which itself is based on [[icalendar-fr|iCalendar RFC2445]], which needed a way to capture and represent datetimes, this technique is similarly used in several instances in hCard, e.g.
Motivé initialement par le développement du [[hcalendar-fr|hCalendar]] qui lui-même est basé sur la [[icalendar-fr|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
* the "bday" property, e.g.:
* la propriété "bday" par ex.:
** <code>&lt;abbr class="bday" title="2005-06-20"&gt;20 juin&lt;/abbr&gt;</code>
** <code>&lt;abbr class="bday" title="2005-06-20"&gt;20 juin&lt;/abbr&gt;</code>
* the "region" sub-property, e.g.:
* la sous-propriété "region" par ex.:
** <code>&lt;abbr class="region" title="California"&gt;CA&lt;/abbr&gt;</code>
** <code>&lt;abbr class="region" title="California"&gt;CA&lt;/abbr&gt;</code>
* the "country-name" sub-property, e.g.:
* la sous-propriété "country-name" par ex.:
** <code>&lt;abbr class="country-name" title="United States of America"&gt;USA&lt;/abbr&gt;</code>
** <code>&lt;abbr class="country-name" title="United States of America"&gt;USA&lt;/abbr&gt;</code>


Revision as of 08:51, 15 December 2007

hCard méthodologie de design

Cette page est une section d'expliction 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éutiliser le schéma (names, objects, properties, values, types, hierarchies, constraints) autant que possible en partant des standards pré-existants, et bien supportés en référence. Eviter de redéclarer des contraintes exprimés 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:VCARD est devenu class="vcard"
  • N: est devenu class="n"
  • FN: est devenu class="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>


voir aussi

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-design-methodology-fr&oldid=23801"