hcard-parsing-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (Reverted edits by ElbolIcnae (Talk) to last version by Brian)
 
(23 intermediate revisions by 8 users not shown)
Line 5: Line 5:
(traduction en cours [[Christophe Ducamp]])
(traduction en cours [[Christophe Ducamp]])
== introduction ==
== introduction ==
Quand j'ai initialement conçu [[hcard-fr|hCard]], il était clair pour moi de savoir comment parser sans ambiguïté tant l'existence de hCards dans du (X)HTML arbitraire (et n'importe où ce  pouvait être embarqué dans du (X)HTML arbitraire, par ex. RSS, Atom, "XML générique") que les propriétés et valeurs de hCard.


Quand j'ai d'abord conçu [[hcard-fr|hCard]], il était clair pour moi de savoir comment parser sans ambiguïté l'existence de hCards dans du (X)HTML arbitraire (et n'importe où pouvait être embarqué du (X)HTML arbitraire, par ex. RSS, Atom, "XML générique"), et les propriétés et valeurs de hCard.
J'ai travaillé directement avec Brian Suda pour saisir ces idées dans une implémentation, et Brian a écrit X2V, un script XSLT qui convertit les hCards en vCards, démontrant ainsi simultanément la parsabilité des hCards et l'utilité immédiate du contenu hCard interopérant avec les applications existantes massivement répandues de vCard.


J'ai travaillé directement avec Brian Suda pour capturer ces idées dans une implémentation, et Brian a écrit X2V, un script XSLT qui convertit les hCards en vCards, démontrant de ce fait simultanément, la parsabilité des hCards et l'utilité immédiate du contenu hCard interopérant avec les applications existantes massivement répandues de vCard.
Je vais maintenant documenter ces idées directement sur cette page, de façon à ce que des implémentations supplémentaires puissent être construites à partir de ces concepts élémentaires, plutôt que d'avoir à faire du reverse engineering sur X2V.
 
Je vais maintenant documenter ces idées directement sur cette page, de façon à ce que des implémentations supplémentaires, plutôt que d'avoir à faire du reverse engineering sur X2V, puissent être construites à partir de ces concepts élémentaires.


__TOC__
__TOC__


== étendue ==
== étendue ==
Bien que cette page soit écrite spécifiquement pour expliquer comment parser [[hcard-fr|hCard]], les concepts et algorithmes contenus à l'intérieur servent comme exemple pour la façon dont d'autres [[compound-microformat-fr|microformats composés]] vont se faire parser.
Bien que cette page soit écrite spécifiquement pour expliquer comment parser [[hcard-fr|hCard]], les concepts et algorithmes contenus à l'intérieur servent comme exemple pour la façon dont d'autres [[compound-microformat-fr|microformats composés]] vont se faire parser.


== Gestion URL  ==
== Gestion URL  ==
Un parseur hCard peut commencer par un <abbr title="Uniform Resource Locator">URL</abbr> à récupérer.


Un parseur hCard peut commencer par un URL à récupérer.
Si l'<abbr>URL</abbr> manque d'un [http://www.la-grange.net/w3c/html4.01/intro/intro.html#h-2.1.2 identifiant de fragment], alors le parseur devrait parser la ressource complète retrouvée pour les [[hcard-fr|hCards]].


Si l'URL manque d'un identifiant fragment, alors le parseur devrait parser la ressource complète récupérée pour les hCards.
Si l'<abbr>URL</abbr> a un identitfiant de fragment, alors le parseur ne devrait parser ''que'' le noeud indiqué par l'identifiant de fragment et ses descendants, chercher des [[hcard-fr|hCards]], démarrer avec le noeud indiqué, qui peut lui-même être une simple [[hcard-fr|hCard]].


Si l'URL a un identifiant fragment, alors le parseur ne devrait paser ''que'' le noeud indiqué par l'identifiant fragment et ses descendants, chercher des hCards, démarrer avec le noeud indiqué, qui peut être lui-même un simple hCard.


== nom classe racine ==
== nom de classe racine ==
Chaque microformat composé commence par un élément racine avec un nom de classe relativement unique. Par cela, je veux dire un nom de classe qui n'est pas simplement un mot commun, et qui devra être peu probablement être utilisé à l'extérieur du contexte du microformat. En choisissant un tel nom de classe racine, le microformat évite (pour toutes les intentions pratiques) de rentrer en conflit avec des noms de classe existants qui peuvent exister dans le contexte (X)HTML.  Ceci est essentiel pour permettre à de tels microformats composés d'être ''embarqués'' dans le contenu actuel, existant, tout comme le contenu futur.


Chaque microformat composé commence par un élément racine ave un nom de classe relativement unique. Par cela, je veux dire un nom de classe qui n'est pas simplement un mot commun, et qui devra être peu probablement être utilisé à l'extérieur du contexte du microformat. En choisissant un tel nom de classe racine, le microformat évite (pour toutes les intentions pratiques) de rentrer en conflit avec des noms de classe existants qui peuvent exister dans le contexte (X)HTML. Ceci est essentiel pour permettre à de tels microformats composés d'être ''embarqués'' dans le contenu actuel, existant, tout comme le contenu futur.
Heureusement ce n'est pas un nouveau problème à résoudre. Les noms d'objets racine choisis pour la vCard (RFC 2426) et iCalendar (RFC 2445) ont eu de la même manière à éviter de telles collisions et l'ont fait en choisissant des noms qui devraient peu probablement être introduits à l'intérieur d'un objet contexte MIME. Le principe de ''réutilisation'' dicte le fait que nous devrions réutiliser les noms pour ces objets racine dans ces RFCs plutôt que d'inventer les nôtres. Compte tenu de la même sémantique, un design devrait réutiliser les noms, plutôt que d'inventer un second nom pour la même sémantique (une erreur commune de design produite dans des environnements qui requièrent des espaces-noms).


Heureusement ce n'est pas un nouveau problème à résoudre. Les noms d'objts racine choisis pour la vCard (RFC 2426) et iCalendar (RFC 2445) ont eu de la même manière à éviter de telles collisions et l'ont fait en choisissant des noms qui devraient peu probablement être introduits à l'intérieur d'un objet contexte MIME. Le principe de ''réutilisation'' dicte le fait que nous devrions réutiliser les noms pour ces objets racine dans ces RFCs plutôt que d'inventer les nôtres. Compte tenu de la même sémantique, un design devrait réutiliser les noms, plutôt que d'inventer un second nom pour la même sémantique (une erreur commune de design produite dans des environnements qui requièrent des espaces-noms).
Dans la spécification vCard, les noms ne sont pas sensibles à la casse du aux (manques) d'exigences de leur contexte. Les noms de classes (X)HTML sont sensibles à la casse par ces spécifications. De ce fait, nous sommes obligés de choisir une casse canonique pour les noms de classe équivalents des noms d'objets, et des noms de propriétés de vCard. Toutes les bas de casse sont choisies pour suivre le réglage précédent (c'est à dire le modèle ''reuse'') par le XHTML, ce qui devait de la même manière canoniser la casse de l'élément et les noms d'attributs que cela prenait du HTML4, qui lui-même était insensible à la casse du fait de son contexte (SGML).  En outre, les raisons d'éviter le mélange de casse (par ex. la casse chatmot) dans le contexte de noms de classes peuvent être trouvées dans l'article [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class], spécifiquement, la section titrée [http://tantek.com/log/2002/12.html#atoc_csensitivity Class sensitivity].
 
Dans la spécification vCard, les noms ne sont pas sensibles à la casse du aux (manque) d'exigences de leur contexte. Les noms de classes (X)HTML sont sensibles à la casse par ces spécifications. De ce fait, nous sommes obligés de choisir une casse canonique pour les noms de classe équivalents des noms d'objets, et des noms de propriéts de vCard. Toutes les bas de casse sont choisies pour suivre le réglage précédent (c'est à dire le modèle ''reuse'') par le XHTML, ce qui devait de la même manière canoniser la casse de l'élément et les noms d'attributs que cela prenait du HTML4, qui lui-même était insensible à la casse du fait de son contexte (SGML).  En outre, les raisons d'éviter le mélange de casse (par ex. la casse chatmot) dans le contexte de noms de classes peuvent être trouvées dans l'article [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class], spécifiquement, la section titrée [http://tantek.com/log/2002/12.html#atoc_csensitivity Class sensitivity].


Par conséquent, le nom de classe racine d'un [[hcard-fr|hCard]] est "vcard".   
Par conséquent, le nom de classe racine d'un [[hcard-fr|hCard]] est "vcard".   


== trouver des hCards ==
== trouver des hCards ==
Un document (X)HTML indique qu'il peut contenir des [[hcard-fr|hCards]] en référençant le [[hcard-profile-fr|profil XMDP de hCard]].  Voir [http://gmpg.org/xmdp/description XMDP] pour plus de détails.


Un docuemnt (X)HTML indique qu'il peut contenir des hCards en référençant le [[hcard-profile-fr|hCard XMDP profile]].  Voir [http://gmpg.org/xmdp/description XMDP] pour plus de détails.
Un parseur trouve des [[hcard-fr|hCards]] dans un contexte (X)HTML en cherchant des éléments avec le nom de classe racine ''vcard'' tout simplement comme le fait le [[http://www.w3.org/TR/REC-CSS2/selector.html#class-html sélecteur de classe CSS suivant] :  
 
Un parseur trouve des hCards dans un contexte (X)HTML en cherchant des éléments avec le nom de classe racine "vcard" tout simplement comme le fait le sélecteur de classe CSS suivant :  
<pre>
<pre>
  .vcard
  .vcard
</pre>
</pre>


Par exemple, la règle de style CSS suivante fixe l'arrière plan de toutes les hCards en vert :  
Par exemple, la déclaration de règle de style CSS suivante fixe l'arrière-plan de toutes les [[hcard-fr|hCards]] en vert :  
<pre>
<pre>
  .vcard { background: green; }
  .vcard { background: green; }
Line 58: Line 54:
* <code>&lt;li class="reviewer vcard first"&gt; &lt;/li&gt;</code>
* <code>&lt;li class="reviewer vcard first"&gt; &lt;/li&gt;</code>


Une fois l'élément racine d'un hCard trouvé, cet élément-là et tous ses descendants sont tout ce qui est exigé pour parser le hCard.
Une fois l'élément racine d'une [[hcard-fr|hCard]] trouvé, cet élément-là et tous ses descendants sont tout ce qui est exigé pour parser la [[hcard-fr|hCard]].


Par conséquent, il est possible pour un hCard bien formé d'être extrait à partir d'un contexte général non bien-formé, si le parseur a la capacité de trouver des éléments par nom de classe dans ce contexte non bien-formé.
Par conséquent, il est possible pour une [[hcard-fr|hCard]] bien formée d'être extraite à partir d'un contexte général non bien-formé, si le parseur a la capacité de trouver des éléments par nom de classe dans ce contexte non bien-formé.


== propriétés hCard ==
== propriétés hCard ==
La liste complète des noms de classe pour les propriétés hCard est documentée sur la page  [[hcard-profile-fr|hCard profile]].
La liste complète des noms de classe pour les propriétés hCard est documentée sur la page  [[hcard-profile-fr|hCard profile]].


=== parsage compatible en avant ===
=== parsage compatible avant ===
 
Au moment de parser les contenus d'une [[hcard-fr|hCard]], tous les noms de classe non reconnus doivent être ignorés.
Au moment de parser les contenus d'un hCard, tous les noms de classe non reconnus doivent être ignorés.


De la même manière, les valeurs non reconnues pour les propriétés de hCard doivent être aussi ignorées.
De la même manière, les valeurs non reconnues pour les propriétés de [[hcard-fr|hCard]] doivent être aussi ignorées.


=== trouver des propriétés hCard ===
=== trouver des propriétés hCard ===
 
Pour parser une [[hcard-fr|hCard]] pour une propriété hCard (par ex. "fn"), le parseur cherche simplement le premier élément avec ce nom de classe à l'intérieur de hCard.
Pour parser un hCard pour une propriété hCard (par ex. "fn"), le parseur cherche simplement le premier élément avec ce nom de classe à l'intérieur de hCard.


Ceci peut être aussi exprimé comme le premier élément qui correspond à ce sélecteur CSS :  
Ceci peut être aussi exprimé comme le premier élément qui correspond à ce sélecteur CSS :  
Line 82: Line 75:
</pre>
</pre>


Quelques propriétés, comme "fn", ne devraient seulement apparaître qu'une fois, et par conséquent le parseur arrête de chercher la propriété après qu'il ait trouvé une occurence. Les occurences supplémenaires sont ignorées.
Quelques propriétés, comme "fn", ne devraient seulement apparaître qu'une fois, et par conséquent le parseur arrête de chercher la propriété après qu'il ait trouvé une occurence. Les occurences supplémentaires sont ignorées.


D'autres propriéts comme "adr", "email", "url", "tel", etc., peuvent (et le font souvent) apparaître plus d'une fois, et par conséquent le parseur continue à regarder chaque occurence dans les contenus du hCard.
D'autres propriétés comme "adr", "email", "url", "tel", etc., peuvent (et le font souvent) apparaître plus d'une fois, et par conséquent le parseur continue à regarder chaque occurence dans les contenus du hCard.


=== parser les propriétés et valeurs de hCard ===
=== parser les propriétés et valeurs de hCard ===
Une fois qu'un élément pour une propriété est trouvé, les contenus de l'élément sont utilisés pour la valeur.


Une fois qu'un élément pour une propriété est trouvé, les contenus de l'élément sotn utilisés pour la valeur.
Il y a plusieurs exceptions pour concilier [[hcard-fr#Principes_de_Design_XHTML_Sémantique|le XHTML sémantique et plus d'équivalents sémantiques]].
 
===== propriété email =====
Il y a plusieurs exceptions pour concilier [http://microformats.org/wiki/hcard-fr#Principes_de_Design_XHTML_S.C3.A9mantique le XHTML sémantique et plus d'équivalents sémantiques].
 
Pour la propriété "email" en particulier, quand l'élément est :  
Pour la propriété "email" en particulier, quand l'élément est :  
* <code>&lt;a href="mailto:..."&gt;</code> OU <code>&lt;area href="mailto:..."&gt;</code> : parse la valeur de l'attribut 'href', en omettant le préfixe "mailto:" et tout suffixe de requête "?"  (si présent), dans l'attribut. Pour les détaisl sur le schéma URL "mailto:", voir RFC 2368.
* <code>&lt;a href="mailto:..."&gt;</code> OU <code>&lt;area href="mailto:..."&gt;</code> : parse la valeur de l'attribut 'href', en omettant le préfixe "mailto:" et tout suffixe de requête "?"  (si présent), dans l'attribut. Pour les détails sur le schéma URL "mailto:", voir la RFC 2368.
===== propriété tel=====
Pour la propriété "tel" en particulier, quand l'élément est :
* <code>&lt;a href="tel:..."&gt;</code> OU <code>&lt;area href="tel:..."&gt;</code> : parser la valeur de l'attribut 'href', en omettant le préfixe "tel:" et tout suffixe de requête "?" (si présent) dans l'attribut. Pour les détails sur le schéma URL "tel:" voir la RFC 2806.


Pour les propriétés qui peuvent prendre un type URL ou les parseurs URI DOIVENT gérer les URLs/URIs relatives et les normaliser selon leurs URLs/URIs absolus respectives, en suivant les règles de langage du document conteneur pour résoudre les URLs/URIs relatives (par ex. &lt;base&gt; pour le HTML, xml:base pour XML).  
===== propriétés du type URL ou URI =====
Pour les propriétés qui peuvent prendre un type URL ou les parseurs URI DOIVENT gérer les URLs/URIs relatives et les normaliser selon leurs URLs/URIs absolus respectifs, en suivant les règles de langage du document conteneur pour résoudre les URLs/URIs relatifs (par ex. &lt;base&gt; pour le HTML, xml:base pour XML).  


===== properties de type URL ou URI ou UID =====
Pour les propriétés qui peuvent prendre les types URL, URI, ou UID, quand l'élément pour cette propriété est :  
Pour les propriétés qui peuvent prendre les types URL, URI, ou UID, quand l'élément pour cette propriété est :  
* <code>&lt;a href&gt;</code>  OU <code>&lt;area href&gt;</code> : utiisez la valeur de l'attribut 'href'.
* <code>&lt;a href&gt;</code>  OU <code>&lt;area href&gt;</code> : utilisez la valeur de l'attribut 'href'.
* <code>&lt;img src&gt;</code> : utilisez la valeur de l'attribut 'src'.  Si le 'src' est une URL "data:", utilisez le type MIME dans cet URL "data:" pour la sous-propriété TYPE, autrement si l'attribut 'type' est présent, utilisez ça pour la sous-propriété TYPE.
* <code>&lt;img src&gt;</code> : utilisez la valeur de l'attribut 'src'.  Si le 'src' est une URL "data:", utilisez le type MIME dans cet URL "data:" pour la sous-propriété TYPE, autrement si l'attribut 'type' est présent, utilisez ça pour la sous-propriété TYPE.
* <code>&lt;object data&gt;</code> : utilisez la valeur de l'attribut 'data' pour la valeur. Si le 'data' est un URL "data:", utilisez le type MIME dans cet URL "data:" pour la sous-propriété TYPE, autrement si l'attribut 'type' est présent, utilisez ça pour la sous-propriété TYPE.
* <code>&lt;object data&gt;</code> : utilisez la valeur de l'attribut 'data' pour la valeur. Si le 'data' est un URL "data:", utilisez le type MIME dans cet URL "data:" pour la sous-propriété TYPE, autrement si l'attribut 'type' est présent, utilisez ça pour la sous-propriété TYPE.


===== propriétés pas du type URL ou URI ou UID =====
Pour les propriétés avec des valeurs qui ne SONT PAS du type URL, URI, ou UID, quand l'élément pour une propriété est :  
Pour les propriétés avec des valeurs qui ne SONT PAS du type URL, URI, ou UID, quand l'élément pour une propriété est :  
* <code>&lt;img alt&gt;</code> OU <code>&lt;area alt&gt;</code> : utilisez la valeur de l'attribut 'alt'.
* <code>&lt;img alt&gt;</code> OU <code>&lt;area alt&gt;</code> : utilisez la valeur de l'attribut 'alt'.


===== toutes les propriétés =====
Pour toutes les propriétés, quand l'élément pour une propriété est :  
Pour toutes les propriétés, quand l'élément pour une propriété est :  
* <code>&lt;abbr&gt;</code> : utilisez  la valeur de l'attribut 'title' si présent, autrement les contenus de l'élément.
* <code>&lt;abbr title&gt;</code> : utilisez  la valeur de l'attribut 'title'. S'il n'y a pas d'attribut 'title' utilisez alors les contenus de l'élément.
** Pour les propriétés qui peuvent prendre une valeur datetime ISO8601, les parseurs *devraient* rembourrer toute précision nécessaire (par ex. les secondes) et *devraient* normaliser tous les datetimes avec les "timezone offsets", (par ex. <code>20050814T2305-0700</code>) en UTC (<code>20050815T060500Z</code>).  Notez que les dates et heures flottantes NE DOIVENT PAS être produites en valurs de zones temps absolu UTC/Z.
** Pour les propriétés qui peuvent prendre une valeur datetime ISO8601, les parseurs *devraient* rembourrer toute précision nécessaire (par ex. les secondes) et *devraient* normaliser tous les datetimes avec les "timezone offsets", (par ex. <code>20050814T2305-0700</code>) en UTC (<code>20050815T060500Z</code>).  Notez que les dates et heures flottantes NE DOIVENT PAS être produites en valurs de zones temps absolu UTC/Z.
* <code>&lt;br /&gt;</code> OU <code>&lt;hr /&gt;</code> : la valeur est la chaîne vide. Ces deux éléments ne représentent pas quelque sémantique et par conséquent c'est probablement une erreur (au moins un abus) pour un auteur de les utiliser avec les noms de classe microformats. Néanmoins, s'ils sont trouvés, traitez la valeur comme vide.
* <code>&lt;br /&gt;</code> OU <code>&lt;hr /&gt;</code> : la valeur est la chaîne vide. Ces deux éléments ne représentent pas quelque sémantique et par conséquent c'est probablement une erreur (au moins un abus) pour un auteur de les utiliser avec les noms de classe microformats. Néanmoins, s'ils sont trouvés, traitez la valeur comme vide.
Line 120: Line 119:


=== sous-propriétés hCard ===
=== sous-propriétés hCard ===
Il y a quelques propriétés hCard dont les valeurs elles-même ont une structure (comme des valeurs type structurées) et sont composées de plusieurs morceaux, dont nous faisons référence à des sous-propriétés.
Il y a quelques propriétés hCard dont les valeurs elles-même ont une structure (comme des valeurs type structurées) et sont composées de plusieurs morceaux, dont nous faisons référence à des sous-propriétés.


Line 131: Line 129:
</pre>
</pre>


Dans hCard cette propriété "n" serait marquée comme :  
Dans [[hcard-fr|hCard]] cette propriété "n" serait marquée comme :  
<pre>
<pre>
<span class="n">
<span class="n">
Line 149: Line 147:
=== paramètres propriétés hCard ===
=== paramètres propriétés hCard ===


Quelques propriétés hCard ont un paramètre ou plus, plus souvent "type", avec un ensemble numéroté de valeurs. Nous représentons la ''value'' spécifique du paramètre comme un nom de classe sur un élément à l'intérieur de l'élément représentant la propriété.
Quelques propriétés [[hcard-fr|hCard]] ont un paramètre ou plus, plus souvent "type", avec un ensemble numéroté de valeurs. Nous représentons la ''value'' spécifique du paramètre comme un nom de classe sur un élément à l'intérieur de l'élément représentant la propriété.


Par exemple, la propriété "adr" a un paramtère type qui prend les valeurs : "dom", "intl", "post", "parcel", "home", "work", "pref".
Par exemple, la propriété "adr" a un paramtère type qui prend les valeurs : "dom", "intl", "post", "parcel", "home", "work", "pref".
Line 167: Line 165:


=== extraction Value ===
=== extraction Value ===
Notez l'élément avec class="value" utilisé dans l'exemple au-dessus.
Notez l'élément avec class="value" utilisé dans l'exemple au-dessus.


Parfois, seule une partie d'un élément qui est l'équivalent pour une propriété devrait être utilisée pour la valeur de la propriété. Ceci arrive typiquement quand une propriété a un sous-type, comme TEL. Pour ce but, le nom de classe spécial "value" est introduit pour extraire le sous-ensemble de l'élément qui est la valeur de la propriété.
Parfois, seule une partie d'un élément qui est l'équivalent pour une propriété devrait être utilisée pour la valeur de la propriété. Ceci arrive typiquement quand une propriété a un sous-type, comme TEL. Pour ce but, le nom de classe spécial "value" est introduit pour extraire le sous-ensemble de l'élément qui est la valeur de la propriété.


== Proposed Additions ==
== Additions Proposées ==
Ce sont des additions proposés pour le parsage de hCard. Les implémentations PEUVENT suivre ces conventions afin de gagner en expérience d'implémentation et DEVRAIENT rendre compte des résultats.
Ce sont des additions proposées pour le parsage de hCard. Les implémentations PEUVENT suivre ces conventions afin de gagner en expérience d'implémentation et DEVRAIENT rendre compte des résultats.


=== gestion élément DEL ===
=== gestion élément DEL ===
Au moment de traiter avec un document HTML qui est encodé hCard, le parseur DEVRAIT honorer l'élément <code>&lt;del&gt;</code>.
Au moment de traiter avec un document HTML qui est encodé hCard, le parseur DEVRAIT honorer l'élément <code>&lt;del&gt;</code>.


Line 185: Line 181:
2. Si l'élément <code>&lt;del&gt;</code> est utilisé pour une propriété en elle-même, il pourrait être utile comme un moyen de communication de mettre une pierre tombale / rendre obsolète cette valeur particulière de propriété, et de fait alors qu'un parseur en train de convertir vers une vCard DEVRAIT  simplement faire ce qui est indiqué dans (1), les applications qui ont directement parsé hCard (plutôt que de seulement supporter vCard) POURRAIENT traiter de telles occurences d'éléments <code>&lt;del&gt;</code> comme un moyen d'ôter l'information obsolète (avec la confirmation de l'utilisateur bien sûr) d'un stockage local de l'information contact.
2. Si l'élément <code>&lt;del&gt;</code> est utilisé pour une propriété en elle-même, il pourrait être utile comme un moyen de communication de mettre une pierre tombale / rendre obsolète cette valeur particulière de propriété, et de fait alors qu'un parseur en train de convertir vers une vCard DEVRAIT  simplement faire ce qui est indiqué dans (1), les applications qui ont directement parsé hCard (plutôt que de seulement supporter vCard) POURRAIENT traiter de telles occurences d'éléments <code>&lt;del&gt;</code> comme un moyen d'ôter l'information obsolète (avec la confirmation de l'utilisateur bien sûr) d'un stockage local de l'information contact.


=== Misen en Forme Plein Texte du HTML Structurel/Sémantique ===
=== Mise en Forme Texte Simple du HTML Structurel/Sémantique ===
There are several structural/semantic elements in HTML which have useful default styling which could be converted into ASCII (AKA Plain Text) equivalents as a low resolution way of communicating that structure. Note that <code>&lt;br /&gt;</code> and <code>&lt;pre&gt;</code> are already handled in the section above titled [http://microformats.org/wiki/hcard-parsing#white-space_handling White-space Handling].
Il existe plusieurs éléments structurels/sémantiques dans le HTML qui ont un stylisme utile par défaut qui pourrait être converti en ASCII (plein texte) équivalents  à un moyen basse résolution de communiquer cette structure. Notez que <code>&lt;br /&gt;</code> et <code>&lt;pre&gt;</code> sont déjà gérés dans la section titrée ci-dessus [[hcard-parsing-fr#gestion_espace_blanc|Gestion des espaces blancs]].


When parsing the DESCRIPTION property, hierarchically convert the following HTML tags into their plain text styling equivalents.
Au moment de parser la propriété DESCRIPTION, convertissez hiérarchiquement les tags HMTL suivants dans leurs équivalents stylisés en plein texte.
 
* <code>&lt;div&gt;</code>, <code>&lt;/div&gt;</code>, <code>&lt;dl&gt;</code>,  <code>&lt;/dl&gt;</code>, <code>&lt;dt&gt;</code>, <code>&lt;/li&gt;</code>, <code>&lt;/dd&gt;</code> - Append a soft <code>\n</code> to the output. By "soft <code>\n</code>", we mean only do so if there isn't already a line break (in contrast to a "hard" (implied by default) <code>\n</code>).  Two things in particular order to ensure that <code>&lt;div&gt; &lt;div&gt;</code> does not result in two <code>\n</code> characters in a row:
*# only output the <code>\n</code> if something other than whitespace (including  <code>\n</code>) was outputted immediately previously.
*# omit any immediately subsequent whitespace characters.
* <code>&lt;li&gt;</code> - Append a soft <code>\n</code> and then </code> * </code>. (Note: Indenting the contents of the list item is not particularly practical, since that would require line-breaking, and that would depend on knowing the width of when the plain text is rendered.  Wrapping to 70 characters may be a good assumption for plain text email, but is probably a very bad assumption for vCard output).
* <code>&lt;/dt&gt;</code> - Append <code>:\n</code>
* <code>&lt;dd&gt;</code> - Append a soft <code>\n</code> and then </code>  </code> (two space ASCII 32 characters).
* <code>&lt;h1&gt;</code>, <code>&lt;/h1&gt;</code>, <code>&lt;h2&gt;</code>, <code>&lt;/h2&gt;</code>, <code>&lt;h3&gt;</code>, <code>&lt;/h3&gt;</code>, <code>&lt;h4&gt;</code>, <code>&lt;/h4&gt;</code>, <code>&lt;h5&gt;</code>, <code>&lt;/h5&gt;</code>, <code>&lt;h6&gt;</code>, <code>&lt;/h6&gt;</code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>.  (Note: we may want to consider some conventions to indicate the heading level.  Perhaps only the relative heading level inside the property matters, e.g. whatever level HTML heading is seen first is treated as a first level heading, then any subsequent HTML heading elements are treated relative to that original heading (this is because it is likely that the property is embedded somewhere deep inside an HTML document following higher heading levels).  Any subsequent higher level headings should perhaps cause a warning, and then simply be treated as a first level heading.  Given that, the [http://microformats.org/wiki/wiki-formats#straw_proposals straw proposal for heading syntax] from Ian Hickson is one reasonable possibility, with the only issue being that for first and second level headings, how wide to make the line of '-'s or '='s, which is a similar problem to the line-breaking problem noted above when considering indenting the contents of list-items.  Thus perhaps it might be sufficient to simply set a first level heading in ALL CAPS (same as the third level heading in Ian's proposed syntax), and let second and deeper level headings be simply implied by the "one line of text with two line breaks both before and after" convention.  Rarely has there been more than one level of heading found within a DESCRIPTION property, and I've never seen more than two even if it is possible.)
* <code>&lt;p&gt;</code>, <code>&lt;/p&gt;</code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>. (Note: Typical books indent the start of a paragraph approximately three spaces "<code>  </code>", and implementations may wish to consider doing so as well. Keep in mind that on the Web, typical paragraphs do not start with a first line indent.)
* <code>&lt;q&gt;</code>, <code>&lt;/q&gt;</code> - Append a double-quote '"' character.
* <code>&lt;sub&gt;</code> - Append an open parenthesis "("
* <code>&lt;/sub&gt;</code> - Append a a close parenthesis ")".
* <code>&lt;sup&gt;</code> - Append an open bracket "["
* <code>&lt;/sup&gt;</code> - Append a a close bracket "[".  <code>&lt;sup&gt;</code> are often used for footnotes which in plain text are often formatted as bracketed numbers.
* <code>&lt;table&gt;</code>, <code>&lt;/table&gt;</code>, <code>&lt;tbodygt;</code>, <code>&lt;/tbody&gt;</code>, <code>&lt;thead&gt;</code>, <code>&lt;/thead&gt;</code>, <code>&lt;tfoot&gt;</code>, <code>&lt;/tfoot&gt;</code>, <code>&lt;tr&gt;</code>, <code>&lt;/tr&gt;</code>, <code>&lt;caption&gt;</code>, <code>&lt;/caption&gt;</code> - Append a soft <code>\n</code>.  Of course one could try to do a lot more with representing the structure of the table, but that is almost certainly more work than it is worth, nevermind the complexities introduced by COLSPAN, ROWSPAN etc.  At least by approximating the table sections and rows the table may be more readable.
* <code>&lt;/td&gt;</code>, <code>&lt;/th&gt;</code> - Append a space and a tab character (ASCII 32, ASCII 9 respectively).  It's not clear that what subsequent application would be able to make use of this visually, but at least the tabular nature of the structure is indicated and it makes it possible to copy and paste the table into something that handles tabular content like a spreadsheet and have the tabular structure reflected.


* <code>&lt;div&gt;</code>, <code>&lt;/div&gt;</code>, <code>&lt;dl&gt;</code>,  <code>&lt;/dl&gt;</code>, <code>&lt;dt&gt;</code>, <code>&lt;/li&gt;</code>, <code>&lt;/dd&gt;</code> - fournit un <code>\n</code> doux vers la sortie. Par <code>\n</code> doux", nous voulons seulement dire faire ainsi s'il n'y a pas déjà un saut de ligne (à l'opposé d'un <code>\n</code>) "dur" (implicite par défaut).  Deux choses en particuliers visent à garantir que <code>&lt;div&gt; &lt;div&gt;</code> ne résulte pas en deux caractères <code>\n</code> dans une ligne :
*# seulement sortir <code>\n</code> si quelque chose d'autre que l'espace blanc (y compris  <code>\n</code>) a été sorti immédiatement avant.
*# omettre tout caractère espace blanc immédiatement subséquent.
* <code>&lt;li&gt;</code> - Ajouter un <code>\n</code> doux et puis </code> * </code>. (Note : Indenter les contenus de la liste d'item n'est pas particulièrement pratique, parce que cela obligerait au saut de ligne, et cela dépendrait de connaître la largeur quand le plein texte est restitué. Emballer à 70 caractères peut être une bonne hypothèse pour un email en plein texte, mais c'est probablement une très mauvaise hypothèse pour la sortie vCard).
* <code>&lt;/dt&gt;</code> - ajouter à <code>:\n</code>
* <code>&lt;dd&gt;</code> - ajouter un <code>\n</code> doux et puis </code>  </code> (deux espaces ASCII de 32 caractères).
* <code>&lt;h1&gt;</code>, <code>&lt;/h1&gt;</code>, <code>&lt;h2&gt;</code>, <code>&lt;/h2&gt;</code>, <code>&lt;h3&gt;</code>, <code>&lt;/h3&gt;</code>, <code>&lt;h4&gt;</code>, <code>&lt;/h4&gt;</code>, <code>&lt;h5&gt;</code>, <code>&lt;/h5&gt;</code>, <code>&lt;h6&gt;</code>, <code>&lt;/h6&gt;</code> - Ajouter un  <code>\n</code> doux suivi par un <code>\n</code> dur.  (Note : nous pouvons vouloir considérer quelques conventions pour indiquer le niveau de titre. Peut-être que seul le niveau de titre relatif dans la propriété compte, par ex. quel que soit le niveau de titre HTML qui soit vu en premier est traité comme un titre de niveau 1, puis tout élément subséquent HTML de titre est traité relativement avec ce titrage original (ceci parce qu'il est probable que la propriété soit encapsulée quelque part profond dans un document HTML en suivant des niveaux de titre plus élevés.) Tout niveau de titre subséquent à un niveau plus haut pourrait peut-être provoquer un avertissement, et puis simplement être traité comme un titre de niveau un. Compte tenu de cela, la [wiki-formats-fr#proposition_de_paille proposition de paille pour la syntaxe de titre] de Ian Hickson est une possibilité raisonnable, avec la seule problématique étant que pour les titres de niveau 1 et de niveau 2, à quelle largeur faire la ligne des '-'s ou '='s, ce qui est un problème similaire au problème du saut de ligne noté au-dessus quand on considère d'indenter les contenus d'items de liste. Ainsi peut-être qu'il pourrait être suffisant de régler simplement un premier niveau de titre TOUT EN CAPITALES (le même que le troisième niveau de titre dans la syntaxe proposée par Ian), et laisser les niveaux de titres de niveau deux et en dessous être simplement implicites par la convention "une ligne de texte avec deux sauts de ligne à la fois avant et après".  Rarement il y a eu plus d'un niveau de titre trouvé dans une propriété DESCRIPTION et je n'en ai jamais vu plus de deux même si c'est possible.)
* <code>&lt;p&gt;</code>, <code>&lt;/p&gt;</code> - Ajoute un <code>\n</code> doux suivia par un <code>\n</code> dur. (Note : Les livres indentent généralement le début d'un paragraphe approximativement de trois espaces "<code>  </code>", et les implémentations peuvent vouloir considérer faire ainsi. Gardez en tête que sur le Web, les paragraphes typiques ne commencent pas avec une première ligne indentée.)
* <code>&lt;q&gt;</code>, <code>&lt;/q&gt;</code> - Ajoute un caractère double guillemet'"'.
* <code>&lt;sub&gt;</code> - Ajoute une parenthèse ouverte "("
* <code>&lt;/sub&gt;</code> -  Ajoute une parenthèse fermée ")".
* <code>&lt;sup&gt;</code> -  Ajoute un crochet rectangulaire ouvert "["
* <code>&lt;/sup&gt;</code> - Ajoute un crochet rectangulaire fermé "]".  <code>&lt;sup&gt;</code> sont souvent utilisés pour les notes de pied de page qui en plein tete sont souvent formatées comme des nombres entre crochets numérotés.
* <code>&lt;table&gt;</code>, <code>&lt;/table&gt;</code>, <code>&lt;tbody&gt;</code>, <code>&lt;/tbody&gt;</code>, <code>&lt;thead&gt;</code>, <code>&lt;/thead&gt;</code>, <code>&lt;tfoot&gt;</code>, <code>&lt;/tfoot&gt;</code>, <code>&lt;tr&gt;</code>, <code>&lt;/tr&gt;</code>, <code>&lt;caption&gt;</code>, <code>&lt;/caption&gt;</code> - Ajoute un <code>\n</code> doux. Bien sûr on pourrait essayer de faire beaucoup plus en représentant la structure du tableau, mais ceci est surtout certainement plus de travail que cela n'en vaille la peine, peu importe les complexités introduites par COLSPAN, ROWSPAN etc.  Au moin par approximation des sections de table et de lignes la table peut être plus lisible.
* <code>&lt;/td&gt;</code>, <code>&lt;/th&gt;</code> - Ajoute un espace et un caractère tabulation (respectivement ASCII 32, ASCII 9).  Il n'est pas clair quelle est l'application subséquente qui serait capable de faire usage de cela visuellement, mais au moins la nature tabulaire de la struture est indiquée et cela rend possible de copier et coller la table dans quelque chose qui gère le contenu tablulaire comme une feuille de style et d'avoir la structure tabulaire réfléchie.


==== Plus d'éléments stimulants ====
==== Plus d'éléments stimulants ====
* <code>&lt;ol&gt;</code> - it would be nice to number list items inside an ordered list rather than bullet them, but keeping track of list item numbers/counts is a non-trivial piece of state information for the parser to deal with, and thus we are omitting this behavior for now.
* <code>&lt;ol&gt;</code> - ce serait bien de numéroter les items de listes dans une liste triée plutôt que d'y mettre des puces, mais conserver une trace des numéros d'items de listes est un morceau d'information non trivial à traiter pour le parseur, et de ce fait nous omettons ce comportement pour le moment.
 


==== Usage de styles informatiques CSS au lieu de styles par défaut HTML ====
==== Usage de styles informatiques CSS au lieu de styles par défaut HTML ====
Rather than assuming the default presentation for these elements, and using that for the basis of plain text formatting, a parser could use the respective equivalent computed style properties and use those instead. However, requiring an hCard parser to also implement Cascading Style Sheets (e.g. CSS1) is out of scope. Some environments (i.e. a browser DOM) may already provide this information, and in that case, it may be easy for an hCard parser (e.g. a clientside javascript parser) to use computed style properties.  E.g. instead of the elements above, the following computed styles could be used:
Plutôt que d'assumer la présentation par défaut pour ces éléments, et utiliser ça pour la base d'une mise en forme en plein-texte, un parseur pourrait utiliser l'équivalent des propriétés respectives équivalentes de style par la machine et les utiliser à la place. Néanmoins, obliger un parseur hCard à implémenter aussi les Feuilles de Styles en Cascade (par ex. CSS1) est hors du champ de la réflexion. Quelques environnements (par ex un navigateur DOM) peuvent déjà fournir cette information et dans ce cas, il peut être facile pour un parseur hCard (par ex. un parseur client javascript) d'utiliser les propriétés informatiques de mise en style. Par ex. au lieu des éléments ci-dessus, les styles suivis par la machine pourraient être utilisés :
* display:block - Append a soft <code>\n</code>
* display:block - fournit un <code>\n</code> doux
** text-indent (non-zero value, on an element with display:block or display:list-item) - Append a number of spaces equivalent to value of the text-ident property divided by the computed font-size property of the element.
** text-indent (valeur non nulle, sur un élément avec display:block ou display:list-item) - Ajoute un nombre d'espaces équivalent à la valeur de la propriété text-ident divisé par la propriété informatique font-size de l'élément.
** margin-top, margin-bottom (non-zero value, on an element with display:block or display:list-item) - Append a number of "\n" equivalent to the value divided by the computed font-size property of the elementObviously this won't properly collapse vertical margins.  
** margin-top, margin-bottom (valeur non nulle, sur un élément avec display:block ou display:list-item) - Ajoute un nombre de "\n" équivalent à la valeur divisé par la propriété font-size de l'élémentEvidemment ceci ne résoudra pas proprement la destruction des marges verticales.
* display:list-item - Append a soft <code>\n</code> followed by " * "
* display:list-item - Ajoute un <code>\n</code> doux suivi de " * "
* etc.   
* etc.   
This is enough extra work that I'm not sure it is worth spending the time documenting more equivalents. The above are sufficient to illustrate the possibility.
Ceci est assez de travail supplémentaire sur lequel je ne suis pas certain que cela vaille la peine de passer du temps et de documenter plus d'équivalents. Les données au-dessus sont suffisantes pour illustrer la possibilité.


== Problématiques étonnantes ==
== Problématiques étonnantes ==


=== Issues 3 ===
=== Problématiques 3 ===
 
Il pourrait être valable de considérer la définition du parsage en terme de DOM, de façon que cela s'applique au HTML et XHTML également sans ambiguïté.
Might be worth considering defining the parsing in terms of the DOM, so that it applies to HTML and XHTML equally without ambiguity.


== Problématiques Résolues ==
== Problématiques Résolues ==
Cette section est informative.


This section is informative.
Les problématiques suivantes ont été explorées et résolues.
 
The following issues have been explored and resolved


=== Résolue le 16 septembre 2005 ===
=== Résolue le 16 septembre 2005 ===


==== PROBLEMATIQUE 1 ====
==== PROBLEMATIQUE 1 ====
 
Devrions-nous produire les noms de sous-propriété pluriel en versions singulières et simplement permettre plusieurs instances ? par ex. le préfixe singulier honorifique ferait plus de sens s'il était classé tel quel, et la liste implicite par la valeur pour les "honorific-suffix" pourrait être produite de façon plus explicite (et de ce fait plus facilement parsable par une machine) :
Should we make plural sub-property names into singular versions and simply allow multiple instances? I.e. the singular honorific prefix would make more sense if it was classed as such, and the list implied by the value for honorific-suffixes could be made more explicit (and thus more easily machine parseable):


<pre>
<pre>
Line 249: Line 240:
</pre>
</pre>


RESOLUTION: Adopt singular class name equivalents for plural property and sub-property names.
RESOLUTION : Adopter des noms de classe singuliers équivalents pour une propriété plurielle et des noms de sous-propriété.




==== PROBLEMATIQUE 2 ====
==== PROBLEMATIQUE 2 ====
Restreindre les valeurs de sous-propriétés "type" à être exprimées en noms de classe semble moins qu'idéal. Cela prend un morceau d'information qui est très souvent visible dans le contenu et le force à être invisible.


Restricting the "type" sub-property values to being expressed in class names seems less than ideal.  It's taking a piece of information which is very often visible in the content, and forcing it to be invisible.
Voici un exemple d'un morceau important d'information sur une page web :
 
Here is an example of an extensive bit of contact information on a web page:


http://www.patchlink.com/company/contact.html
http://www.patchlink.com/company/contact.html
Line 270: Line 260:
</pre>
</pre>


Note that the type information for each "adr" is explicit in the content. This content could be marked up like this:
Notez que le type d'information pour chaque "adr" est explicite dans le contenu. Ce contenu pourrait être balisé comme ceci :  


<pre>
<pre>
<div class="adr">
<div class="adr">
<abbr style="display:block" class="type" title="postal,parcel">Mailing Address</abbr>
<abbr style="display:block" class="type" title="postal,parcel">Adresse Postale</abbr>
<div class="street-address">3370 N. Hayden Road, #123-175</div>
<div class="street-address">3370 N. Hayden Road, #123-175</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>
Line 280: Line 270:
</div>
</div>
<div class="adr">
<div class="adr">
<abbr style="display:block" class="type" title="work,pref">Physical Address</abbr>
<abbr style="display:block" class="type" title="work,pref">Adresse Physique</abbr>
<div class="street-address">8515 E Anderson</div>
<div class="street-address">8515 E Anderson</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>  
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>  
Line 287: Line 277:
</pre>
</pre>


RESOLUTION: The "type" parameter MUST be marked-up when content is available (like the above two examples). We are ditching the type-value-as-another class name pattern.
RESOLUTION : Le paramètre "type" DOIT être balisé quand le contenu est disponible (comme dans les deux exemples au-dessus). Nous laissons tomber le modèle de nom de classe type-value-as-another.


In addition since there are some potentical problems with the "type" parameter for TEL and EMAIL properties. Since there are no defined sub-properties (unlike ADR's post-code, locality, etc) the entire node-value of TEL is taken as the value. For example:
En outre, parce qu'il y a quelques problèmes potentiels avec le paramètre "type" pour les propriétés TEL et EMAIL. Parce qu'il n'y a pas de sous-propriétés définies (à la différence du post-code de l'ADR, locality, etc) la valeur-noeud complète de TEL est prise comme la valeur. Par exemple :  
<pre>
<pre>
<span class="tel">+1.123.456.7890 <abbr class="type" title="work">(work)</abbr></span>
<span class="tel">+1.123.456.7890 <abbr class="type" title="work">(work)</abbr></span>
</pre>
</pre>
would be represented in vCard as:
serait représenté dans la vCard comme :
<pre>
<pre>
TEL;TYPE=work:+123.456.7890 (work)
TEL;TYPE=work:+123.456.7890 (work)
</pre>
</pre>


We are introducing another sub-property class="value" to enable excerpting of a the value of an element of for a property.
Nous introduisons une autre sous-propriété class="value" pour permettre l'extraction d'une valeur d'un élément ou pour une propriété.


<pre>
<pre>
Line 304: Line 294:
</pre>
</pre>


Then parsers would first need to look for class="value" and take the node value of that if it exists rather than class="tel".
Alors les parseurs auraient d'abord besoin de chercher class="value" et de prendre la valeur noeud de cela si elle existe plutôt que than class="tel".


If one or more child elements with the class name of "value" are present inside the element for a property, then concatenate the node values of those child elements (in the order found) and use that as the value of the property. This would be before using the node value of the element for a property itself.
Si un ou plusieurs éléments enfants avec le nom de classe de "value" sont présents dans l'élément pour une propriété, alors concaténez les valeurs noeuds de ces éléments enfants (dans l'ordre trouvé) et utilisez ça comme la valeur de la propriété. Ceci serait avant la valeur noeud de l'élément pour une propriété elle-même.


== Références ==
== Références ==
=== Références Normatives ===
=== Références Normatives ===
* [[hcard-fr|hCard]]
* [[hcard-fr|hCard]]
Line 319: Line 308:
=== Références Informatives ===
=== Références Informatives ===
* [http://w3.org/TR/REC-CSS1 CSS1 Recommendation]
* [http://w3.org/TR/REC-CSS1 CSS1 Recommendation]
== Pages Apparentées ==
{{hcard-related-pages-fr}}

Latest revision as of 19:24, 3 January 2009

parsage hCard

par Tantek Çelik

(traduction en cours Christophe Ducamp)

introduction

Quand j'ai initialement conçu hCard, il était clair pour moi de savoir comment parser sans ambiguïté tant l'existence de hCards dans du (X)HTML arbitraire (et n'importe où ce pouvait être embarqué dans du (X)HTML arbitraire, par ex. RSS, Atom, "XML générique") que les propriétés et valeurs de hCard.

J'ai travaillé directement avec Brian Suda pour saisir ces idées dans une implémentation, et Brian a écrit X2V, un script XSLT qui convertit les hCards en vCards, démontrant ainsi simultanément la parsabilité des hCards et l'utilité immédiate du contenu hCard interopérant avec les applications existantes massivement répandues de vCard.

Je vais maintenant documenter ces idées directement sur cette page, de façon à ce que des implémentations supplémentaires puissent être construites à partir de ces concepts élémentaires, plutôt que d'avoir à faire du reverse engineering sur X2V.

étendue

Bien que cette page soit écrite spécifiquement pour expliquer comment parser hCard, les concepts et algorithmes contenus à l'intérieur servent comme exemple pour la façon dont d'autres microformats composés vont se faire parser.

Gestion URL

Un parseur hCard peut commencer par un URL à récupérer.

Si l'URL manque d'un identifiant de fragment, alors le parseur devrait parser la ressource complète retrouvée pour les hCards.

Si l'URL a un identitfiant de fragment, alors le parseur ne devrait parser que le noeud indiqué par l'identifiant de fragment et ses descendants, chercher des hCards, démarrer avec le noeud indiqué, qui peut lui-même être une simple hCard.


nom de classe racine

Chaque microformat composé commence par un élément racine avec un nom de classe relativement unique. Par cela, je veux dire un nom de classe qui n'est pas simplement un mot commun, et qui devra être peu probablement être utilisé à l'extérieur du contexte du microformat. En choisissant un tel nom de classe racine, le microformat évite (pour toutes les intentions pratiques) de rentrer en conflit avec des noms de classe existants qui peuvent exister dans le contexte (X)HTML. Ceci est essentiel pour permettre à de tels microformats composés d'être embarqués dans le contenu actuel, existant, tout comme le contenu futur.

Heureusement ce n'est pas un nouveau problème à résoudre. Les noms d'objets racine choisis pour la vCard (RFC 2426) et iCalendar (RFC 2445) ont eu de la même manière à éviter de telles collisions et l'ont fait en choisissant des noms qui devraient peu probablement être introduits à l'intérieur d'un objet contexte MIME. Le principe de réutilisation dicte le fait que nous devrions réutiliser les noms pour ces objets racine dans ces RFCs plutôt que d'inventer les nôtres. Compte tenu de la même sémantique, un design devrait réutiliser les noms, plutôt que d'inventer un second nom pour la même sémantique (une erreur commune de design produite dans des environnements qui requièrent des espaces-noms).

Dans la spécification vCard, les noms ne sont pas sensibles à la casse du aux (manques) d'exigences de leur contexte. Les noms de classes (X)HTML sont sensibles à la casse par ces spécifications. De ce fait, nous sommes obligés de choisir une casse canonique pour les noms de classe équivalents des noms d'objets, et des noms de propriétés de vCard. Toutes les bas de casse sont choisies pour suivre le réglage précédent (c'est à dire le modèle reuse) par le XHTML, ce qui devait de la même manière canoniser la casse de l'élément et les noms d'attributs que cela prenait du HTML4, qui lui-même était insensible à la casse du fait de son contexte (SGML). En outre, les raisons d'éviter le mélange de casse (par ex. la casse chatmot) dans le contexte de noms de classes peuvent être trouvées dans l'article A Touch of Class, spécifiquement, la section titrée Class sensitivity.

Par conséquent, le nom de classe racine d'un hCard est "vcard".

trouver des hCards

Un document (X)HTML indique qu'il peut contenir des hCards en référençant le profil XMDP de hCard. Voir XMDP pour plus de détails.

Un parseur trouve des hCards dans un contexte (X)HTML en cherchant des éléments avec le nom de classe racine vcard tout simplement comme le fait le [sélecteur de classe CSS suivant :

 .vcard

Par exemple, la déclaration de règle de style CSS suivante fixe l'arrière-plan de toutes les hCards en vert :

 .vcard { background: green; }

Notez que l'attribut de classe (X)HTML est un espace séparé par des noms de classe.

de ce fait tout ce qui suit sont des éléments racines valides hCard :

  • <div class="vcard"> </div>
  • <span class="attendee vcard"> </span>
  • <address class="vcard author"> </address>
  • <li class="reviewer vcard first"> </li>

Une fois l'élément racine d'une hCard trouvé, cet élément-là et tous ses descendants sont tout ce qui est exigé pour parser la hCard.

Par conséquent, il est possible pour une hCard bien formée d'être extraite à partir d'un contexte général non bien-formé, si le parseur a la capacité de trouver des éléments par nom de classe dans ce contexte non bien-formé.

propriétés hCard

La liste complète des noms de classe pour les propriétés hCard est documentée sur la page hCard profile.

parsage compatible avant

Au moment de parser les contenus d'une hCard, tous les noms de classe non reconnus doivent être ignorés.

De la même manière, les valeurs non reconnues pour les propriétés de hCard doivent être aussi ignorées.

trouver des propriétés hCard

Pour parser une hCard pour une propriété hCard (par ex. "fn"), le parseur cherche simplement le premier élément avec ce nom de classe à l'intérieur de hCard.

Ceci peut être aussi exprimé comme le premier élément qui correspond à ce sélecteur CSS :

.vcard .fn

Quelques propriétés, comme "fn", ne devraient seulement apparaître qu'une fois, et par conséquent le parseur arrête de chercher la propriété après qu'il ait trouvé une occurence. Les occurences supplémentaires sont ignorées.

D'autres propriétés comme "adr", "email", "url", "tel", etc., peuvent (et le font souvent) apparaître plus d'une fois, et par conséquent le parseur continue à regarder chaque occurence dans les contenus du hCard.

parser les propriétés et valeurs de hCard

Une fois qu'un élément pour une propriété est trouvé, les contenus de l'élément sont utilisés pour la valeur.

Il y a plusieurs exceptions pour concilier le XHTML sémantique et plus d'équivalents sémantiques.

propriété email

Pour la propriété "email" en particulier, quand l'élément est :

  • <a href="mailto:..."> OU <area href="mailto:..."> : parse la valeur de l'attribut 'href', en omettant le préfixe "mailto:" et tout suffixe de requête "?" (si présent), dans l'attribut. Pour les détails sur le schéma URL "mailto:", voir la RFC 2368.
propriété tel

Pour la propriété "tel" en particulier, quand l'élément est :

  • <a href="tel:..."> OU <area href="tel:..."> : parser la valeur de l'attribut 'href', en omettant le préfixe "tel:" et tout suffixe de requête "?" (si présent) dans l'attribut. Pour les détails sur le schéma URL "tel:" voir la RFC 2806.
propriétés du type URL ou URI

Pour les propriétés qui peuvent prendre un type URL ou les parseurs URI DOIVENT gérer les URLs/URIs relatives et les normaliser selon leurs URLs/URIs absolus respectifs, en suivant les règles de langage du document conteneur pour résoudre les URLs/URIs relatifs (par ex. <base> pour le HTML, xml:base pour XML).

properties de type URL ou URI ou UID

Pour les propriétés qui peuvent prendre les types URL, URI, ou UID, quand l'élément pour cette propriété est :

  • <a href> OU <area href> : utilisez la valeur de l'attribut 'href'.
  • <img src> : utilisez la valeur de l'attribut 'src'. Si le 'src' est une URL "data:", utilisez le type MIME dans cet URL "data:" pour la sous-propriété TYPE, autrement si l'attribut 'type' est présent, utilisez ça pour la sous-propriété TYPE.
  • <object data> : utilisez la valeur de l'attribut 'data' pour la valeur. Si le 'data' est un URL "data:", utilisez le type MIME dans cet URL "data:" pour la sous-propriété TYPE, autrement si l'attribut 'type' est présent, utilisez ça pour la sous-propriété TYPE.
propriétés pas du type URL ou URI ou UID

Pour les propriétés avec des valeurs qui ne SONT PAS du type URL, URI, ou UID, quand l'élément pour une propriété est :

  • <img alt> OU <area alt> : utilisez la valeur de l'attribut 'alt'.
toutes les propriétés

Pour toutes les propriétés, quand l'élément pour une propriété est :

  • <abbr title> : utilisez la valeur de l'attribut 'title'. S'il n'y a pas d'attribut 'title' utilisez alors les contenus de l'élément.
    • Pour les propriétés qui peuvent prendre une valeur datetime ISO8601, les parseurs *devraient* rembourrer toute précision nécessaire (par ex. les secondes) et *devraient* normaliser tous les datetimes avec les "timezone offsets", (par ex. 20050814T2305-0700) en UTC (20050815T060500Z). Notez que les dates et heures flottantes NE DOIVENT PAS être produites en valurs de zones temps absolu UTC/Z.
  • <br /> OU <hr /> : la valeur est la chaîne vide. Ces deux éléments ne représentent pas quelque sémantique et par conséquent c'est probablement une erreur (au moins un abus) pour un auteur de les utiliser avec les noms de classe microformats. Néanmoins, s'ils sont trouvés, traitez la valeur comme vide.

Pour toutes les propriétés, si l'élément pour une propriété a un enfant ou plus avec un nom de classe "value", alors concaténez les valeurs de noeud pour tous ces éléments enfants avec le nom de classe "value' dans l'ordre du document, et utilisez cette concaténation comme la valeur de la propriété.

gestion espace blanc

Les parseurs hCard devraient gérer le parsage selon les règles de gestion d'espace blanc, avec les deux additions suivantes :

  1. gestion <pre>. Tout contenu parsé en tant que partie d'une propriété hCard qui est à l'intérieur d'un élément <pre> doit préserver tous les espaces-blancs selon les règles de préservation des espaces-blancs.
  2. gestion de <br />. Toute occurence d'un <br /> à l'intérieur de(s) élément(s) pour une valeur doit être traitée comme un retour-chariot (\n) dans l'endroit respectif dans la valeur.

sous-propriétés hCard

Il y a quelques propriétés hCard dont les valeurs elles-même ont une structure (comme des valeurs type structurées) et sont composées de plusieurs morceaux, dont nous faisons référence à des sous-propriétés.

Par exemple, la propriété "n" comporte les sous-propriétés "family-name", "given-name", "additional-name", "honorific-prefix" et "honorific-suffix".

c'est à dire à partir de la section 3.1.2 de la RFC 2426, modifiée pour inclure Ph.D.

N:Public;John;Quinlan;Mr.;Esq.,Ph.D.

Dans hCard cette propriété "n" serait marquée comme :

<span class="n">
 <span class="honorific-prefix">Mr.</span>
 <span class="given-name">John</span>
 <span class="additional-name">Quinlan</span>
 <span class="family-name">Public</span>,
 <span class="honorific-suffix">Esq.</span>,
 <span class="honorific-suffix">Ph.D.</span>
</span>

qui pourrait être aussi restituée comme :

Mr. John Quinlan Public, Esq., Ph.D.

paramètres propriétés hCard

Quelques propriétés hCard ont un paramètre ou plus, plus souvent "type", avec un ensemble numéroté de valeurs. Nous représentons la value spécifique du paramètre comme un nom de classe sur un élément à l'intérieur de l'élément représentant la propriété.

Par exemple, la propriété "adr" a un paramtère type qui prend les valeurs : "dom", "intl", "post", "parcel", "home", "work", "pref".

Le paramètre "type" est traité comme une sous-propriété.

Pour encoder le "type" d'une propriété "adr", un élément imbriqué avec class="type" est utilisé pour baliser le paramètre type.

Exemple avec la propriété "tel" avec une valeur de type "work" :

<span class="tel">
 <span class="type">work</span>: 
 <span class="value">+1.123.456.7890</span>
</span>

extraction Value

Notez l'élément avec class="value" utilisé dans l'exemple au-dessus.

Parfois, seule une partie d'un élément qui est l'équivalent pour une propriété devrait être utilisée pour la valeur de la propriété. Ceci arrive typiquement quand une propriété a un sous-type, comme TEL. Pour ce but, le nom de classe spécial "value" est introduit pour extraire le sous-ensemble de l'élément qui est la valeur de la propriété.

Additions Proposées

Ce sont des additions proposées pour le parsage de hCard. Les implémentations PEUVENT suivre ces conventions afin de gagner en expérience d'implémentation et DEVRAIENT rendre compte des résultats.

gestion élément DEL

Au moment de traiter avec un document HTML qui est encodé hCard, le parseur DEVRAIT honorer l'élément <del>.

Il existe ici deux possibilités (adopter les deux peut être possible) :

1. Sautez toutes les occurences des éléments <del> et leurs contenus entièrement dans les contenus d'une propriété.

2. Si l'élément <del> est utilisé pour une propriété en elle-même, il pourrait être utile comme un moyen de communication de mettre une pierre tombale / rendre obsolète cette valeur particulière de propriété, et de fait alors qu'un parseur en train de convertir vers une vCard DEVRAIT simplement faire ce qui est indiqué dans (1), les applications qui ont directement parsé hCard (plutôt que de seulement supporter vCard) POURRAIENT traiter de telles occurences d'éléments <del> comme un moyen d'ôter l'information obsolète (avec la confirmation de l'utilisateur bien sûr) d'un stockage local de l'information contact.

Mise en Forme Texte Simple du HTML Structurel/Sémantique

Il existe plusieurs éléments structurels/sémantiques dans le HTML qui ont un stylisme utile par défaut qui pourrait être converti en ASCII (plein texte) équivalents à un moyen basse résolution de communiquer cette structure. Notez que <br /> et <pre> sont déjà gérés dans la section titrée ci-dessus Gestion des espaces blancs.

Au moment de parser la propriété DESCRIPTION, convertissez hiérarchiquement les tags HMTL suivants dans leurs équivalents stylisés en plein texte.

  • <div>, </div>, <dl>, </dl>, <dt>, </li>, </dd> - fournit un \n doux vers la sortie. Par \n doux", nous voulons seulement dire faire ainsi s'il n'y a pas déjà un saut de ligne (à l'opposé d'un \n) "dur" (implicite par défaut). Deux choses en particuliers visent à garantir que <div> <div> ne résulte pas en deux caractères \n dans une ligne :
    1. seulement sortir \n si quelque chose d'autre que l'espace blanc (y compris \n) a été sorti immédiatement avant.
    2. omettre tout caractère espace blanc immédiatement subséquent.
  • <li> - Ajouter un \n doux et puis * . (Note : Indenter les contenus de la liste d'item n'est pas particulièrement pratique, parce que cela obligerait au saut de ligne, et cela dépendrait de connaître la largeur quand le plein texte est restitué. Emballer à 70 caractères peut être une bonne hypothèse pour un email en plein texte, mais c'est probablement une très mauvaise hypothèse pour la sortie vCard).
  • </dt> - ajouter à :\n
  • <dd> - ajouter un \n doux et puis (deux espaces ASCII de 32 caractères).
  • <h1>, </h1>, <h2>, </h2>, <h3>, </h3>, <h4>, </h4>, <h5>, </h5>, <h6>, </h6> - Ajouter un \n doux suivi par un \n dur. (Note : nous pouvons vouloir considérer quelques conventions pour indiquer le niveau de titre. Peut-être que seul le niveau de titre relatif dans la propriété compte, par ex. quel que soit le niveau de titre HTML qui soit vu en premier est traité comme un titre de niveau 1, puis tout élément subséquent HTML de titre est traité relativement avec ce titrage original (ceci parce qu'il est probable que la propriété soit encapsulée quelque part profond dans un document HTML en suivant des niveaux de titre plus élevés.) Tout niveau de titre subséquent à un niveau plus haut pourrait peut-être provoquer un avertissement, et puis simplement être traité comme un titre de niveau un. Compte tenu de cela, la [wiki-formats-fr#proposition_de_paille proposition de paille pour la syntaxe de titre] de Ian Hickson est une possibilité raisonnable, avec la seule problématique étant que pour les titres de niveau 1 et de niveau 2, à quelle largeur faire la ligne des '-'s ou '='s, ce qui est un problème similaire au problème du saut de ligne noté au-dessus quand on considère d'indenter les contenus d'items de liste. Ainsi peut-être qu'il pourrait être suffisant de régler simplement un premier niveau de titre TOUT EN CAPITALES (le même que le troisième niveau de titre dans la syntaxe proposée par Ian), et laisser les niveaux de titres de niveau deux et en dessous être simplement implicites par la convention "une ligne de texte avec deux sauts de ligne à la fois avant et après". Rarement il y a eu plus d'un niveau de titre trouvé dans une propriété DESCRIPTION et je n'en ai jamais vu plus de deux même si c'est possible.)
  • <p>, </p> - Ajoute un \n doux suivia par un \n dur. (Note : Les livres indentent généralement le début d'un paragraphe approximativement de trois espaces " ", et les implémentations peuvent vouloir considérer faire ainsi. Gardez en tête que sur le Web, les paragraphes typiques ne commencent pas avec une première ligne indentée.)
  • <q>, </q> - Ajoute un caractère double guillemet'"'.
  • <sub> - Ajoute une parenthèse ouverte "("
  • </sub> - Ajoute une parenthèse fermée ")".
  • <sup> - Ajoute un crochet rectangulaire ouvert "["
  • </sup> - Ajoute un crochet rectangulaire fermé "]". <sup> sont souvent utilisés pour les notes de pied de page qui en plein tete sont souvent formatées comme des nombres entre crochets numérotés.
  • <table>, </table>, <tbody>, </tbody>, <thead>, </thead>, <tfoot>, </tfoot>, <tr>, </tr>, <caption>, </caption> - Ajoute un \n doux. Bien sûr on pourrait essayer de faire beaucoup plus en représentant la structure du tableau, mais ceci est surtout certainement plus de travail que cela n'en vaille la peine, peu importe les complexités introduites par COLSPAN, ROWSPAN etc. Au moin par approximation des sections de table et de lignes la table peut être plus lisible.
  • </td>, </th> - Ajoute un espace et un caractère tabulation (respectivement ASCII 32, ASCII 9). Il n'est pas clair quelle est l'application subséquente qui serait capable de faire usage de cela visuellement, mais au moins la nature tabulaire de la struture est indiquée et cela rend possible de copier et coller la table dans quelque chose qui gère le contenu tablulaire comme une feuille de style et d'avoir la structure tabulaire réfléchie.

Plus d'éléments stimulants

  • <ol> - ce serait bien de numéroter les items de listes dans une liste triée plutôt que d'y mettre des puces, mais conserver une trace des numéros d'items de listes est un morceau d'information non trivial à traiter pour le parseur, et de ce fait nous omettons ce comportement pour le moment.

Usage de styles informatiques CSS au lieu de styles par défaut HTML

Plutôt que d'assumer la présentation par défaut pour ces éléments, et utiliser ça pour la base d'une mise en forme en plein-texte, un parseur pourrait utiliser l'équivalent des propriétés respectives équivalentes de style par la machine et les utiliser à la place. Néanmoins, obliger un parseur hCard à implémenter aussi les Feuilles de Styles en Cascade (par ex. CSS1) est hors du champ de la réflexion. Quelques environnements (par ex un navigateur DOM) peuvent déjà fournir cette information et dans ce cas, il peut être facile pour un parseur hCard (par ex. un parseur client javascript) d'utiliser les propriétés informatiques de mise en style. Par ex. au lieu des éléments ci-dessus, les styles suivis par la machine pourraient être utilisés :

  • display:block - fournit un \n doux
    • text-indent (valeur non nulle, sur un élément avec display:block ou display:list-item) - Ajoute un nombre d'espaces équivalent à la valeur de la propriété text-ident divisé par la propriété informatique font-size de l'élément.
    • margin-top, margin-bottom (valeur non nulle, sur un élément avec display:block ou display:list-item) - Ajoute un nombre de "\n" équivalent à la valeur divisé par la propriété font-size de l'élément. Evidemment ceci ne résoudra pas proprement la destruction des marges verticales.
  • display:list-item - Ajoute un \n doux suivi de " * "
  • etc.

Ceci est assez de travail supplémentaire sur lequel je ne suis pas certain que cela vaille la peine de passer du temps et de documenter plus d'équivalents. Les données au-dessus sont suffisantes pour illustrer la possibilité.

Problématiques étonnantes

Problématiques 3

Il pourrait être valable de considérer la définition du parsage en terme de DOM, de façon que cela s'applique au HTML et XHTML également sans ambiguïté.

Problématiques Résolues

Cette section est informative.

Les problématiques suivantes ont été explorées et résolues.

Résolue le 16 septembre 2005

PROBLEMATIQUE 1

Devrions-nous produire les noms de sous-propriété pluriel en versions singulières et simplement permettre plusieurs instances ? par ex. le préfixe singulier honorifique ferait plus de sens s'il était classé tel quel, et la liste implicite par la valeur pour les "honorific-suffix" pourrait être produite de façon plus explicite (et de ce fait plus facilement parsable par une machine) :

<span class="n">
 <span class="honorific-prefix">Mr.</span>
 <span class="given-name">John</span>
 <span class="additional-names">Quinlan</span>
 <span class="family-name">Public</span>,
 <span class="honorific-suffix">Esq.</span>,
 <span class="honorific-suffix">Ph.D.</span>
</span>

RESOLUTION : Adopter des noms de classe singuliers équivalents pour une propriété plurielle et des noms de sous-propriété.


PROBLEMATIQUE 2

Restreindre les valeurs de sous-propriétés "type" à être exprimées en noms de classe semble moins qu'idéal. Cela prend un morceau d'information qui est très souvent visible dans le contenu et le force à être invisible.

Voici un exemple d'un morceau important d'information sur une page web :

http://www.patchlink.com/company/contact.html

Maiilng Address
3370 N. Hayden Road, #123-175
Scottsdale, AZ 85251-6632

Physical Address
8515 E Anderson
Scottsdale, AZ 85255

Notez que le type d'information pour chaque "adr" est explicite dans le contenu. Ce contenu pourrait être balisé comme ceci :

<div class="adr">
<abbr style="display:block" class="type" title="postal,parcel">Adresse Postale</abbr>
<div class="street-address">3370 N. Hayden Road, #123-175</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>
<span class="postal-code">85251-6632</span>
</div>
<div class="adr">
<abbr style="display:block" class="type" title="work,pref">Adresse Physique</abbr>
<div class="street-address">8515 E Anderson</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span> 
<span class="postal-code">85255</span>
</div>

RESOLUTION : Le paramètre "type" DOIT être balisé quand le contenu est disponible (comme dans les deux exemples au-dessus). Nous laissons tomber le modèle de nom de classe type-value-as-another.

En outre, parce qu'il y a quelques problèmes potentiels avec le paramètre "type" pour les propriétés TEL et EMAIL. Parce qu'il n'y a pas de sous-propriétés définies (à la différence du post-code de l'ADR, locality, etc) la valeur-noeud complète de TEL est prise comme la valeur. Par exemple :

<span class="tel">+1.123.456.7890 <abbr class="type" title="work">(work)</abbr></span>

serait représenté dans la vCard comme :

TEL;TYPE=work:+123.456.7890 (work)

Nous introduisons une autre sous-propriété class="value" pour permettre l'extraction d'une valeur d'un élément ou pour une propriété.

<span class="tel"><span class="value">+1.123.456.7890</span> <abbr class="type" title="work">(work)</abbr></span>

Alors les parseurs auraient d'abord besoin de chercher class="value" et de prendre la valeur noeud de cela si elle existe plutôt que than class="tel".

Si un ou plusieurs éléments enfants avec le nom de classe de "value" sont présents dans l'élément pour une propriété, alors concaténez les valeurs noeuds de ces éléments enfants (dans l'ordre trouvé) et utilisez ça comme la valeur de la propriété. Ceci serait avant la valeur noeud de l'élément pour une propriété elle-même.

Références

Références Normatives

Références Informatives

Pages Apparentées

La spécification hCard est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront rajoutés. Ces idées, problématiques et questions sont maintenues sur des pages distinctes.