hcard-issues-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
([fr: sync'd with english version - translation in progress])
Line 12: Line 12:
== problématiques fermées ==
== problématiques fermées ==
<span id="Closed_Issues-fr">Les problématiques résolues qui n'ont plus d'actions à prendre.</span> Celles-ci seront probablement déplacées sur une page distincte comme [[hcard-issues-closed-fr|hcard-problématiques-résolues]].
<span id="Closed_Issues-fr">Les problématiques résolues qui n'ont plus d'actions à prendre.</span> Celles-ci seront probablement déplacées sur une page distincte comme [[hcard-issues-closed-fr|hcard-problématiques-résolues]].
=== 2007 ===
 


=== 2007 ===
=== 2007 ===

Revision as of 18:47, 5 January 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.

Problématiques

problématiques fermées

Les problématiques résolues qui n'ont plus d'actions à prendre. Celles-ci seront probablement déplacées sur une page distincte comme hcard-problématiques-résolues.


2007

  • 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]].
    1. Proposition d'utiliser l'attribut de classe pour le qname préfixé avec des valeurs type (et d'autres telles que les valeurs dtstard), aussi connues comme des méta-classes. 


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





  • 2007-05-08 soulevée par Tantek comme un résultat du message provenant de Andy Mabbett sur microformats-new

    1. How do you distinguish a place vs. an organization hCard, both from the perspective of a publisher (author) souhaitant exprimer une sémantique particulière, et en partant de la perspective d'un parseur (développeur) souhaitant discerner la différence ? C'est différent de la problématique du 2006-12-15 sur la spécificité sémantique parce que cette problématique est *spécifiquement* à propos d'un endroit plutôt qu'une org, plutôt que "conflating" ça avec person.
      2. 

    2. Note : le billet de la liste de diffusion cité dans la problématique du 2006-12-15 est très clair ; il dit "quand un spider trouve une hCard, il ne peut pas dire si c'est une personne, une société, une organisation ou un endroit".

      • 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. Le fait que les problématiques sont résolues, elles seront migrées en haut de la [[hcard-issues-fr#Problématiques|liste des problématiquesen bas de cette section.



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. 

    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. 

        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. 

    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. 

    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.

          • 

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

    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. 

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



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

      • 

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



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



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

    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.

      2. 

    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. 

    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. 

    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. 

    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. 

    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. 

    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. 

    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)

        • 

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


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>

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



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



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

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

    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. 

    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. 

    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. 

    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.



problématiques


Ajoutez svp les nouvelles problématiques en bas de la liste en copiant et collant le Gabarit.  SVP relancez vers les problématiques résolues/rejetées avec de la nouvelle information plutôt que de soumettre de nouveau de telles problématiques. Les ajouts de problématiques en duplicata 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]].
    • 

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







Gabarit


SVP utilisez ce format (copiez et collez ceci à la fin de la liste) pour rajouter vos problématiques : 



  • problématique ouverte ! AAAA-MM-JJ soulevée par VotreNom.

    1. Problématique 1 : Voilà la première problématique que j'ai.
      2. 

    2. 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. [8], [9]. [10], [11], [12]



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=24948"