hcard-feedback-fr

From Microformats Wiki
Revision as of 20:06, 9 January 2007 by ChristopheDucamp (talk | contribs)
Jump to navigation Jump to search

hCard réactions

Les réactions générales à propos de hCard peuvent être fournies ici, et le(s) éditeur(s) feront de leur mieux pour essayer de se plier et d'accomoder à de telles réactions. Plus la réaction est spécifique, plus il y aura de chance qu'elle soit prise en compte. Pour les problématiques spécifiques avec la spécification (à l'inverse des problèmes généraux et réactions), utilisez svp la page hCard problématiques.

IMPORTANT : Lisez SVP avant la page hCard FAQ en donnant toute réaction ou pour soulever toutes les problématiques car vos réactions/problématiques peuvent avoir été déjà résolues ou traitées.

La réaction peut (et sera probablement) éditée et récrite pour une meilleure concision, clarté rationnalité et sous un point de vue aussi neutre que possible. Utilisez le gabarit fourni et ajoutez votre réaction à la fin de la section Réaction. Ecrivez bien votre réaction. — Tantek

Réactions

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

Gabarit

Utilisez svp ce format (copiez et collez ceci à la fin de la liste pour ajouter votre réaction ):

  • AAAA-MM-JJ soulevée par VOTRENOM.
    1. Voici la première réaction générale que j'ai.
    2. Voici la seconde réaction générale que j'ai.

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-feedback-fr&oldid=24946"