hcard-issues-resolved-fr

hCard Problématiques Résolues

Voir hCard-problématiques pour les problématiques non résolues.

problématiques fermées

les problématiques résolues où il n'y a plus d'actions à mener.

2007

• 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]].
  1. Proposition d'utiliser l'attribut de classe pour les valeurs types préfixées qname (et d'autres comme les valeurs dtstart), aussi connues comme les classes meta.

<span xml:lang="en">Home (preferred): <span class="tel type:home type:pref">+1.415.555.1212</span></span> <span xml:lang="es">Casa (preferido): <span class="tel type:home type:pref">+1.415.555.1212</span></span>

• 1. • REJETE DOUBLON ETC. Class attributes for type values was tried and rejected and in addition, qnames-considered-harmful-fr.
     • Proposition clarifiée, laissée REJETEE.

• 2007-05-08 raised by Tantek as a result of a message from Andy Mabbett on microformats-new
  1. 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.
  2. 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.".
     • DOUBLON. Voir problématique du 2006-12-15.

problématiques résolues

les problématiques qui ont été résolues mais peuvent avoir encore des items marquants en to-do. Du fait que les problématiques sont résolues, elles seront migrées à partir de la liste des problématiquesIssues list

2005

• 2005-06-21 soulevée par Hixie
  1. 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 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.
  1. 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 Brian Suda (2005-11-08 mise à jour par 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. <abbr title="Middle Name" class="additional-name">M</abbr>. Les suffixes honorifiques dans la RFC comprennent Jr. Esq. et d'autres suffixes hérités, ainsi j'utiliserais juste <span class="honorific-suffix">Jr.</span> etc.
  2. 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 Brian Suda (2005-11-08 mis à jour par 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 :

<span class="adr">
<span class="type">work</span>:
...
</span>

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

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

• 2005-07-22 soulevée par DanConnolly
  1. ... 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 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é !
       1. Régler "fn" et "org" à la même valeur. par ex. <span class="fn org">W3C</span> (recommandée)
       2. Régler "org" comme d'habitude, et régler "fn" explicitement à vide. par ex. <span class="fn"></span><span class="org">W3C</span> 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é : X-ABShowAs:COMPANY
     • 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 X-ABShowAs:COMPANY
         • 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. 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.
     • RESOLU. hCard décrit maintenant spécifiquement l'info de contact organisation. Reste à faire : ajouter à hcard-faq-fr.

• 2005-07-23 soulevée par DanConnolly
  1. Est-ce que les noms de classes sont sensibles à la casse ou non ? 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.
  2. ... 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 Brian Suda j'ai réparé toutes les références dans la page hcard-brainstorming pour renvoyer le style en plus bas de casse, ceci est un report du design original, X2V a été mis à jour.
  3. ..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.
       • rfc2629xslt.html utilise Street-Address, Family-Name, etc.
         • R : Par Julian Reschke Réparé rfc2629.xslt (2005-10-29)
       • X2V Version 0.5.1 2005-07-08 supporte Family-Name etc.
         • R : Par 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.
  4. Le truc ul/ol pour plusieurs valeurs de propriété semble être dans le code X2V et dans le hcard-brainstorming mais pas dans la spec 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.
  5. le profil hCard dit 'country-name' mais X2V et beaucoup de données que j'ai vues disent country
     • A. ACCEPTEE 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 Brian Suda j'ai réparé toutes les références dans la page 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-08-12 soulevée par Jack L. Wolfgang II. L'utilisation de la fonctionnalité de transport mailto pour le champ adresse email.
  1. Comme cela a été déclaré dans le document 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 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-08-12 soulevée par Jack L. Wolfgang II. L'utilisation de la fonctionnalité de transport mailto pour le champ adresse email.
  1. Comme cela a été déclaré dans le document 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 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-10-30 soulevée par Julian Reschke.
  1. 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 contains(concat(@class,' '),'vcard ').
     • REJETEE VAGUE. Quelles implémentations ? Et quels exemples?
     • (Note : le code contains(concat(@class,' '),'vcard ') est brisé voir parser les valeurs de classes pour un exemple correct --Robert Bachmann)

• 2005-12-08 soulevée par Kenny Heaton.
  1. 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).

2006

• 2006-01-21 soulevée par Ben Boyle.
  1. 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.

• problématique ouverte ! 2006-01-23 soulevée par David Janes (?).
• Problématique 1 : Spécifier la hCard Faisant Autorité ou Canonique ou Officielle
  • 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 profil XFN et la RFC 4287. Voir la discussion sur la liste à propos de rel="me self" pour plus d'information. 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." 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. 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.

• 1. • ACCEPTEE PARTIELLEMENT. PLUSIEURS PROBLEMATIQUES ET BRAINSTORMING. Les questions sur "authoritative" et "canonical" et "representative" sont problablement des questions différentes et doivent être déconstruites dans des problématiques différentes. - Tantek
       • Voir hCard représentative pour la résolution de la question de la hCard représentative.
       • la hCard "authoritative" a besoin d'une meilleure définition de la question spécifique
       • hCard "canonical" a besoin d'une meilleure définition de la question spécifique.

• problématique ouverte ! 2006-01-28 soulevée par Tantek sur #microformats
  1. 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
     • ACCEPTEE FAQ. Bien que hCard ait été étendu our permettre des endroits nommés, ceux-ci sont des endroits physiques, et hCard n'est vraiment pas pertinent pour des endroits virtuels nommés (aussi connus comme des adresses virtuelles) tels qu'un numéro de téléphone ou une uRL. Néanmoins compte tenu du cas d'usage d'avoir un contact dans le carnet d'adresses de quelqu'un sur "Zakim" afin de "composer le numéro de Zalkin" peut être recommandé dans un groupe de discussion IRC, peut-être que Zakim est une entité virtuelle comme une organisation - Tantek

• 2006-02-03 soulevée par Brian
  1. Nous pouvons utiliser le microformat geo dans htatom pour représenter l'élément GeoRSS
     • ACCEPTEE DOCUMENTATION. Oui ceci devrait être documenté dans hAtom-exemples. -Tantek

• 2006-02-13 soulevée par Eron Wright
  1. 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. Voir aussi geo-extension-elevation.

• 2006-02-19 soulevée par Miika Mäkinen.
  1. 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 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 <abbr class="type" title="work">W:</abbr> afin de présenter le type d'une manière qui puisse mieux coller avec le reste de votre présentation.

• 2006-02-23 soulevée par Jesse Skinner et Ben Buchanan.
  1. Est-ce que plusieurs URLs sont permises ? La 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. --RyanKing 17:58, 12 Jun 2006 (PDT)

• 2006-03-07 soulevée par Tantek.
  1. 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 raccourcie pour que ce soit plus facile pour les auteurs ?
     • REJETE. J'ai vu suffisamment de cas supplémentaires dans les systèmes qui ont des noms complets mais pas des noms structurés qui ont des noms de famille à plusieurs noms ce qui je pense un tel algorithme peut provoquer de la corruption de données là où la partie d'un nom de famille est interprétée comme un "additional-name". -Tantek

• 2006-04-06 soulevée par Evan.
  1. Quelle est la relation entre la propriété CATEGORY et 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-fr) est utilisé pour la catégorie. Exemples : (1) <span class="category">cuisine</span> et (2) <a class="category" rel="tag" href="http://exemple.com/cuisine">Cuisine !</a>. --RyanKing 15:16, 13 Jun 2006 (PDT)

• 2006-04-10 soulevée par Scott Reynen.
  1. Quand quelqu'un cherche les pages 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 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.
     • ACCEPTE. D'accord. Une partie de cela est maintenant documenté dans hcard-design-méthodologie, mais en to-do : documentation supplémentaire dans le processus et process-faq-fr.

• 2006-11-15 soulevée par Lachy dans #whatwg (un canal IRC sur freenode à propos de The WHATWG).
  1. Je pense que l'ensemble de la spécification hCard a besoin d'être restructuré.
     • ACCEPTE. Moi (l'éditeur, Tantek) ait récrit la spec en rapport depuis juin 2007.
  2. C'est incroyablement difficile de sortir ce que chaque nom de classe signifie et comment les utiliser proprement..
     • ACCEPTE. Bien que la liste par items des noms de classes ait été ajouté, les définitions sont dans le profil hCard et la manière de les utiliser (quelques unes d'entre elles) sont dans hCard-publication, mais devrait aussi être brièvement dans la spec. - Tantek

• 2006-11-15 soulevée par hsivonen dans #whatwg.
  1. Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.
     • ACCEPTEE. This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the hCard profile which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them, as well as by adding to the itemized list of properties in the spec at least brief definitions that then link to the expanded definitions in the profile. - Tantek

• 2006-11-15 soulevée par Hixie dans #whatwg (et d'accord avec Lachy et hsivonen).
  1. La spéc hCard se lit basiquement comme un brainstorm, pas une spec normative
     • ACCEPTEE. En tant qu'éditeur je chercherai à rendre la spec hCard comme écrite normativement comme pour les dernières recommandations communes du W3C, et je l'espère au niveau de la spécification HTML5. -Tantek

• 2006-11-16 soulevée par Andy Mabbett
  1. 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 : 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 ? 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 à cet effet et ajouté cette suggestion. - Tantek
           • La spéc. vCard est mise à jour par RFC, par exemple RFC 4770. Andy Mabbett 06:22, 12 Jan 2007 (PST)

• 2006-11-17 soulevée par Lachlan Hunt (Je seconde tous ces items de feedback. Andy Mabbett 07:15, 17 Nov 2006 (PST))
  1. Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
     • ACCEPTEE. I've expanded on the specifics of this section AND moved it to a separate page accordingly hcard-design-methodology-fr.
  2. Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
     • ACCEPTEE. Each property has now been listed explicitly. Brief explanations of each property will be added. -Tantek
  3. Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
     • ACCEPTEE PARTIELLEMENT. The definition of singular and plural in this context will be expanded to clarify. Listing the number of times a property can be used with the individual property description will be considered, but may be rejected per editor discretion of keeping the spec shorter and simpler. -Tantek
  4. Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
     • ACCEPTEE. Cette section a migré sur notes d'information sur la section dérivation. -Tantek
  5. Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC2119 terminology that describes exactly what a UA has to do. Presently, it's written too informatively, rather than normatively (particularly for the abbr element).
     • ACCEPTEE PARTIELLEMENT. Note that the title also makes sense for the use of URL properties in attributes like href and src. A conformance requirements section is a reasonable request, but it may reference the Human vs. Machine Readable section rather than included it for better document flow. Agreed on use of RFC2119 terminology. -Tantek
  6. Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
     • Property name
     • Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
     • Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
     • Usage
       • Contexts in which this property may be used
       • Content model (e.g. list of sub properties, expected elements, text, or whatever)
       • Syntax of the value (i.e. plain text, number, URI, etc.)
       • Elements this property may be used on
     • How to interpret the value (may link to relevant section in Conformance Requirements)
     • ACCEPTEE PARTIELLEMENT. Much of this is good feedback on how to improve the property listing. Per some of the above resolutions, editor's discretion will be used to keep the property listing as short and simple as possible for better readability/accessibility. - Tantek

• 2006-11-23 soulevée par Andy Mabbett
  1. 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 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. Andy Mabbett
  2. La spécification devrait déclarer que les "numéros de téléphone DEVRAIENT adhérer à la 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 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. Andy Mabbett
     • ACCEPTEE DOCUMENTATION. to-do. -Tantek

• 2006-11-24 soulevée par Andy Mabbett
  1. 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édaignent.
     • ACCEPTEE FAQ, PROPOSITION. Cette technique pour communiquer le genre devrait être documentée dans la FAQ, tout comme les limites notées dans cette problématique, tout comme un pointeur vers la proposition de genre en progrès. La proposition de genre devrait aussi pointer vers cette technique existante, et noter ses limites comme justification supplémentaire pour la proposition. -Tantek

• 2006-12-07 soulevée par RyanKing.
  1. l'org-fn de la hCard correspondant devrait utiliser organization-name, s'il est donné.
  2. soulevée initialement sur uf-discuss par David Janes.
     • ACCEPTEE. C'est une bonne clarification suggérée. Tantek to-do : mettre à jour hCard.

• 2006-12-15 soulevée par WizardIsHungry
  1. [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 ? --Jon Williams 10:28, 22 Dec 2006 (PST)
     • En outre, 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. --Jon Williams 13:33, 5 Jan 2007 (PST)
     • Ce devrait être sur microformats-problématiques ? --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 exemples dans la jungle : [1] [2] [3] [4] -- 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. -- Jon Williams 13:24, 9 Jan 2007 (PST)
               • ACCEPTEE FAQ. Ceci est basé sur le principe de visibilité de donnée des microformats qui est meilleur que la donnée invisible. Plus de documentation sur la page des principes des microformats. la faq a aussi une question et réponse en rapport.
     • hcard-brainstorming-fr#Styles_CSS permet ça explicitement. Je vais voir ce qu'ils en disent.
       • REJETEE. Notez cette section qui dit explicitement : "ATTENTION : ceci est vraiment recommandé CONTRE". -Tantek

• 2006-12-15 soulevée (le 2006-12-14, sur la liste de discussion) par Joe Andrieu.
  1. (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).
     • Apparemment intentionnel, mais exigeant probablement une extension plus poussée. Andy Mabbett
     • REJETEE. Parce qu'il existe des règles précises de parsage pour déterminer si une une hCard est une organisation, ou si une hCard est un lieu, la précision sémantique est préservée provenant de l'auteur qui décide de publier une personne, une organisation ou un lieu à travers le parseur, qui détermine la spécificité sémantique de savoir si la hCard est une personne, organisation ou un lieu -Tantek
     • ROUVERTE - la dernière est une proposition récente sur une page de brainstorming et rien de plus. Il y a une insuffisance évidente d'usage dans la junge pour être sûr de savoir si oui ou non cela rencontre tous les comportements communs de publication. Andy Mabbett 05:32, 15 Dec 2007 (PST)
     • ACCEPTEE PARTIELLEMENT. La portion organisations vs. personne reste REJETEE. Néanmpoins comme indiqué, la proposition de lieu nommé a besoin d'être testé avec plus d'exemples. - Tantek
     • Consider also an hCard for a City, "Birmingham, England": Birmingham may be the "fn" and the "locality", but it's not an "extended-address". Perhaps the rule should be that the hCard is for a place if the "fn" is on any address component (e.g "fn locality" or "fn street-address")? See discussion at [5] et seq. Andy Mabbett 16:15, 30 Dec 2007 (PST)
       • If so, the "implied-n-optimisation" rule will need to be modified, to exclude cases where the fn is on the same attribute as an adr-child (which should probably not happen anyway). Andy Mabbett 13:59, 2 Jan 2008 (PST)

2006

• 2006-11-15 soulevée par Lachy dans #whatwg (un canal IRC sur freenode à propos de The WHATWG).
  1. Je pense que la totalité de la spécification hCard a besoin d'être restructurée.
  2. C'est incroyablement difficile de travailler avec ce que chaque nom de classe signifie et comment les utiliser correctement.

• 2006-11-15 soulevée par hsivonen dans #whatwg.
  1. Sans connaître iCalendar ou vCard, c'est vraiment non-évident de voir ce à quoi s'adapteront les hCards ou les hCalendars. La partie normative est extrêmement courte et ne semble pas établir suffisamment clairement un mapping entre les microformats et les RFCs.
     • Ceci (et la seconde réaction de Lachy au point ci-dessus) devrait être résolu en clarifiant le mapping avec un meilleur usage du hCard profile qui mappe vraiment clairement les noms de classes vers les propriétés vCard properties et les sections de la spécification vCard qui les définit. - Tantek

• 2006-11-15 soulevée par Hixie dans #whatwg (et accord par Lachy et hsivonen).
  1. La spec hCard se lit basiquement comme un brainstorm, pas une spec normative.

• 2006-11-17 soulevée par Lachlan Hunt.
  1. Principes de Design XHTML Sémantique : Cette section devrait partir. Les lignes de conduite sur la façon d'écrire une spécification de microformats n'appartiennent pas à la spec elle-même.
  2. Format - Plus d'Equivalents Sémantiques : Les explications sur la façon d'utiliser correctement chaque propriété devraient être données avec chacune et toutes les propriétés, pas simplement en lister quelques-unes en haut avant que les propriétés n'aient été définies.
  3. Singulier vs. Pluriel : Il est peut clair de ce que veut dire les propriétés singulière vs plurielle. Ordinairement, un pluriel est un mot qui fait référence à plusieurs objets, mais dans cette spec, il est utilisé pour désigner une propriété qui peut être utilisée plus d'une fois. Cela ne fait pas de sens parce que la propriété elle-même n'est pas un pluriel. A côté de cela, cette section devrait partir. Le nombre de fois où une propriété peut être utilisée devrait être listé avec chaque description individuelle de propriété.
  4. Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
  5. Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
  6. Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
     • Property name
     • Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
     • Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
     • Usage
       • Contexts in which this property may be used
       • Content model (e.g. list of sub properties, expected elements, text, or whatever)
       • Syntax of the value (i.e. plain text, number, URI, etc.)
       • Elements this property may be used on
     • How to interpret the value (may link to relevant section in Conformance Requirements)
  • I second all of the above. Andy Mabbett 07:15, 17 Nov 2006 (PST)

2007

• 2007-01-22 soulevée par Christina Hope.
  1. 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.
     Exemples : (1)

     <p>

<span class="vcard"> <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>

• 1. • ACCEPTEE FAQ.

Essayez

<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>

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.

Andy Mabbett 08:34, 22 Jan 2007 (PST)

• 2007-01-30 soulevée par Andy Mabbett
  1. Beaucoup de sites, au moins Wikipedia, publie les coordonnées sous des degrés-minutes-secondes (par ex. [6]). Est-ce que geo pourrait être étendu pour autoriser ça, avec des parseurs faisant la conversion vers des valeurs digitales ?
     • ACCEPTEE BRAINSTORMING. My first instinct is that if a precise grammar can be defined for the human friendlier d-m-s syntax, and if that precise grammar reflects the 80% of existing real world cases (e.g. Wikipedia as cited), then it should be considered for addition to the geo property and thus hCard. This may help reduce the number of instances of needing to duplicate the d-m-s value as a decimal value for machines. -Tantek

• 2007-02-02 soulevée par [[User::DerrickPallas|Derrick Pallas]]
  1. adr dit que tout de ses propriétés sont singulières, "street-address" est listé comme zéro-ou-plus.
     • ACCEPTEE. Ceci semble avoir été fixé dans spécification adr-fr. "street-address" n'est plus listé comme "zero-or-more".

• 2007-02-25 soulevée ailleurs par User:JamesCraig
  1. Note sur l'internationalisation : le country-code peut être manquant. Généralement un préfixe postal-code tel que "FIN-00630 Helsinki" ou "L-4750 Petange" (Luxembourg).
     • ACCEPTEE FAQ. Ceci semble comme simplement une FYI/FAQ plutôt qu'une vraie problématique. Souvent les noms de pays peuvent être inférés à partir des codes postaux. Aussi peut-être que le nom de pays peut être marqué sous un sous-ensemble abbr du code postal dans les cas de l'exemple donné "FIN" -Tantek

• 2007-03-26 soulevée par Andy Mabbett
  1. Les parseurs (Operator, Tails) attendent actuellement que adr 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
     • ACCEPTEE. Tantek to-do : Ajouter plus de précisions sur la façon de gérer les sous-propriétés adr (ou le manque) à adr et hcard. En particulier, une "adr" sans sous-propriétés ne fournit simplement aucune information.

• 2007-03-31 soulevée par Andy Mabbett
  1. Le schéma WGS84 utilisé comme un défaut par geo ne demeurera pas valide pour toujours. Heureusement l'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. Andy Mabbett 13:00, 31 Mar 2007 (PDT)
     • Remarquez aussi le schéma "European Terrestrial Reference System 89" (Voir aussi Etrs89 sur Wikipedia. Andy Mabbett 03:11, 5 avril 2007 (PDT)

• 1. La problématique de l'Internationalisation (i18n) pour l'optimisation implicite de FN. Beaucoup de langues (par exemple le japonais) listent souvent FN comme "family-name given-name" au lieu du supposé "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 les deux mots FN sont un raccourci pour les langues occidentales et que toute langue ne correspondant pas à ce format devrait explicitement définir "family-name" et "given-name" à chaque fois.
     • ACCEPTEE. Tantek to-do : ajouter une section internationalisation dans la spec hCard et noter dans la spec indiquant que le FN en deux mots est un raccourci pour les langues occidentales et que toute langue ne satisfaisant pas ce format devrait définir explicitement à chaque fois "family-name" et "given-name".

• 2007-04-09 soulevée Andy Mabbett
  1. Pourquoi est-ce geo est encore un "draft", alors qu'il est inclus dans la spec hCard déjà sortie ?
     • ACCEPTEE. geo-fr a été examiné minutieusement depuis suffisamment longtemps par la communauté pour être élevé au même niveau que hCard. Tantek to-do : envoyer un email vers microformats-new pour proposer ça.

• 2007-04-21 soulevée par Mark Nottingham.
  1. Les pages listent souvent beaucoup d'adresses dans la même localité, mais hCard (et adr) sont actuellement structurés de telle sorte que vous devez répéter le contexte global complet pour chaque adresse. Par exemple,

<h2>Pizza Shops in Burlingame, California</h2>
<ul>
<li>Round Table - 231 Burlingame Avenue</li>
<li>Village Host - 303 Broadway</li>
<li>Pizza Hut - 43423 El Camino Real</li>
</ul>

Tel que spécifié, il y aurait beaucoup d'information répétée ici.

Néanmoins, si adr permettait l'usage de locality, region, postcode et country comme des ancêtres des balises addresss plus spécifiques, cela ferait gagner beaucoup de bits -- et aiderait à l'adoption de ces microformats dans ce genre de cas (qui est tout à fait courant).

• 1. • ACCEPTEE FAQ. Utiliser include-pattern. Andy Mabbett 03:51, 21 Apr 2007 (PDT)

• 2007-04-24 soulevée par singpolyma
  1. A quoi sert la propriété 'Label
     • ACCEPTEE. Selon les première résolutions, plus d'explication sera ajoutée à la spéc hCard, et cette question devrait aussi être ajoutée à la hcard-faq.

• 2007-04-27 soulevée par Sjoerd Mullender
  1. There is a proposal for a geo URI scheme [7]. It would be nice if that scheme and the geo hCard type could somehow be combined. It seems to me that if you want to use both and also have a human-readable version, you need three copies of the latitude/longitude:

     <p>Location: <a href="geo:52.356389,4.952222"><span class="geo"><abbr class="latitude" title="52.356389">52°21'23.00"

N</abbr> <abbr class="longitude" title="4.952222">

4°57'08.00" E</abbr></span></a></p>

• 1. • ACCEPTEE BRAINSTORMING. This is a very interesting proposal, and clearly it is desirable to minimize the number of copies of the latitude/longitude. Thus this should be added to the geo brainstorming geo links section. -Tantek

• 2007-08-03 soulevée par MikeKaply.
  1. Problématique 1: Au moment d'utiliser le value-design-pattern, est-ce que la donnée devrait être extraite complètement (y comprit les tags HTML) ou juste le contenu texte ? En général, le value pattern semble prendre implicitement exactement la donnée.
     • ACCEPTEE FAQ. Pour l'extraction de valeurs, le parsage est géré comme il le serait pour une propriété, mais juste sur l'élément avec le nom de classe "value" plutôt que l'élément avec le nom de classe de la propriété elle-même. De ce fait en général, juste le contenu de texte mais regardez les combinaisons spécifiques de hcard-parsage de propriété et/ou élément pour les cas spéciaux. C'est juste le include-pattern qui incorpore le sous-arbre HTML (y compris les tags) dans son intégralité.

• 2007-11-04 soulevée RalfEngels.
  1. Problématique 1 : La section Organization Contact Info est excessivement vague. Elle dit "I must not set the N property" and later on it says that I could set it to an empty value. Which of both is true? Must not or empty?
     • ACCEPTEE. Tantek to-do: clarifier la spec sur ce point. Not setting it and setting it to empty have the same effect. Improve the wording.
  2. Issue 2: Same section. It does not cover e.g. Mr Fischer (N=Fischer) from the Fischer AG (ORG=Fischer). Could you re-formulate it stating that if the N attribute is missing the hcard is regarded as the card of a company.
     • REJETEE. If the "n" property is missing, then remaining fn+org or implied fn rules still apply.
  3. Issue 3: Grouping as specified by rfc2425 and supported by vcard cannot be expressed. Grouping allows you to express the relation between different values.
     • REJETEE. hCard only maps the properties and values from vCard, not all features. Grouping in particular is excluded.
  4. Issue 4: Implied n optimization: the typical case list specifies a (space) in the first and last line. In the middle lines it specifies a (comma). I guess this should mean (comma)(space) instead. In addition it contradicts with the previous text where you state that the separating character is a (whitespace)
     • ACCEPTEE. Tantek to-do: clarify the spec on this point. space and whitespace are the same in this context.
  5. Issue 5: Concatenation of texts is not consistent in the examples. Example file 21 contatinates telephone fields with spaces. Example 16 concatenates multiple name sub-properties by a comma. Example 34 even concatinates multiple note fields.
     • ACCEPTEE. Tantek to-do: clarify concatenation handling in hcard-parsing. to-do: correct hCard-exemples accordingly.