hListing draft

From Microformats Wiki
Revision as of 16:26, 18 July 2020 by Aaronpk (talk | contribs) (Replace <entry-title> with {{DISPLAYTITLE:}})
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Ce document est une spécification microformat draft. Bien que les "drafts" soient en quelque sorte mâtures dans le processus de développement, la stabilité de ce document ne peut être garantie, et les implémenteurs doivent être prêts à rester informés des futurs développements et modifications. Suivez cette page wiki, ou suivez les discussions sur la liste de discussion microformats-new pour rester informé.

hListing est une proposition pour un format ouvert et distribué de petites annonces classées pour l'embarquement dans (X)HTML, Atom, RSS et le XML arbitraire. hListing serait l'un des nombreux standards microformats ouverts.


Proposition Draft

Éditeurs

Auteurs et Contributeurs


Introduction

Les individus et professionnels publient de plus en plus leurs offres en ligne : que ce soit pour la vente ou la location (voitures, maisons, appartements), de services à proposer, (cours de musique, garde de chiens, plombier), des disponibilités (jobs, bénévolat, place dans une bibliothèque) ou personnels (les gens cherchant des rendez-vous galants, des compagnons, des colocataires). Le but de la publication (et de la promotion) de ces annonces classées en ligne est de chercher des parties intéressées, souvent dans une période de temps limitée.

Alors que les descriptions de produits et services sont communes sur le web, tout particulièrement sur les sites de e-commerce, nous proposons un microformat hListing pour partager, chercher et syndiquer l'information qui aide à faire correspondre les acheteurs et vendeurs. Cette proposition suit les pratiques communes sur les sites d'échanges et de commerces tels que Craigslist, eBay et les annonces classées dans les journaux.

Si hReview traite d'un item et de ce que vous pensez, hListing traite d'un item et de ce que vous voulez vraiment en faire.

Inspiration et Remerciements

Merci à tous ceux qui ont participé dans l'activité initiale du hListing en août 2005, particulièrement Emiliano Martínez Luque et Trevor O'Reilly, pour nommer l'effort et organiser les pages listing-{brainstorming, formats, examples} sur le wiki. Nous aimerions remercier Tantek pour un débat initial afin de savoir s'il fallait étendre hReview ou poursuivre sur un hListing indépendant-bien-que-similaire pour notre proposition.

Dans le sujet

Les places de marché vibrantes en ligne ont été lancées avec pas plus que des titres, des prix, des descriptions et des adresses email de contacts ; nous espérons éveiller le même esprit de minimalisme avec cette proposition pour redémarrer la discussion active de ce que devrait être un hListing. Parce que nous sommes en train de nous aventurer dans un espace qui n'a pas de "loi établie" telle que les définitions de la vCard démarrée, nous avons été inspirés par hReview, un autre nouveau microformat combiné qui a émergé du processus de la communauté microformats.org.

En particulier, nous remarquons que les deux applications ont besoin d'un moyen de partager des descriptions informatives d'un produit ou d'un service, comprenant l'attribution de la paternité d'auteur et la provenance de l'item. Si hReview est un microformat pour décrire l'avis de quelqu'un pour un produit ou service, hListing aide à partager ce qu'on aimerait faire avec ça : le vendre, le loueur, l'échanger, exécuter ce service, l'annoncer, ou pour les gens, se rencontrer. Il peut vous dire comment contacter l'émetteur et si c'est un item sur une offre ou une annonce voulue.

Hors sujet

Nous nous concentrons pour fournir "juste assez" de structure afin de permettre la correspondance, pas pour accomplir des transactions. Ceci est distinct de la majorité des formats décrits sur le wiki sous les exemples d'annonces, qui sont assez spécifiques pour décrire complètement les produits pour la vente de détail selon la sémantique idiosyncratique des marchands spécifiques et moteurs d'achats. Au lieu de champs encodés orientés-commerce tels que les UPCs, SKUs et numéros de fabrication, cette proposition remarque que beaucoup d'annonces sont conçues pour dresser des "inventaires de quelqu'un" qui peuvent ne pas avoir de telles abstractions précises.

De la même façon, les annonces classées ne peuvent pas aspirer à décrire les prix, termes et conditions générales jusqu'aù degré nécessaire pour automatiser la totalité des transactions ou comparaisons de prix. Quelques-unes de ces annonces ont des termes qui vont au delà des limites de n'importe quel protocole de transaction B2B (par ex. "$50 obo").

Comme dans hReview, le concept d'un "objet identifiant universel" est aussi hors-sujet pour cet effort. A la différence de quelques-uns des formats "product-feed" sous les exemples d'annonces classées, nous avons évité de spécifier quelque taxonomie pour identifier ou catégoriser les listes en faveur des tags.

Format

En Général

Le format hListing est basé sur un ensemble de champs communs à de nombreux sites de listes et formats en cours d'utilisation de nos jours sur le web. Là où cela est possible, les champs de noms ont été choisis selon ceux définis par les standards apparentés hReview, hCard, hCalendar.

Schéma

Un schéma hListing devrait être composé comme suit :

  • hListing
    • version. optionnel. texte.
    • listing action. un ou plusieurs tags, ensemble suggéré : sell | rent | trade | meet | announce | offer | wanted | event | service
    • lister. requis. hCard | (fn || email || url || tel).
    • dtlisted. optionnel. ISO8601 absolute date time.
    • dtexpired. optionnel. ISO8601 absolute date time.
    • price. optionnel. texte. [devrait comprendre un nombre avec une virgule flottante avec les codes ISO optionnels de devises] - voir la proposition currency
    • item info. requis. (fn || url || photo || geo || adr) | hCard (pour les personnes ou les commerces).
    • summary. optionnel. texte.
    • description. requis. texte avec balisage optionnel XHTML valide.
    • item tags. optionnel. mots-clés ou phrases décrivant l'item étant offert, en utilisant rel-tag
    • permalink. optionnel.

Résumé des Modifications

En comparaison avec hReview :

  • Les type Item et info ont été préservés pour décrire le bien, le service ou la personne en position d'offre.
  • L'info item a été étendue pour prendre geo ou adr pour l'endroit de l'item.
  • La description de l'item est devenue obligatoire, plutôt que l'item info ou le type. Alors que les reviews (critiques) tendent à s'appliquer à une gamme de produits, les annonces classées "dans la jungle" peuvent être sui generis, trouvées avec seulement une description et aucune autre information structurée.
  • L'évaluation (rating) a été retirée.
  • L'annonceur, à la différence du critique (Reviewer), peut aussi avoir un numéro de téléphone -- mais ce peut être soit une hCard ou les autres champs.


Créer une annonce classée oblige à ajouter des métadonnées de transaction :

  • Type de transaction cherchée : que l'annonceur ait ou veuille un item (à vendre ou à louer), un service, une disponibilité ou une introduction personnelle.
  • Les dates des annonces et expiration. Une fois prises, les annonces peuvent être postées de biuyveay avec une dtexpired modifiée.
  • Le prix a été appelé spécifiquement comme un champ texte indépendant. Il peut inclure quelques définitions et conditions.

Détails des Champs

Les champs du schéma hListing représentent ce qui suit :

version :: Ce champ optionnel permet aux auteurs de hListing de spécifier une version particulière de hListing que leur contenu utilise. En omettant ce champ, l'auteur déclare que les implémentations peuvent interprétére les hListings selon n'importe quelle version de la spécification hListing. La valeur pour cette proposition en date du 6-Fév-2006 est "0.0," parce qu'elle n'a pas à cette heure quelque degré officiel.

Métadonnée Transaction

listing type :: Ce champ obligatoire indique la correspondance requise : que ce soit à propos de quelque chose que le listeur a (offer) ou veut (wanted). NOTE : Ceci a besoin d'être éclaté avec l'action listing selon la modification produite sur le résumé au-dessus.

listing action :: Ce champ requis indique l'action désirée pour le listing : un transfert permanent (sale) ; un usage passager (rent) ; troc ou donation (trade) ; organiser une introduction (meet) ; promouvoir l'existence d'un événement ou d'un vendeur (announce) ; ou exécuter un service (service).

lister :: Le personne ou les commerçants qui devraient être contactés à propos des annonces classées, soit sous la forme d'une hCard ou d'une évaluation raccourcie d'un ou plusieurs noms formatés (fn) et l'information de contact (email, url, tel). Remarquez que ce n'est pas nécessairement le même que l' author du listing.

dtlisted :: Ce champ optionnel DOIT fournir une date time ISO8601 absolue du moment où l'annonce a été initialement produite. Ce champ DEVRAIT SHOULD utiliser UTC, mais PEUT utiliser la syntaxe horaire de zone offset. Voir datetime design pattern.

dtexpired :: Ce champ optionnel fournir une date time ISO8601 absolue du moment où l'annonce expirera. Il DOIT être plus tard que le dtlisted. Ce champ DEVRAIT utiliser UTC, mais PEUT utiliser la syntaxe horaire de zone offset. Voir datetime design pattern.

Remarquez que cette définition évite le besoin d'une action "taken" sur l'annonce ; quand une annonce n'est plus valide, elle peut être simplement effacée, ou publiée de nouveau avec une date d'expiration qui est déjà passée. La republication peut être désirable, pour indiquer que l'annonce n'est plus disponible afin d'empêcher totue demande supplémentaire. Garder la date d'expiration orthogonale à l'action-annonce permet un usage d'archives des pages web avec des hListings.

location :: Ce champ optionnel contient l'endroit de l'item, qui peut être différent du lieu de l'annonceur. Ceci peut être une hCard complète avec l'information de contact, ou un type de microformat spécifique geolocation.

Il y a une discussion séparée qui doit être tenue à propos de la façon dont ces trois microformats peuvent mieux s'accommoder de la terminologie colloquiale pour “neighborhoods,” mais cette proposition ne brise pas ce nouveau terrain en inventant de nouveaux champs pour cette proposition.

price :: Ce champ optionnel décrit le prix “publicisé” de l'annonce ; ce n'est pas une offre liée, ni un prix complet de transaction. Des nombres à virgules dans cette chaîne peuvent être extraits pour trier/indexer, tout comme des symboles adjacents de devices ou des codes ISO de devises.

Notez que parce que le prix est une telle description générale, nous avons évité de promouvoir un champ supplémentaire “terms and conditions” pour compliquer le prix ou les termes du deal (par ex : “dollars”, “best offer” “per month” “paypal only”). Nous suggérons de le dégommer jusqu'à ce qu'on puisse démontrer qu'il ait besoin d'exister indépendamment de soit une descritpion (comme des frais de transport) ou un prix (qui peut simplement se déclarer “CAD$22/mo”).

Métadonnée Item

item type :: Ce champ optionnel "type" fournit le type d'item étant annoncé : un des suivants : opening, housing, product, business, event, person, place, website, url.

Notez que les deux premiers, housing et opening, sont nouveaux et uniques pour le hListing ; les autres restants sont copiés par référence provenant du hReview. Similaire à la note dans hReview 0.2 pour les types d'item, la liste énumérée de types d'annonces classées est "en développement et peut être augmentée."

item info :: Ce champ requis DOIT avoir au minimum le nom ("fn" - le texte formaté correspondant au nom) de l'item, DEVRAIT fournir au moins un URI ("url") pour l'item, et PEUT fournir au moins un URL vers une photo ou représentation ("photo") de l'item. Pour les items de type personne ou business, l'info item (fn, url, photo) DEVRAIT être encapsulée dans une hCard. Les IDs d'items uniques (par ex. ISBNs, UPCs) PEUVENT être représentées comme un URN ("url") pour l'item.

Contenu

summary :: Ce champ texte optionnel sert comme titre pour l'annonce.

description :: Ce champ requis contient la totalité du texte représentant la description écrite de l'item étant annoncé. Le champ PEUT inclure un balisage valide XHTML (par ex. des paragraphes). Les agents utilisateurs DEVRAIENT préserver n'importe quel balisage.

tags :: Les tags sont représentés en utilisant une liste de mots-clés ou phrases (en utilisant le microformat rel-tag pour chaque mot-clé individuel ou tag phrase) que le rédacteur associe avec l'item. Le rédacteur DEVRAIT fournir des tags apparentés à la façon dont il veut que l'item soit catégorisé (par ex., “car, used, acura”, “job”, “real estate, 3BR”). Le rédacteur PEUT aussi vouloir fournir des tags indiquant les conditions de paiement (“dollars”, “paypal”).

permalink :: Ce champ optionnel est un URL pour le hListing. En plus d'utilisr le tag <a href> pour ce champ, l'attribut rel="self bookmark" DOIT être utilisé pour indiquer que l'hyperlien est un lien permanent pour le résumé en lui-même. Si l'hyperlien contient déjà un attribut rel, alors les valeurs self et bookmark DOIVENT être incluses parmi l'ensemble de valeurs séparées par un espace dans l'attribut. Les indexeurs PEUVENT traiter le permalink d'une notice comme un ID unique afin d'identifier et réunir la même annonce provenant de sources multiples (tout comme indexer une page plusieurs fois). Le permalink PEUT aussi être utilisé pour indiquer ou sous-entendre l'origine de l'annonce. Les auteurs PEUVENT utiliser le nom de classe de "permalink" sur l'élément représentant le lien permanent, mais ils ne sont pas obligés de faire ainsi.

Problématiques croisées

Internationalisation : Bien qu'il existe beaucoup de souvenirs en langue anglaise, ils sont uniquement utilisés comme des noms de classe invisibles ; l'information des annonces visible par l'utilisateur peut être complètement localisée. Notez bien que les règles d'attribut lang s'appliquent encore comme d'habitude, pour les agrégateurs multilingues de hListings.

Les noms de champs suivants ont été réutilisés à partir des microformats de la hCard et du hCalendar : version, summary, fn, url, email, photo, description, categories. En outre, les items et auteurs décrits par les hCards PEUVENT contenir n'importe quel champ hCard. La valeur rel "self" a été réutilisée à partir de la spécification Atom 1.0.

Les Valeurs Par Défaut Contextuelles : Une Nouvelle Approche ?

Parce que les annonces classées peuvent être embarquées dans les billets de blog, l'email, les fils syndiqués, des pages Web simples ou d'autres microformats tels que hAtom, au degré possible, les champs suivants peuvent être "hérités" du contexte entourant un hListing si absent :

  • lister (author, contributor, From:)
  • dtlisted (Date:)
  • dtexpired (Expires:)
  • summary (title)
  • permalink (URI:, <base>)

Par contraste, le "gazetteering" est un exemple de défaut contextuel ad hoc qui n'est pas régi par cette technique. Supposer que la “Noe Valley” est dans “San Francisco, CA” parce que la hCard de l'auteur du blog est dans la même ville va au delà de la valeur contextuelle par défaut proposée ici. Tout ce que nous suggérons est l'application de DRY (“Don't Repeat Yourself”) pour les champs qui ont des définitions équivalentes ailleurs dans le même document XHTML ou ses en-têtes MIME.

Voir une discussion en rapport le 27 janvier 2006 sur hreview-feedback.

Exemples (Préliminaire)

Annonce Simple

Espace Parking à Louer (2/2/06)
2 places de parking compactes dans un garage souterrain à :
100, boulevard du Roi
Quelque part, Ile de France 78000 France
Disponible en avril 2006 pour € 215/mo
Contactez svp Jean Ledealer au 110.555.1212 (C)

 <div class="hlisting">
   <p>
     <span class="item">
     <span class="fn">Espace Parking</span>
     </span>
     <span class="offer rent">à Louer</span>
     (<abbr class="dtlisted" title="20060202">2/2/06</abbr>)
   </p>
   <p class="description">
     2 places de parking compactes dans un garage souterrain à :
     <div class="location vcard">
       <span class="adr">
       <span class="street-address">100, boulevard du Roi</span>
       <span class="locality">Quelquepart</span>, <span class="region">Ile de France</span>
       <span class="postal-code">78000</span> <span class="country">France</span> 
       </span>
     </div>
     Disponible en <abbr class="dtexpired" title="20060401">avril 2006</abbr>
     pour <span class="price">€ 215/trim</span>
   </p>
   <div class="lister vcard">
      Contactez svp <span class="fn">Jean Lebondealer</span> au 
      <span class="tel"><span class="value">(110) 555-1212</span> 
      (<abbr class="type" title="cell">Cell.</abbr>)</span>
   </div>
</div>

Exemples Étendus

Voir Exemples Etendus de hListing pour des exemples du vrai monde extraits de Craigslist, eBay.com et Match.com.

Problématiques à défier

Voir Problèmes à résoudre pour le hListing pour quelques exemples hypothétiques qui illustrent les coins de la spécification.

Exemples dans la Jungle

Cette section est informative.

Les sites suivants ont implémenté hListing, et de ce fait sont un bon point de départ pour des exemples "dans la jungle" afin d'essayer d'analyser, d'indexer, d'organiser, etc. Si votre site est marqué avec hListing, sentez-vous libre de l'ajouter en haut' de cette liste. Incluez à la fois une URL à la racine du site, et au moins une URL vers un item spécifique hListing de manière à ce que le marquage hListing puisse être vérifié.

Une fois que la liste sera trop grosse, nous produirons une page wiki distincte comme hListing-exemples-dans-la-jungle.

exemples passés

  • Edgeio http://www.edgeio.com/ produisait des hListings (jusqu'en 2007 ou 2008 - date précise demandée, regardez svp edgeio.com sur archive.org)

implémentations

Ajoutez svp les liens vers les sites qui consomment des hListings et les outils qui génèrent des hListings.

  • ...

Modifications

Changements substantiels :

  • 6 février 2006 : définitions clarifiées des champs.
  • 5 février 2006 : Reformaté en style wiki-syntaxe.
  • 4 février 2006 : Classé le sens de “taken” en dtexpired, re-importé le type item à partir de hReview, et combiné action et status. Ajouté un exemple. Oté les listes anonymes, parce que c'est un cas d'utilisation peu probable (pseudonyme, peut-être mais pas anonyme).
  • fin janvier 2006 : les conversations initiales ont démarré sur le fait que hReview fait un travail génial de description des items, et que nous pourrions corner dans la sémantique d'annonces en utilisant a) ds tags magiques pour signifier à vendre et b) mapper le prix sur les évaluations. Tantek a tapé dans le mille ceci sous une pensée a-priori et nous a encouragé de démarrer par concevoir la bonne spécification pour les annonces, et de ne partager que ce qui était nécessaire.

Discussions

Voir aussi

Retrieved from "http://microformats.org/wiki/index.php?title=hlisting-fr&oldid=69866"