hcard-issues-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (sync in progress)
m (→‎2008: typo)
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
<h1> Problématiques hCard </h1>
<h1> Problématiques hCard </h1>
 
{{TOC-right}}
Ce sont des problématiques soulevées à propos de [[hcard-fr|hCard]] avec divers degrés de mérite. Par conséquent, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici dans le cas où elles reviendraient à surgir), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des modifications ou des explications améliorées dans la spécification.  
Ce sont des problématiques soulevées à propos de [[hcard-fr|hCard]] avec divers degrés de mérite. Par conséquent, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici dans le cas où elles reviendraient à surgir), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des modifications ou des explications améliorées dans la spécification.  


'''IMPORTANT''' : Lisez svp les [[hcard-faq-fr|hCard FAQ]] ''avant'' de donner quelque réaction ou de soulever quelques problématiques car vos réactions/problématiques peuvent être déjà résolues/répondues.
'''IMPORTANT''' : Lisez svp les [[hcard-faq-fr|hCard FAQ]] et la page [[hcard-issues-fr#problématiques_résolues|hCard problématiques résolues]] ''avant'' de donner quelque réaction ou de soulever quelques problématiques car vos réactions/problématiques peuvent être déjà résolues/répondues.
 
Les problématiques proposées peuvent (et le seront probablement) être éditées et récrites pour une meilleure concision, clarté, rationnalité et une expresson aussi neutre que possible. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]
 
SVP, ajoutez les nouvelles '''problématiques''' en haut de la liste. Relancez svp les problématiques résoules/rejetées avec de l'information fraîche plutôt que de soumettre de nouveau de telles problématiques. Les ajouts de problématiques dupliquées seront retirées.


Voir les [[hcalendar-issues-fr|problématiques hCalendar]] à ce sujet.
Les problématiques proposées peuvent (et le seront probablement) être éditées et récrites pour une meilleure concision, clarté, rationnalité et une expression aussi neutre que possible. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]


Pour toutes les questions en rapport avec la spécification vCard elle même, voir [[vcard-errata-fr|vcard errata]] et [[vcard-suggestions-fr|vcard suggestions]].
Pour toutes les questions en rapport avec la spécification vCard elle même, voir [[vcard-errata-fr|vcard errata]] et [[vcard-suggestions-fr|vcard suggestions]].


Voir aussi les [[hcalendar-issues-fr|problématiques hCalendar]].
Voir aussi les autres [[issues-fr|problématiques]].
 
 


__TOC__


== Problématiques ==
== Problématiques ==
== problématiques fermées ==
Voir [[hcard-issues-resolved-fr|hcard-problématiques-résolues]]
== problématiques résolues ==
Voir [[hcard-issues-resolved-fr|hcard-problématiques-résolues]]


* {{OpenIssue-fr}} 2007-08-03 soulevée par [http://www.kaply.com/weblog/ [User:MikeKaply|MikeKaply]]].
== problématiques ==
*# ''Problématique 1 : When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''
*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".


*{{OpenIssue-fr}} 2007-04-24 soulevée par [[User:Singpolyma|singpolyma]]
<span id="Problématiques">Ajoutez ici les nouvelles problématiques</span> en '''bas''' de la liste en copiant et collant le [[hcard-issues-fr#Gabarit|Gabarit]].  Relancez svp vers les problématiques résolues/rejetées avec de la nouvelle information plutôt que de soumettre à nouveau de telles problématiques. Les ajouts de problématiques doublons seront révoquées.
*# ''A quoi sert la propriété 'Label' ''


*{{OpenIssue-fr}} 2007-04-19 soulevée par [[User:AndyMabbett|Andy Mabbett]]
=== 2006 ===
*#Comment devrions-nous gérer les [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Styles Anciens et Styles Nouveaux de Dates] (par ex. le calendrier Julian vs. Gregorian), dans DoB ? Par exemple, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], né le "10 February [O.S. January 29] 1890". Est-ce que la spec hCard devrait spécifier New Style , en utilisant le  <code>abbr-design-pattern</code> si nécessaire : <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
* {{OpenIssue-fr}} 2006-10-21 soulevée par [[User:AndyMabbett|Andy Mabbett]]
 
*# ''Il devrait y avoir quelque manière de dire que l'URL d'une hCard ou hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même.''
* {{OpenIssue-fr}} 2007-04-09 soulevée [[User:AndyMabbett|Andy Mabbett]]
*#* Très souvent je vois "une" page web accessible avec plusieurs URLs différentes. Typicament 1 URL est l'URL "préféré", attendue pour avoir une longue durée de vie. Parfois d'autres URLs sont des URLs "commodes" qui peuvent avoir été liées dans le passé, mais sont attendues pour s'en aller sous peu, qui pointent vers le même fichier (la "dernière version"). Puis il existe des URLs 'archive" qui présentent une copie exacte de cette page web comme elle est apparue il y a quelque temps dans le passé. Je pense que nous voudrons toujours utiliser l'URL préféré, peu importe laquelle de ces URLs sur lequels nous puissions tomber en premier -- ainsi l'URL n'est en fait pas redondante. (Comment est-ce "dommageable en accessiblité" pour une page de se lier sur elle-même ? Pourriez vous expliquer ou ajouter un lien vers une explication ?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#Pourquoi est-ce [[geo-fr|geo]] est encore un "draft", alors qu'il est inclus dans la spec [[hcard-fr|hCard]] déjà sortie ?
*#**"''Comment est-ce "dommageable en accessiblité" pour une page de se lier sur elle-même ? Pourriez vous expliquer ou ajouter un lien vers une explication ?''" - L'utilisateur novice clique sur un lien ; rien (il semble) n'apparaît. Répété à l'infini, jusqu'à ce que l'utilisateur quitte le site pour faire quelque chose d'autre. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
 
*#*R: ACCEPTEE THEORIQUE. Alors que je tens à être d'accord avec les problématiques/lignes de conduite d'accessibilité notées ici en théorie, pour faire que ce soit un problème du vrai monde de plus grande prioriét, nous avons besoin de documentation d'exemples dans la jungle d'une hcard ou d'un événement hCalendar qui soit l'URL de la page elle-même, de façon que nous puissions utiliser ces exemples pour informer un brainstorming vers une solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
 
*#** Les exemples dans la jungle où l'URL d'une hCard est l'URL de la page elle-même :
 
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html La page Pipettes] sur SXSW 2007 (1 parmi les 1000+ groupes). Il n'y a pas de liens vers la page elle-même sur la page pour marquer avec class="url".  De ce fait ce serait joli d'avoir un moyen pour la hcard des pipettes d'indiquer que la page elle-même est l'URL de la hCard.
* {{OpenIssue-fr}} 2007-03-31 soulevée par [[User:AndyMabbett|Andy Mabbett]]
*#** Exemples dans la jungle où l'URL d'un évènement hCalendarest l'URL de la page elle-même :
*# Le [http://en.wikipedia.org/wiki/World_Geodetic_System schéma WGS84] utilisé comme un défaut par <code>geo</code> ne demeurera pas valide pour toujours. Heureusement l'[[geo-extension-strawman-fr|extension geo]] proposée, initialement destinée pour les coordonnées pour la lune/Mars, fournit aussi une facilité pour la spécification d'autres, d'un schéma lié la terre, ce qui soulagera ce problème. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#*** La page [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] à SXSW 2007 (1 parmi les 1000+ concerts). concerts, oui, même page que la page pour The Pipettes l'org). Il n'y a pas de liens vers la page elle-même sur la page pour marquage avec class="url". De ce fait ce serait joli d'avoir un moyen pour l'événement hCalendar pour The Pipettes at La Zona Rosa d'indiquer que la page elle-même est l'URL pour l'évènement hCalendar.
*#* Remarquez aussi le [http://www.euref-iag.net/ schéma "European Terrestrial Reference System 89"] (Voir aussi  [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 sur Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 avril 2007 (PDT)
*#** Ceci est aussi une [[hreview-issues-fr|hReview problématique]] et de tout autre microformat qui a une propriété "url". Les exemples où l'URL d'un *item* potentiel hReview est l'URL de la page elle-même :
 
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions d'items/produits potentiels en hReview avec des critiques sur leurs pages item).
* {{OpenIssue-fr}} 2007-03-26 soulevée par [[User:AndyMabbett|Andy Mabbett]]
*#Les parseurs (Operator, Tails) attendent actuellement que <code>adr</code> ait un ou plusieurs enfants. Il n'est pas clair de la spec que c'est obligatoire ; ni qu'il soit toujours possible pour un champ address dans un site web (ou CMS) avec gabarit d'être défini avec une telle granularité. Voir [[hcard-brainstorming-fr#ADR sans enfants]] pour la discussion
 
* {{OpenIssue-fr}} 2007-03-19 soulevée par [[User::ChristinaHope|Christina Hope]]
# ''Est-ce que Microsoft Outlook 2003 permet l'utilisation de la propriété "role" ? Je l'ai ajoutée à toutes mes hCards et cela n'apparaît pas. Suis-je en train de faire quelque erreur ?''
*#** URL?
 
* {{OpenIssue-fr}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 soulevée ailleurs] par [[User:JamesCraig]]
*#Note sur l'internationalisation : le <code>country-code</code> peut être manquant. Généralement un préfixe postal-code tel que "FIN-00630 Helsinki" ou "L-4750 Petange" (Luxembourg).
 
* {{OpenIssue-fr}} 2007-02-02 soulevée par [[User::DerrickPallas|Derrick Pallas]]
*# [[adr-fr|adr]] dit que tout de ses propriétés sont singulières, "street-address" est listé comme zéro-ou-plus.
 
* {{OpenIssue-fr}} 2007-01-30 soulevée par  [[User:AndyMabbett|Andy Mabbett]]
*# Beaucoup de sites, au moins Wikipedia, publie les coordonnées sous des degrés-minutes-secondes (par ex. [http://en.wikipedia.org/wiki/Birmingham]). Est-ce que [[geo-fr|geo]] pourrait être étendu pour autoriser ça, avec des parseurs faisant la conversion vers des valeurs digitales ?


=== 2007 ===
* {{OpenIssue-fr}} 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]].  
* {{OpenIssue-fr}} 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]].  
*# les valeurs 'type' RFC2426 ne peuvent pas être localisées/internationalisées dans hCard. Dans l'exemple en-desous, il n'y a pas de solution pour baliser la version Espagnole avec un type de 'home' parce que les valeurs RFC2426 sont définies en anglais. <strong>abbr-design-pattern</strong> suggérerait d'utiliser abbr, mais 'Casa' n'est pas une forme abrégée de 'home', par consquent la version actuellement recommandée (en dessous) n'est pas valide. <pre><nowiki>
*# les valeurs 'type' RFC2426 ne peuvent pas être localisées/internationalisées dans hCard. Dans l'exemple en-desous, il n'y a pas de solution pour baliser la version Espagnole avec un type de 'home' parce que les valeurs RFC2426 sont définies en anglais. <strong>abbr-design-pattern</strong> suggérerait d'utiliser abbr, mais 'Casa' n'est pas une forme abrégée de 'home', par consquent la version actuellement recommandée (en dessous) n'est pas valide. <pre><nowiki>
Line 71: Line 49:
*#*# Laissez SVP la clarification comme telle même si vous sentez que vous devez la REJETER de NOUVEAU (ajoutez, ne reinitialisez pas). Mes points initiaux ont été perdus quand ils ont été retirés du contexte et migrés ici. -[[User::JamesCraig|JamesCraig]]
*#*# Laissez SVP la clarification comme telle même si vous sentez que vous devez la REJETER de NOUVEAU (ajoutez, ne reinitialisez pas). Mes points initiaux ont été perdus quand ils ont été retirés du contexte et migrés ici. -[[User::JamesCraig|JamesCraig]]


*2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]].
* {{OpenIssue-fr}} 2007-03-19 soulevée par [[User::ChristinaHope|Christina Hope]]  
*# ''Proposition d'utiliser l'attribut de classe pour le qname avec des valeurs type préfixe (et d'autres telles que les valeurs dtstard), aussi connues comme des méta-classes.'' <pre><nowiki>
# ''Est-ce que Microsoft Outlook 2003 permet l'utilisation de la propriété "role" ? Je l'ai ajoutée à toutes mes hCards et cela n'apparaît pas. Suis-je en train de faire quelque erreur ?''  
<span xml:lang="en">Home (preferred): <span class="tel type:home type:pref">+1.415.555.1212</span></span>
*#** URL? (si aucune URL vers un exemple démonstratif n'ets fourni dans un an, elle sera fermée comme REJETE INFORMATION INSUFFISANTE.)
<span xml:lang="es">Casa (preferido): <span class="tel type:home type:pref">+1.415.555.1212</span></span>
</nowiki></pre>
*#* REJETEE DUPLICATION ETC. L'attribut de classe pour les valeurs type [http://microformats.org/wiki/hcard-parsing-fr#PROBLEMATIQUE_2 a été essayé et rejeté] et en outre les [[qnames-considered-harmful-fr|qnames sont considérés comme nuisibles]].
*#* Proposition clarifiée, laissée REJETEE.


* {{OpenIssue-fr}} 2007-01-22 soulevée par [[User:Christina Hope|Christina Hope]].
* {{OpenIssue-fr}} 2007-03-31 soulevée par [[User:AndyMabbett|Andy Mabbett]]
*# ''Quel est le meilleur moyen d'afficher une hCard sur une ligne avec un espacement. Actuellement j'utilise ça - mais je sais qu'il doit y avoir un moyen plus simple de faire. <br/>Exemples : (1) <pre><nowiki><p>
*# Le [http://en.wikipedia.org/wiki/World_Geodetic_System schéma WGS84] utilisé par défaut par <code>geo</code> ne demeurera pas valide pour toujours. Heureusement, l'extension proposée [[geo-extension-strawman-fr|geo extension]], initialement destinée pour les coordonnées lunaires/Martiennes, fournit aussi une facilité pour la spécification, qui soulagera ce problème. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
<span class="vcard">
*#* Notez aussi le [http://www.euref-iag.net/ schéma 89 à venir European Terrestrial Reference System ] (Voir aussi [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
<span class="fn">Christina Hope</span>& nbsp;& nbsp;& nbsp;
<span class="department">Information Technology</span>& nbsp;& nbsp;& nbsp;
<span class="role">Website Coordinator</span>& nbsp;& nbsp;& nbsp;
<span display="none" class="region"></span>
<span class="tel"> x3408</span> & nbsp;& nbsp;& nbsp;
<span class="email"><a href="mailto:chope@example.com">chope@example.com</a></span>
</span></p></nowiki></pre>''
 
:: Essayez <pre><nowiki><p class="vcard">
<span class="fn">Christina Hope</span>
<span class="department">Information Technology</span>
<span class="role">Website Coordinator</span>
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</p></nowiki></pre>
 
::Remarque : appliquer des classes aux éléments existants ; utiliser abbr pour donner le numéro de téléphone dans sa totalité au format international. Aussi utiliser CSS, et pas des espaces non brisés pour l'espacement.
 
::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)
 
* {{OpenIssue-fr}} 2006-12-15 soulevée  ([http://microformats.org/discuss/mail/microformats-discuss/2006-December/007730.html le 2006-12-14, sur la liste de discussion]) par Joe Andrieu.
*# (Paraphrasé) En incluant les organisations et les lieux, tout comme les personnes, les hCards ont perdu leur spécificité sémantique (voir billet cité de la liste de discussion pour les détails).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparemment intentionnel], mais exigeant probablement une extension plus poussée. [[User:AndyMabbett|Andy Mabbett]]
 
* 2006-12-15 soulevée par [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Migrée à partir de la page discussion d'un utilisateur] Hé, pourquoi est-ce mal de cacher de l'information semi-utile en utilisant CSS ? Les trucs geo et address ne seraient-ils pas suffisants pour me contacter, mais j'aimerais là aussi que les bookmarklets, crawlers, greasemonkey etc puissent le manipuler. Y'a t'il une politique sur l'utilisation de CSS pour dissimuler des champs ? Merci :)''
*#* Je suppose que nous pouvons pas faire confiance sur le fait que tout ce qui consomme des hCards soit normalisé à un format particulier au lieu de prendre tout le xml à l'intérieur des blocs classés de la hCard et des les coller quelque part. Si cela ne fait que les stocker comme une chaîne, alors générer du html à partir de là aboutira aux même champs cachés. Peut-être que cacher les champs en appliquant une feuille de style aux styles pertinents pour la hCard est bien, mais pas les dissimuler en utilisant un style en ligne CSS. Réaction ? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* En outre, [[hcard-example1-steps-fr#hCard_Exemple_1_:_les_Etapes|hcard-exemple1-les étapes]] affiche l'utilisation de CSS en ligne pour cacher les champs. Ce que ça donne ? Je pense encore que c'est une problématique ouverte ; tout particulièrement la distinction entre une feuille de style externe les achant et des règles dans la ligne. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Ce devrait être sur [[microformats-issues-fr|microformats-problématiques]] ? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** L'exemple que vous citez est le premier de plusieurs étapes, qui raffinent et améliorent la première étape de hCard sous-optimale.
*#*** La question est : ''pourquoi est-ce considéré sous-optimal si c'est bien de cacher la carte complète ?'''
*#**** REJETEE FERMEE TROP THEORIQUE. Ce n'est pas bien de cacher la totalité de la carte. Sans exemples plus concrets provenant d'URLs du vrai monde sur le web, cette problématique est close.
*#***** Il existe un bon nombre d'exemples qui dissimulent la totalité de la hCard, extraits à partir de [[hcard-examples-in-wild-fr|hCard exemples dans la jungle]] : [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1]  -- Est-ce que quelqu'un pourrait lier vers un endroit où cela a été discuté et décidé dans le passé, car il me semble que ceci est en train d'être gouverné par autorisation. Même si vous ne vous souciez pas d'avoir un consensus, mais pourriez-vous au moins justifier ça ? Ce mur de pierres est plutôt rude. -- [[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming-fr#Styles_CSS]] permet cela explicitement. Je vais avancer avec ce qu'ils disent.
 
 
* {{OpenIssue-fr}} 2006-12-07 soulevée par RyanKing.
*# ''l'org-fn de la hCard correspondant devrait utiliser organization-name, s'il est donné.''
*# soulevée [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html initialement sur uf-discuss] par David Janes.
 
* {{OpenIssue-fr}} 2006-11-24 soulevée [[User:AndyMabbett|Andy Mabbett]]
*# ''Un contournement suggéré pour le manque d'une propriété sexe est de représenter implicitement le sexe dans le champ 'honorific-prefix' par ex. Mr. pour un Homme, et Ms. pour une femme. Cette approche a vraiment la limite que "Mr." et "Ms." (ou "Miss"/ "Mrs.") entre en conflit avec un classement de plus haut niveau, honorifique et libre de sexe, comme "Dr." ou "Rév." pour la personne, car il est peu habituel (et parfois invalide hors des Etats-Unis) de faire référence par exemple à quelqu'un comme "Mr. Dr." ou "Mrs. Rev.". Remarquez aussi que quelques cultures ou religions considèrent de tels titres comme insultants, ou au moins les dédaigent.''
 
* {{OpenIssue-fr}} 2006-11-23 soulevée par [[User:AndyMabbett|Andy Mabbett]]
*# ''La spécification devrait être "stand alone" et ne pas obliger normalement à exiger une réfrence à la spécification vCard.''
*#*R : ACCEPTEE PARTIELLEMENT.  D'accord sur le fait que [[hcard-fr|hCard]] devrait être utilisable par les auteurs web sans avoir à plonger dans la spécification vCard. Précisez l'impélenation du parsage, etc. Les propriétés de hCard obligeront nénamoins les programmeurs à faire référence aux spécificités/grammaires de la spécification vCard qui ne repliquera PAS dans la spécification hCard afin d'éviter l'introduction inévitable d'erreurs dues à la duplication. Et ceci étant dit, les explications ''informatives'' peuvent être une bonne idée, tant que les définitions de valeur/propriété de la vCard sont maintenues comme ''normatives''.
*#** ''Oui ; mon inteprétation faisait référence à la publication de hCard, pas de parser l'intérieur des vCards. [[User:AndyMabbett|Andy Mabbett]]''
*# ''La spécification devrait déclarer que les "numéros de téléphone DEVRAIENT adhérer à la [http://en.wikipedia.org/wiki/E.123 ITU-T Recommandation E.123]" (ou peut être "DOIVENT").''
*#* ACCEPTE PARTIELLEMENT. Ceci a du sens comme référence informative et un PEUT, mais parce que la vCard ne fait pas de telle déclaration DEVRAIT pour les valeurs TEL, la hCard ne devrait pas le faire ni ne le fera. En outre, parce que l'URL de Wikipedia est sujette à un changement drastique, nous ne pouvons pas produire ça comme une référence normative.
*#** ''Je prends ton point sur Wikipedia - voici  [http://www.itu.int/rec/T-REC-E.123-200102-I/en une url ITU-E.123 plus définitive] ; mais c'est pour un document chargeable. Utiliser "DEVRAIT" ou "DOIT" dans la hCard n'affectera la compatiblité ou la conversion vers vCard. [[User:AndyMabbett|Andy Mabbett]]''
 
* 2006-11-16 soulevée par [[User:AndyMabbett|Andy Mabbett]]
*# ''Le "type" pour "tel" manque d'une option "textphone" (pour les terminaux utilisés par exemple par les personnes qui sont sourdes sourdes ou ont des difficultés d'expression. Par exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*R : REJETE. Ceci est une problématique vCard, car la taxonomie "type" pour "tel" est déterminée par vCard. Nous n'augmentons pas actuellement la hCard au delà des propriétés et valeurs dans la vCard.
*#** ''Ce n'est pas clair comment vous pouvez "rejeter" une déclaration factuelle prouvée. Quel est le processus pour suggérer une mise à jour vers vCard ? [[User:AndyMabbett|Andy Mabbett]]''
*#***R : ACCEPTEE PARTIELLEMENT RESOLUE. Malheureusement il n'est pas clair quel est le processus pour mettre à jour vCard. Néanmoins, nous pouvons au moins saisir les suggestions pour améliorer vers vCard à partir de cette communauté, ce qui peut être utile une fois que le processus pour mette à jour la vCard sera compris. J'ai créé [[vcard-suggestions-fr|vcard-suggestions]] à cet effet et ajouté cette suggestion. - Tantek
*#**** La spéc. vCard est mise à jour par RFC, par exemple [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)
 
* {{OpenIssue-fr}} 2006-10-21 soulevée par [[User:AndyMabbett|Andy Mabbett]]
*# ''Il devrait y avoir quelque moyen de dire que l'URL d'une hCard ou d'un événement hCalendar est l'URL de la page elle-même sans avoir à inclure un lien redondant et dommageable en accessibilité sur la page elle-même.''
*#* Très souvent je vois "une" page web accessible avec plusieurs URLs différentes. Généralement 1 URL est l'URL "préféré", attendue pour avoir une longue durée de vie. Parfois d'autres URLs sont des URLs "pratiques" qui peuvent avoir été liés dans le passé, mais sont attendues pour disparaître bientôt, qui pointent vers le même fichier (la "dernière version"). Ensuite il existe les URLs "archive" qui affichent une copie exacte de cette page web comme elle apparaissait dans le temps. Je pense que nous voulons toujours utiliser l'URL préférée, peu importe sur laquelle de ces URLs nous tombons en premier -- par conséquent l'URL qui n'est en fait pas redondante. (Comment exactement est 'il "accessibility-damaging" pour une page de faire un lien vers elle-même ? Pourriez-vous expliquer ou ajouter un lien vers une explication ?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTE THEORIQUE. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues-fr|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).
 
* 2005-06-21 soulevée par Hixie
*# ''Problématique H-1 : Cette spécification manque d'une section de conformité d'agent utilisateur. Il n'y a rien basiquement qui dise comment devraient être parsés les hCards, comment gérer les erreurs, et ainsi de suite. Est-ce défini dans les termes du DOM ? Est-ce défini dans les termes d'une sérialisation ? Comment gérez vous le contenu inattendu ou le contenu manquant ?
*#*R : ACCEPTEE RESOLUE.  Voir [[hcard-parsing-fr|parsage hCard]] pour la façon dont les hCards doivent être parsées. Pour le contenu erreurs/contenu inattendu/contenu manquant, fournissez svp  des exemples spécifiques.
 
* 2005-06-30 soulevée par Jack L. Wolfgang II. SVP sentez-vous libre de migrer cela vers les FAQs si cela colle mieux là-bas.
*# ''Gérer les noms du milieu et les suffixes : comment gérer les noms/initiales au milieu dans le format hCard et les suffixes qui ne sont pas honorifiques (par ex Jr., Sr., II, III, etc. à l'inverse de Ph.D., Esq., M.D., etc.) ?''
*#*R : ACCEPTEE en FAQ. par [http://suda.co.uk Brian Suda] (2005-11-08 mise à jour par [http://tantek.com/log/ Tantek]) la hCard est basée sur la spec RFC2426. Si vous voulez utiliser une initiale de milieu, elle peut être épanchée en utilisant l'élément abbr. <code>&lt;abbr title="Middle Name" class="additional-name"&gt;M&lt;/abbr&gt;</code>. Les suffixes honorifiques dans la RFC comprennent Jr. Esq. et d'autres suffixes hérités, ainsi j'utiliserais juste <code>&lt;span  class="honorific-suffix"&gt;Jr.&lt;/span&gt;</code> etc.
*# ''Gérer différents types d'adresses : comment on gère la spécification TYPE (par ex. postale, travail, etc.) pour des adresses comme spécifiée dans la RFC 2426 Section 3.2.1 ?''
*#*R : ACCEPTEE FAQ. par [http://suda.co.uk Brian Suda] (2005-11-08 mis à jour par [http://tantek.com/log/ Tantek]) Si vous voulez ajouter un type à certains éléments, y compris l'adresse et le téléphone, ce peut être fait de la façon suivante :
<pre><nowiki>
&lt;span class="adr"&gt;
&lt;span class="type"&gt;work&lt;/span&gt;:
...
&lt;/span&gt;
</nowiki></pre>
<pre><nowiki>
&lt;span class="tel"&gt;
&lt;span class="type"&gt;work&lt;/span&gt;:
&lt;span class="value"&gt;123.456.7890&lt;/span&gt;
&lt;/span&gt;
</nowiki></pre>
le TYPE a besoin d'être un sous-élément de la propriété (adr, tel, etc) NOTE : EMAIL n'a PAS beaucoup d'attributs TYPE, seulement INTERNET et X400
 
* {{OpenIssue-fr}} 2006-04-10 soulevée par [[User:ScottReynen|Scott Reynen]].
*# ''Quand quelqu'un cherche les pages [[hcard-fr|hCard]] on ne voit pas d'ensemble de publication du vrai monde de données de contact ni de discussion des propriétés sous-tendues par de tels exemples, je pense que c'est loin d'être très facile d'inférer que les microformats proviennent d'autres formats plus que du comportement véritable. Il n'y a rien sur le [[process-fr|processus]] ni sur les pages hCards qui explique ce désaccord. Je soutiendrais qu'il devrait y avoir une explication, probablement dans les deux endroits.
 
* 2006-04-06 soulevée par [[User:Evan|Evan]].
*# ''Quelle est la relation entre la propriété CATEGORY et [[rel-tag|rel-tag-fr]] ? Pouvez-vous ajouter un tag à une hCard ? Comment pouvez-vous ajouter un tag à une hCard particulière sur une page sans taguer les autres cartes sur une page ?''
*#* ACCEPTEE. Les catégories peuvent optionnellement être représentées comme des tags. Le nom de classe 'category' devrait toujours être utilisé, mais rel="tag" peut optionnellement être utilisé (en addition au nom de classe category). Dans le cas où un tag rel-tag est utilisé, le tag (tel que défini par [[rel-tag|rel-tag-fr]]) est utilisé pour la catégorie. Exemples : (1) <code><nowiki><span class="category">cuisine</span></nowiki></code> et (2) <code><nowiki><a class="category" rel="tag" href="http://exemple.com/cuisine">Cuisine !</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)
 
* {{OpenIssue-fr}} 2006-03-07 soulevée par [http://tantek.com Tantek].
*# ''Problématique 1 : Dans 99% des cas je trouve le besoin de produire explicitement un balisage "n", la personne a un troisième mot fn qui est sous la forme "prénom nom-additionnel (ou initiale) nom-de-famille". Devrions-nous produire trois mots de fn à l'intérieur d'une notation raccourci pour que ce soit plus facile pour les auteurs ?''
 
* 2006-02-23 soulevée par [http://www.thefutureoftheweb.com/ Jesse Skinner] et [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Est-ce que plusieurs URLs sont permises ? La [http://microformats.org/wiki/hcard-fr#Liste_de_propriétés Liste de Propriétés] suggère que non, alors que l'email et le tel ont plusieurs paires de type/value. Néanmoins, la [[hcard-parsing-fr#trouver_des_propriétés_hCard page de parsage]] suggère que plusieurs URLs sont OK. D'une façon ou d'une autre, il semble clair qu'un type ne peut pas être associé à un URL. Aussi comment hCard traite véritablement avec plusieurs URLs ?''
*#* RESOLU FAQ : Plusieurs URLs sont permises. Quelques agents insatiables (l'application AddressBook d'Apple en faisant partie) n'a pas d'interface pour produire plusieurs URLs, mais elles sont encore valides dans vCard et par conséquent dans hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)
 
* 2006-02-19 soulevée par Miika Mäkinen.
*# ''Est-ce que les types pour les numéros de tel pourraient être spécifiés dans une classe ? Maintenant pour un numéro de téléphone on a besoin d'ajouer le type comme du texte "visible", un type qui n'est pas toujours préféré. Par exemple, le type "Work", bien des fois une étiquette plus adaptée pourrait être "Office" ou équivalent et parfois vous pourriez ne pas vouloir afficher aucun type d'information.''
*#* REJETEE DEJA ESSAYEE. Utiliser les noms de classe pour le "type" d'un tel ou d'une adr [[hcard-parsing-fr#PROBLEMATIQUE_2|a été essayé]], et a échoué dans beaucoup de situations. En outre l'information "type" est une véritable donnée, pas juste un nom de propriété et de ce fait mérite d'être dans le balisage ''visible''. Notez que vous pouvez utiliser les abréviations, par exemple <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> afin de présenter le type d'une manière qui puisse mieux coller avec le reste de votre présentation.
 
* 2006-02-13 soulevée par [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Peu de systèmes prennent en considération la composante altitude d'une coordonnée, alors qu'elle existe. L'altitude devient importante quand on travaille avec des logiciels de cartographie 3D tels que Google Earth. Bien sûr, le service de géocodage que Google Earht utilise renvoie une coordonnée tridimensionnelle. Je suggère que hCard fournisse un support explicite pour l'altitude.''
*#* REJETEE REPOUSSEE. Pas dans la vCard. Il n'existe pas de composant "altitude" dans la vCard (RFC 2426), et par conséquent (certainement à cette heure), il n'y en aura pas dans hCard. Si une nouvelle version de vCard venait à sortir avec l'altitude, alors nous l'ajouterions à hCard. A un certain stade, nous pouvons aussi imaginer ajouter des extensions explicites allant au delà de la vCard, mais si nous faisions ainsi, nous les saisirions d'abord sur la page [[hcard-brainstorming-fr|hCard-brainstorming]].
 
*2006-02-03 soulevée par Brian
*# Nous pouvons utiliser le microformat [[geo-fr|geo]] dans [[hatom-fr|htatom]] pour représenter l'élément GeoRSS
 
* {{OpenIssue-fr}} 2006-01-28 soulevée par [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek sur #microformats]
*# ''Est-ce que hCard est vraiment appropriée pour un pontage téléphonique nommé, ou avons-nous besoin de quelque chose d'autre pour un numéro de téléphone nommé qui n'est ni celui d'une personne ni celui d'organisations (les deux sémantiques actuelles précisent que ce peut être défini par hCard). Par exemple voir la hCard de "Zakim sur http://www.w3.org/2005/12/allgroupoverview.html''
 
* 2006-01-21 soulevée par [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Rencontré quelques problématiques à essayer d'utiliser les définitions de listes avec hCard, spécifiquement autour des obligations d'imbriquer le téléphone là où l'élément DT prend une classe "type" (par ex Telephone, Facsimile) et l'élément DD balise la valeur. C'est invalide de placer tout autre élément dans un DL qui emballe les paires DT/DD aussi il n'y a pas d'élément disponible à assigner à la classe "tel". XHTML2 propose un élément DI qui résoudra ce problème. J'espère une solution temporaire pour ceux qui souhaitent utiliser des listes de définition, peut-être "n'importe quelle classe qui serait placée sur le parent DI (en XHTML2) doit à la plcae être placée sur le premier élément DT". Je réalise que cela provoquera des maux de crâne pour ceux qui implémenteront les parseurs hCard. J'aimerais aussi faire remarquer que cela peut affecter d'autres (actuels ou futurs) microformats et que cela a quelque chose à voir avec le tracas général des listes de définition dans les recommandations courantes (X)HTML. Pour votre considération. Merci !''
*#* REJETEE CONTOURNEMENT DISPONIBLE. Soit n'utilisez pas de listes de définition de cette manière (parce que la description irait complètement dans l'élément DD, et de ce fait vous devriez pouvoir mettre la classe sur ça), ou utilisez des DLs séparées dans les cas où vous auriez autrement besoin d'un élément DI.
 
* 2005-12-08 soulevée par [http://www.heatonarts.com Kenny Heaton].
*# ''La spécification ne donne aucun moyen de déclarer une extension téléphonique, comme dans (800) 234-5678 ext. 101''
*#* ACCEPTEE FAQ. Quel est le meilleur moyen de déclarer une extension téléphonique dans une propriété "tel" ? (semble aussi être une FAQ vCard).
 
* 2005-10-30 soulevée par [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Plusieurs implémentations'' '''(Lesquelles ? Fournissez des liens SVP.)''' ''semble supposer que tout attribut de classe qui contienne la sous-chaîne "vcard" signale en fait la présence d'information vCard. Pas ainsi : il y a des exemples'' '''(Quels exemples ? Fournissez des liens SVP.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored.  Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJETEE VAGUE. Quelles implémentations ? Et quels exemples?
*#*''(Note : le code <code>contains(concat(@class,' '),'vcard ')</code> est brisé voir [[parsing-microformats-fr#Parser_les_valeurs_de_classe|parser les valeurs de classes]] pour un exemple correct --[[User:RobertBachmann|Robert Bachmann]])''
 
* 2005-08-12 soulevée par [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. L'utilisation de la fonctionnalité de transport mailto pour le champ adresse email.
*# ''Comme cela a été déclaré dans le document [[hcard-brainstorming-fr|hcard-brainstorming]], mailto se fait abuser par les spammeurs. En conséquence, bon nombre d'organisations ont migré vers des formulaires de contacts basés sur le web à l'opposé des mailto. Selon la  [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "Une valeur non-standard peut être aussi spécifiée." Cela fait-il référence à une valeur d'adresse e-mail ou une valeur type ?''
*#* R : ACCEPTEE FAQ. Valeur Type.
 
* 2005-07-23 soulevée par DanConnolly
*# ''Est-ce que les noms de classes sont sensibles à la casse ou non ? [[hcard-fr|hCard]] dit "Si les noms dans le schéma source sont non sensibles à la casse, alors utilisez un équivalent tout en bas de casse."''
*#* R : ACCEPTEE FAQ. Les noms de classes sont sensibles à la casse selon la spécification HTML4. De ce fait hCard spécifie explicitement le cas d'un nom de classe à utiliser pour des noms de schéma source qui sont non sensibles à la casse.
*# ''... mais je trouve des exemples de données avec class="Given-Name"''
*#* R : ACCEPTEE RESOLUE. Ceci date d'une version plus ancienne et préliminaire de la spec hCard qui utilisait des noms de classes avec des casses mélangées. De tels noms de classes ne sont plus valides. SVP notez les exemples (URLs) qui utilisent les noms de classes plus anciens et qui je l'espère nous pourrons réparer.
*#** R : Par [http://suda.co.uk Brian Suda] j'ai réparé toutes les références dans la page [[hcard-brainstorming-fr|hcard-brainstorming]] pour renvoyer le style en plus bas de casse, ceci est un report du design original, X2V a été mis à jour.
*# ''..et le code qui le supporte [données avec class="Given-Name"].''
*#* R : ACCEPTEE RESOLUE. Tout code supportant le plus anciens noms de classe est en rétrocompatibilité seulement et devrait être abandonnée graduellement. Tout nouveau code hCard NE DEVRAIT PAS supporter de tels noms de classes avec des casses mélangées.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] utilise  Street-Address, Family-Name, etc.
*#*** R : Par [http://greenbytes.de/tech/webdav/ Julian Reschke] Réparé rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supporte Family-Name etc.
*#*** R : Par [http://suda.co.uk Brian Suda] je suis d'accord que les noms de classe avec des lettres capitales peuvent être retirés du code, ceci est un report et sera raccourci.
*# ''Le truc ul/ol pour plusieurs valeurs de propriété semble être dans le code X2V et dans le [[hcard-brainstorming-fr|hcard-brainstorming]] mais pas dans la spec [[hcard-fr|hCard]].''
*#* R. ACCEPTEE RESOLUE. Ceci a besoin d'être ajouté à la spec. 2005-11-08 Mise à jour : la façon dont plusieurs valeurs ont été mises à jour fonctionne bien mieux et n'a pas besoin de ul/ol.
*# ''le [[hcard-profile-fr|profil hCard]] dit 'country-name' mais X2V et beaucoup de données que j'ai vues disent country''
*#* A. ACCEPTE RESOLUE. RFC 2426 dit clairement "country-name" à la fois dans la prose et la grammaire, de ce fait "country-name" est le nom de classe correct à utiliser. Si X2V utilise juste "country", cela a besoin d'être réparé pour utiliser "country-name", et tout aussi bien de tels exemples. Notez svp quels exemples (URLs) utilisent le nom de classe "country" et nous le réparerons (je l'espère).
*#** R : Par [http://suda.co.uk Brian Suda] j'ai réparé toutes les références dans la page [[hcard-brainstorming-fr|hcard-brainstorming]] pour refléter le country-name correct, X2V supportera cela dans la prochaine itération quand je réparerai plusieurs bugs en une seule fois.
 
* 2005-07-22 soulevée par DanConnolly
*# ''... dans mon carnet d'adresses de téléphonemobile/sidekick, j'ai un certain nombre d'entrées pour les sociétés. J'ai écrit [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] pour convertir les données à partir de RDF vers hCard, mais ne sais pas quoi faire avec les entrées pour les sociétés, parce que FN est obligatoire dans hCard.''
*#*R : ACCEPTEE FAQ. Ceci devrait être une FAQ.  "Comment j'écris une hCard pour une société ?"  La spécification vCard est silencieuse sur ce point (entrées pour les sociétés). De ce fait il y a deux options dans la limite où le standard hCard est concerné !
*#*# Régler "fn" et "org" à la même valeur.  par ex. <code>&lt;span class="fn org"&gt;W3C&lt;/span&gt;</code> (recommandée)
*#*# Régler "org" comme d'habitude, et régler "fn" explicitement à vide. par ex. <code>&lt;span class="fn"&gt;&lt;/span&gt;&lt;span class="org"&gt;W3C&lt;/span&gt;</code> ou
*#*#* Simplement ne pas avoir de "fn", et du côté parsage, s'il n'y a pas de "fn" présent, mais qu'il y ait une propriété "org", alors dupliquer la valeur "org" sous "fn"
*#*Les deux dernières options sont en fait les mêmes et sont toutes deux non explicites et facilement déroutantes avec une condition de "donnée manquante". De ce fait l'option 1 est préférée. Pour les applications de convertisseur (hCard vers vCard), elles ''peuvent'' considérer utiliser des extensions propriétaires pour produire la distinction explicite dans les vCards générées, basées sur soit le cas 1 ou 2 au-dessus. Par exemple, l'application Carnet d'Adresses d'Apple supporte la propriété : <code>X-ABShowAs:COMPANY</code>
*#*Nous cherchons des descriptions sur la façon dont d'autres applications supportant vCard traitent les vCards de "société" différemment des vCards de "personnes". Fournissez svp des applications ici :
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.


*{{OpenIssue-fr}} 2007-04-19 soulevée par [[User:AndyMabbett|Andy Mabbett]]
*#Comment devrions-nous gérer les [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Styles Anciens et Styles Nouveaux de Dates] (par ex. le calendrier Julian vs. Gregorian), dans DoB ? Par exemple, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], né le "10 February [O.S. January 29] 1890". Est-ce que la spec hCard devrait spécifier New Style , en utilisant le  <code>abbr-design-pattern</code> si nécessaire : <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?


=== hCard Canonique Faisant Autorité ===
===2008===


* {{OpenIssue-fr}} 2006-01-23 soulevée par David Janes (?).
*{{OpenIssue-fr}} <span id="tel-type-lang">2008-01-09 migrée à partir de vcard-suggestions</span>
* ''Problématique 1 : Spécifier la hCard Faisant Autorité ou Canonique ou Officielle''
*#Nous ne pouvons spas avoir un nom de type générique du fait que nous devons le localiser en français. Aussi pour nous, le numéro de téléphone professionnel est : <nowiki><div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div></nowiki>. Comment fera un robot pour reconnaître ce type ? Nous ne pouvons pas spécifier tous les types dans chaque langue dans la spécification. C'est pourquoi je pense que quelque chose comme ça serait mieux : <nowiki>Travail : <span class="telwork">0321596224</span></nowiki> SVP, n'utilisez des attributs de classe et id UNIQUEMENT pour les spécifications microformats ! les #cdata et #data XML sont localisés ! Merci !
** L'utilisation de rel="me" ne spécifie seulement qu'une version alternative, pas nécessairement la version canonique
** Suggestion : utilisation de rel="me self". Adopte la sémantique "self" provenant d'Atom qui veut dire "the", ou la version controversée "alternate, equivalent"
*** L'usage combiné de rel="me" et rel="self" peut entrer en conflit avec ses définitions dans respectivement le [http://www.gmpg.org/xfn/11#me profil XFN] et la RFC 4287. Voir  [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html la discussion sur la liste à propos de rel="me self"] pour plus d'information. [[User:RCanine|Ryan Cannon]].
** Suggestion : utiliser rel="via". Selon la RFC 4287, via "signifies que l'IRI dans la valeur de l'attribut href identifie une ressource qui est la source d'information fournie dans l'élément conteneur."  [[User:RCanine|Ryan Cannon]].
** Autres suggestions ?  "authoritative", "canonical"?
** Problèmes avec cette suggestion ?
** Comment cela s'apparente aux problématique d'authentication/confiance ? Est-ce un problème différent avec un champ différent ?
*** (microformats-discuss list) Joe Andrieu : Le concept derrière une hCard "faisant autorité" plutôt que "définitive" ou "canonique" était que "faisant autorité" serait explicitement une revendication par l'auteur de la hCard eu égard à son autorité pour décrire le sujet de la hCard, par ex utilisez ''cette'' hCard comme l'unique vraie source de l'information de contact de cet individu.
*** Pour résumer : l'authentification/confiance est un sujet séparé.
** Qu'est-ce qui est exactement le champ du problème à résoudre ici ?
*** (IRC) (10:47:44) sreynen : par ex, tous les exemples que j'ai vus incluent une personne unique publiant plusieurs hCards pour elles-mêmes.
*** (IRC) (10:48:13) sreynen : à cettte heure beaucoup de personnes parlent de parties tiers publiant des hCards et pointant vers la propre hCard du sujet
** rel="me" doit être symétrique, selon la spec XFN. Qu'est-ce que cela veut dire exactement pour cet usage ?
** "me" (et selon l'usage "self") ne sont pas appropriés pour le contenu faisant référence à des parties tiers. [[User:AndyMabbett|Andy Mabbett]]
''TODO :'' ajoutez svp le contexte et l'historique appropriés de cette problématique à partir de la liste de discussion. Signez vos commentaires.


== Gabarit ==
== Gabarit ==
 
{{issues-format-fr}}
SVP utilisez ce format (copiez et collez ceci à la fin de la liste) pour rajouter vos problématiques :
* {{OpenIssue-fr}} AAAA-MM-JJ soulevée par [http://votrepage.exemple.com VotreNom].
*# ''Problématique 1 : Voilà la première problématique que j'ai.''
*# ''Problématique 2 : Voilà la seconde problématique que j'ai.''
 
 
Note : les grands blocs de texte en italique sont inaccessibles pour bon nombre de lecteurs, y compris les personnes ayant des déficiences visuelles, de la dyslexie, etc. [http://www.intranet.man.ac.uk/accessibility/Disabilities/dyslexia.html], [https://tritonlink.ucsd.edu/portal/site/tritonlink-preview/menuitem.b4448692267a11256ec5e210514b01ca?storyID=20896]. [http://accessites.org/], [http://tlt.psu.edu/suggestions/accessibility/font.html], [http://www.wd4a.co.uk/Guidelines.htm]
 
== Problématiques résolues ==
Issues that are resolved but may have outstanding [[to-do]] items.
 
* 2007-03-28 soulevée par [[User:JamesCraig|James Craig]]
*#Problématique d'[[internationalization-fr|Internationalisation]] (i18n) pour l'optimisation implicite de FN. Beaucoup de langues (par exemple le japonais) listent souvent FN comme sous "family-name given-name" au lieu du "given-name family-name" en anglais et d'autres langues occidentales. Il devrait y avoir une affordance pour indiquer l'ordre ''ou'' une note dans la spec indiquant que le FN en daux mots est un raccourci pour les langues occidentales et toute langue ne correspondant pas à ce format devrait définir explicitement à chaque fois le "family-name" et "given-name".
*#* ACCEPTEE. Tantek [[to-do]] : ajouter section internationalisation dans la spec [[hcard|hCard]], et une note dans la spec indiquant que le FN en deux mots est un raccourci pur les langues occidentales et que toute langue ne correspondant pas à ce format devrait explicitement définir à chaque fois "family-name" et "given-name".
 
== Problématiques Fermées ==
Les problématiques résolues qui n'ont plus d'actions à prendre.
 
* ...
 


== Pages Apparentées ==
== Pages Apparentées ==
{{hcard-related-pages-fr}}
{{hcard-related-pages-fr}}

Latest revision as of 14:30, 3 February 2008

Problématiques hCard

Ce sont des problématiques soulevées à propos de hCard avec divers degrés de mérite. Par conséquent, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici dans le cas où elles reviendraient à surgir), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des modifications ou des explications améliorées dans la spécification.

IMPORTANT : Lisez svp les hCard FAQ et la page hCard problématiques résolues avant de donner quelque réaction ou de soulever quelques problématiques car vos réactions/problématiques peuvent être déjà résolues/répondues.

Les problématiques proposées peuvent (et le seront probablement) être éditées et récrites pour une meilleure concision, clarté, rationnalité et une expression aussi neutre que possible. Ecrivez bien vos problématiques. — Tantek

Pour toutes les questions en rapport avec la spécification vCard elle même, voir vcard errata et vcard suggestions.

Voir aussi les autres problématiques.


Problématiques

problématiques fermées

Voir hcard-problématiques-résolues

problématiques résolues

Voir hcard-problématiques-résolues

problématiques

Ajoutez ici les nouvelles problématiques en bas de la liste en copiant et collant le Gabarit. Relancez svp vers les problématiques résolues/rejetées avec de la nouvelle information plutôt que de soumettre à nouveau de telles problématiques. Les ajouts de problématiques doublons seront révoquées.

2006

  • problématique ouverte ! 2006-10-21 soulevée par Andy Mabbett
    1. Il devrait y avoir quelque manière de dire que l'URL d'une hCard ou hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même.
      • Très souvent je vois "une" page web accessible avec plusieurs URLs différentes. Typicament 1 URL est l'URL "préféré", attendue pour avoir une longue durée de vie. Parfois d'autres URLs sont des URLs "commodes" qui peuvent avoir été liées dans le passé, mais sont attendues pour s'en aller sous peu, qui pointent vers le même fichier (la "dernière version"). Puis il existe des URLs 'archive" qui présentent une copie exacte de cette page web comme elle est apparue il y a quelque temps dans le passé. Je pense que nous voudrons toujours utiliser l'URL préféré, peu importe laquelle de ces URLs sur lequels nous puissions tomber en premier -- ainsi l'URL n'est en fait pas redondante. (Comment est-ce "dommageable en accessiblité" pour une page de se lier sur elle-même ? Pourriez vous expliquer ou ajouter un lien vers une explication ?) --DavidCary 17:44, 5 Apr 2007 (PDT)
        • "Comment est-ce "dommageable en accessiblité" pour une page de se lier sur elle-même ? Pourriez vous expliquer ou ajouter un lien vers une explication ?" - L'utilisateur novice clique sur un lien ; rien (il semble) n'apparaît. Répété à l'infini, jusqu'à ce que l'utilisateur quitte le site pour faire quelque chose d'autre. Andy Mabbett 02:43, 6 Apr 2007 (PDT)
      • R: ACCEPTEE THEORIQUE. Alors que je tens à être d'accord avec les problématiques/lignes de conduite d'accessibilité notées ici en théorie, pour faire que ce soit un problème du vrai monde de plus grande prioriét, nous avons besoin de documentation d'exemples dans la jungle d'une hcard ou d'un événement hCalendar qui soit l'URL de la page elle-même, de façon que nous puissions utiliser ces exemples pour informer un brainstorming vers une solution. Tantek 15:11, 10 Apr 2007 (PDT)
        • Les exemples dans la jungle où l'URL d'une hCard est l'URL de la page elle-même :
          • La page Pipettes sur SXSW 2007 (1 parmi les 1000+ groupes). Il n'y a pas de liens vers la page elle-même sur la page pour marquer avec class="url". De ce fait ce serait joli d'avoir un moyen pour la hcard des pipettes d'indiquer que la page elle-même est l'URL de la hCard.
        • Exemples dans la jungle où l'URL d'un évènement hCalendarest l'URL de la page elle-même :
          • La page The Pipettes at La Zona Rosa à SXSW 2007 (1 parmi les 1000+ concerts). concerts, oui, même page que la page pour The Pipettes l'org). Il n'y a pas de liens vers la page elle-même sur la page pour marquage avec class="url". De ce fait ce serait joli d'avoir un moyen pour l'événement hCalendar pour The Pipettes at La Zona Rosa d'indiquer que la page elle-même est l'URL pour l'évènement hCalendar.
        • Ceci est aussi une hReview problématique et de tout autre microformat qui a une propriété "url". Les exemples où l'URL d'un *item* potentiel hReview est l'URL de la page elle-même :

2007

  • problématique ouverte ! 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]].
    1. les valeurs 'type' RFC2426 ne peuvent pas être localisées/internationalisées dans hCard. Dans l'exemple en-desous, il n'y a pas de solution pour baliser la version Espagnole avec un type de 'home' parce que les valeurs RFC2426 sont définies en anglais. abbr-design-pattern suggérerait d'utiliser abbr, mais 'Casa' n'est pas une forme abrégée de 'home', par consquent la version actuellement recommandée (en dessous) n'est pas valide. 


<span class="tel" xml:lang="en">



 <span class="type">Home</span> (<span class="type">pref</span>erred):
 <span class="value">+1.415.555.1212</span>



</span>




      • REJETEE. TROP PEU D'INFORMATION.  Fournissez svp l'URL précise vers la déclaration spécifique sur le forum de discussion accessify qui déclare qu'utiliser abbr n'est pas valide. Fournissez aussi une URL précise vers un exemple du *vrai *monde* dans la jungle (à l'inverse d'un cas de test artificiellement construit) d'une hCard non anglaise qui tente de spécifier l'information type RFC2426 sur une propriété "tel" et échoue à faire ainsi.
        • 

      • ROUVERTE ET CLARIFIEE (retiré aussi la référence Accessify extraite de [la mention originale]).

        1. Bien que cela ait d'abord émergé sur la page accessibilité, ce n'est pas une problématique d'accessibilité. C'est une problématique de sémantique HTML pour l'internationalisation. abbr[title] devrait être une forme augmentée de contenus abbr, dans la même langue.
          2. 

        2. Il existe des exemples du vrai monde en non anglais dans l'ensemencement actuel Mac OS 10.5. Cet exemple de code illustre suffisamment ce point.
          3. 

        3. Laissez SVP la clarification comme telle même si vous sentez que vous devez la REJETER de NOUVEAU (ajoutez, ne reinitialisez pas). Mes points initiaux ont été perdus quand ils ont été retirés du contexte et migrés ici. -[[User::JamesCraig|JamesCraig]]


  • problématique ouverte ! 2007-03-19 soulevée par [[User::ChristinaHope|Christina Hope]]


  1. Est-ce que Microsoft Outlook 2003 permet l'utilisation de la propriété "role" ? Je l'ai ajoutée à toutes mes hCards et cela n'apparaît pas. Suis-je en train de faire quelque erreur ?


        • URL? (si aucune URL vers un exemple démonstratif n'ets fourni dans un an, elle sera fermée comme REJETE INFORMATION INSUFFISANTE.)



  • problématique ouverte ! 2007-04-19 soulevée par Andy Mabbett

    1. Comment devrions-nous gérer les Styles Anciens et Styles Nouveaux de Dates (par ex. le calendrier Julian vs. Gregorian), dans DoB ? Par exemple, Boris Pasternak, né le "10 February [O.S. January 29] 1890". Est-ce que la spec hCard devrait spécifier New Style , en utilisant le  abbr-design-pattern si nécessaire : <abbr title="1890-02-10">29 January 1890</abbr>?


2008


  • problématique ouverte ! 2008-01-09 migrée à partir de vcard-suggestions

    1. Nous ne pouvons spas avoir un nom de type générique du fait que nous devons le localiser en français. Aussi pour nous, le numéro de téléphone professionnel est : <div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div>. Comment fera un robot pour reconnaître ce type ? Nous ne pouvons pas spécifier tous les types dans chaque langue dans la spécification. C'est pourquoi je pense que quelque chose comme ça serait mieux : Travail : <span class="telwork">0321596224</span> SVP, n'utilisez des attributs de classe et id UNIQUEMENT pour les spécifications microformats ! les #cdata et #data XML sont localisés ! Merci !


Gabarit


SVP, utilisez ce format (copiez et collez ceci à la fin de la liste pour ajouter vos problématiques ; remplacez ~~~ par un lien externe si vous préférez) pour rendre compte des problématiques ou réactions :




<div class="vevent">
* {{OpenIssue-fr}} <span class="summary vcard"><span class="dtstart">AAAA-MM-JJ</span> soulevée par <span class="fn">~~~</span></span>
<div class="description">
*# Voici la première problématique/réaction que je rencontre.
*# Voici la seconde problématique/réaction que je rencontre.
</div>
</div>




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.





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