hcard-issues-fr

From Microformats Wiki
Revision as of 10:19, 26 February 2007 by ChristopheDucamp (talk | contribs)
Jump to navigation Jump to search

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 explicatons améliorées dans la spécification.

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

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

SVP, ajoutez les nouvelles problématiques en haut de la liste.

Voir les problématiques hCalendar à ce sujet.

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

Voir aussi les problématiques hCalendar.


Problématiques

  • problématique ouverte ! 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).
  • problématique ouverte ! 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.
  • problématique ouverte ! 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. [1]). Est-ce que geo pourrait être étendu pour autoriser ça, avec des parseurs faisant la conversion vers des valeurs digitales ?
  • 2007-01-26 soulevée par James Craig sur la page accessibilité.
    1. Localisation des valeurs 'type' RFC2426. Les valeurs type RFC2426 pour adr, email et tel ont été prévues comme des valeurs lisibles par des machines. Notez que la résolution sur la Problématique #2 du parsage hCard est "la saisie du paramètre DOIT être balisé quand le contenu est disponible" mais c'est impossible à localiser. Utilisées comme du véritable contenu HTML dans l'exemple suivant, cela ne ne fonctionne uniquement qu'en anglais. La discussion sur le forum accessify décrite sur la page accessibilité a soutenu que réduire ce problème à un abbr n'est pas une solution valide et accessible.
<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>
      • REJETE. 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.
  • 2007-01-26 soulevée par James Craig sur la page accessibilité.
    1. Localisation des valeurs 'type' RFC2426. Pour des raisons de localisation, l'alternative suivante est proposée pour baliser les valeurs 'type' RFC2426 par ex à la place de :
<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>

... utiliser l'attribut class pour les valeurs types préfixés qname (et d'auttres telles que les valeurs dstart), à savoir 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="fr">Maison (préféré) : <span class="tel type:home type:pref">+1.415.555.1212</span></span>
  • problématique ouverte ! 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>

Essai 
<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)
  • problématique ouverte ! 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).
  • 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-optimiale.
          • La question est : pourquoi est-ce considéré sous-optimal si c'est bien de cacher la carte complète ?'
            • REJETE FERME 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 : [2] [3] [4] [5] -- 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 cela explicitement. Je vais avancer avec ce qu'ils disent.


  • problématique ouverte ! 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é initialement sur uf-discuss par David Janes.
  • problématique ouverte ! 2006-11-24 soulevée 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édaigent.
  • problématique ouverte ! 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.
      • A: 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
  • 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).
      • A : 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
          • A : ACCEPTEE PARTIELLEMENT RESOLUE. Malheurseument 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)
  • problématique ouverte ! 2006-10-21 soulevée par Andy Mabbett
    1. Il devrait y avoir quelque moyen de dire que l'URL d'une hCard ou d'un événement hCalendar est l'URL de la page elle-même sans avoir à inclure un lien redondant et dommageable en accessibilité sur la page elle-même.
  • 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 inattndu/contenu manquant, svp fournissez 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

  • problématique ouverte ! 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-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)
  • problématique ouverte ! 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 dans la forme "prénom nom-additionnel(ou initiale) nom-de-famille". Devrions-nous produire trois mots de fn à l'intérieur d'une notation raccourci pour que ce soit plus facile pour les auteurs ?
  • 2006-02-23 soulevée par 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 une interface pour produire plusieurs URLs, mais elles sont encore valide dans vCard et par conséquent dans hCard. --RyanKing 17:58, 12 Jun 2006 (PDT)
  • 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.
      • REJETE DEJA ESSAYE. 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-13 soulevé 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.
      • REJETE REPOUSSE. 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.
  • 2006-02-03 soulevée par Brian
    1. Nous pouvons utiliser le microformat geo dans htatom pour représenter l'élément GeoRSS
  • open issue! 2006-01-28 soulevée par Tantek sur #microformats
    1. Est-ce que hCard est vraiment approprié pour un pontage téléphonique nommé, ou avons-nous besoin de quelque chose d'autre pour un numéro de téléphone nommé qui n'est ni celui d'une personne ni celui d'organisations (les deux sémantiques actuelles précisent que ce peut être défini par hCard). Par exemple voir la hCard de "Zakim sur http://www.w3.org/2005/12/allgroupoverview.html
  • 2006-01-21 soulevée par 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 !
      • REJETE 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 fair vous devriez pouvoir mettre la classe sur ça), ou utilisez des DLs séparés dans les cas où vous auriez autrement besoin d'un élément DI.
  • 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).
  • 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-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-fr-hcard-brainstorming, mailto se fait abuser par les spammeurs. En conséquence, bon nombre d'organisations ont migré vers des formulaires de contacts basés sur le web à l'opposé des mailto. Selon la RFC 2426, Section 3.3.2, "Une valeur non-standard peut être aussi spécifiée." Cela fait-il référence à une valeur d'adresse e-mail ou une valeur type ?
      • R : ACCEPTEE FAQ. Valeur Type.
  • 2005-07-23 soulevée par DanConnolly
    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 : ACCEPTE 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 : ACCEPTE RESOLU. 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 : ACCEPTE RESOLU. 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. 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 hCard profil dit country-name mais X2V et beaucoup de données que j'ai vues disent country
      • A. ACCEPTE RESOLU. 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 quan je réparerai plusieurs bugs en une seule fois.
  • 2005-07-22 soulevée par DanConnolly
    1. ...dans mon carnet d'adresses de téléphonemobile/sidekick, j'ai un 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 que 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 appliations 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.


Hcard Canonique Faisant Autorité

  • 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 that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." 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.


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. 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. [6], [7]. [8], [9], [10]

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