hlisting-proposal-fr

Cette page est destinée à traduire le contenu de la page hlisting-proposal. La traduction est en cours.

Proposition hListing

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

Proposition "Draft" du 7 février 2006

Editeur

• Rohit Khare, CommerceNet

Auteurs

• Assaf Arkin, Labnotes
• Craig Donato, Oodle
• Rohit Khare, CommerceNet

Contributeurs

• Tantek Çelik
• Ryan King

Introduction

Les individus et professionnels sont de plus en plus en train de publier leurs offres en ligne : que ce soit pour la vente ou la location (voitures, maisons, appartements), des services à louer, (cours de musique, garde de chiens, plombier), disponibiités (jobs, bénévolat, place dans une bibliothèque) ou personnels (les gens cherchant des rdv galants, des compagnons, des colocataires). Le but de la publication (et de la promotion) de ces listings 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, 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 de 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 pour savoir si étendre hReview ou poursuivre un hListing indépendant-bien-que-similaire pour notre proposition.

Etendue

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 aventure 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 une opinion de quelqu'un pour un produit ou service, hListing aide à partage 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 Champ

Nous nous concentrons pour fournir "juste assez" de struture pour permettre la correspondance, pas pour accomplir des transations. Ceci est distinct de la majorité des formats décrits sur le wiki sous les listing-examples, qui sont assez spécifiques pour décrire complètement les produits pour la vendre de détail selon la sémantique idiosyncratique des marchant spécifiques et moteurs d'achats. Au lieu de champs encondés orientés-commerce tels que les UPCs, SKUs, et numéros de fabrication, cette proposition remarque que beaucoup de listes sont pour des "inventaires de quelqu'un" qui peut ne pas avoir de telles abstractions précises.

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

Comme dans hReview, le concept d'un “objet universel identifiant" est aussi hors-sujet pour cet effort. A la différence de quelques-uns des formats "product-feed" sous [listing-examples], nous avons éviter 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]
  • item info. optionnel. (fn || url || photo || geo || adr) | hCard (pour les personnes ou les commerces).
  • summary. optionnel. texte.
  • description. requise. 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. optionnell.

Résumé des Modifications

En comparaison avec hReview :

• Item type and info have been preserved to describe the good, service, or person being offered.
• Item info expanded to take geo or adr for location of the item.
• Item description has become required, rather than item info or type. While reviews tend to apply to a range of products, listings "in the wild" can be sui generis, found with only a description and no other structured information.
• Rating has been removed.
• Lister, unlike Reviewer, can also have a telephone number -- but it must either be an hCard or the other fields.

Creating a listing requires adding transaction metadata:

• Type of transaction sought: whether the lister has or wants an item (sale or rent), a service, an opening, or a personal introduction.
• Dates of listing and expiry. Once taken, listings may be reposted with a modified dtexpired.
• Price has been called out specifically as an independent text field. It can include some terms & conditions.

Détails des Champs

The fields of the hListing schema represent the following:

version:: This optional field permits hListing publishers to specify a particular version of hListing that their content uses. By omitting this field, the publisher is stating that implementations may interpret the hListings according to any version of the hListing specification. The value for this proposal as of 6-Feb-2006 is "0.0," since it has no official standing yet.

Métadonnée Transaction

listing type:: This required field indicates the desired matching: whether it’s about something that the lister has (offer) or wants (wanted). NOTE: This needs to be collapsed with listing action per the change made to the summary above.

listing action:: This required field indicates the desired action for the listing: a permanent transfer (sale); transient use (rent); barter or donation (trade); to arrange an introduction (meet); publicize the existence of an event or vendor (announce); or to perform a service (service).

lister:: The person or business who should be contacted about the listing, either in the form of an hCard or a shorthand notation of one or more formatted names (fn) and contact information (email, url, tel). Note that this is not necessarily the the same as the author of the listing.

dtlisted:: This optional field MUST provide an ISO8601 absolute date time of when the listing was first made effective. This field SHOULD use UTC, but MAY use the time zone offset syntax. See datetime design pattern.

dtexpired:: This optional field MUST provide an ISO8601 absolute date time of when the listing will become ineffective. It MUST be later than dtlisted. This field SHOULD use UTC, but MAY use the time zone offset syntax. See datetime design pattern.

Note that this definition obviates the need for a “taken” listing action; when a listing is no longer valid, it can simply be deleted, or republished with an expiry date that has already passed. Republication may be desirable, to indicate that the listing is no longer available to forestall further inquiries. Keeping expiry orthogonal to listing-action permits archival use of web pages with hListings.

location:: This optional field contains the location of the item, which may be different than the location of the lister. This may be a full hCard with contact information, or a geolocation-specific microformat type.

There is an separate discussion to be had about how either of these three microformats can best accommodate colloquial terminiology for “neighborhoods,” but this proposal does not break new ground by coining a new fields for that purpose.

price:: This optional text field describes the “advertised” price of the listing; it is not a binding offer, nor a complete transaction price. Floating point numbers found within this string may be extracted for sorting/indexing, as could adjacent currency symbols or ISO currency codes.

Note that since price is such a general description, we have avoided promoting an additional “terms and conditions” field for elaborating on the price or terms of the deal (e.g. “dollars”, “best offer” “per month” “paypal only”). We suggest demoting it until proven that it needs to exist independently of either description (such as shipping rates) or price (which can just state “CAD$22/mo”).

Métadonnée Item

item type:: This optional field "type" provides the type of the item being listed: one of the following: opening, housing, product, business, event, person, place, website, url.

Note that the first two, housing and opening, are new and unique to hListing; the remainder are copied by reference from hReview. Similar to the note in hReview 0.2 for item types, the enumerated list of listing types is “under development and may be extended.”

item info:: This required field MUST have at a minimum the name ("fn" - the formatted text corresponding to the name) of the item , SHOULD provide at least one URI ("url") for the item, and MAY provide at least one URL to a photo or depiction ("photo") of the item. For items of type person or business, the item info (fn, url, photo) SHOULD be encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN ("url") for the item.

Contenu

summary:: This optional text field serves as a title for listing.

description:: This optional field contains the full text representing the written description of the item being listed. The field MAY include valid XHTML markup (e.g. paragraphs). User agents SHOULD preserve any markup.

tags:: Tags are represented using a list of keywords or phrases (using the RelTag microformat for each individual keyword or phrase tag) that the reviewer associates with the item. The reviewer SHOULD provide tags relating to how they want the item categorized (e.g., “car, used, acura”, “job”, “real estate, 3BR”). The reviewer MAY also want to provide tags indicating payment terms (“dollars”, “paypal”).

permalink:: This optional field is a URL for the hListing. In addition to using the <a href> tag for this field, the attribute rel="self bookmark" MUST be used to indicate that the hyperlink is a permalink for the review itself. If the hyperlink already contains a rel attribute, then the values self and bookmark MUST be included among the space-separated set of values in the attribute. Indexers MAY treat the permalink of a review as a unique ID in order to identify and collate the same listing from multiple sources (such as indexing a page multiple times). The permalink MAY also be used to indicate or imply the origin of the listing. Authors MAY use the classname of "permalink" on the element representing the permalink, but are not required to do so.

Problématiques croisées

Internationalization: Though there are many English-language tokens, they are only used as invisible class-names; user-visible listing information can be completely localized. N.b. that (X)HTML lang attribute rules still apply as usual, for multilingual aggregators of hListings.

The following field names have been reused from the hCard and hCalendar microformats: version, summary, fn, url, email, photo, description, categories. In addition, items and reviewers described by hCards MAY contain any hCard field. The rel value "self" has been reused from the Atom 1.0 specification.

Contextual Defaults: A New Approach?

Since listings may be embedded within blog postings, email, syndicated feeds, simple Web pages, or other microformats such as hAtom, to the degree possible, the following fields can be “inherited” from the context surrounding an hListing if absent:

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

By contrast, gazetteering is an example of ad hoc contextual defaulting that is not governed by this technique. Guessing that “Noe Valley” is in “San Francisco, CA” because the hCard of the blog author is in the same city is beyond the pale of the contextual defaulting proposed here. All we are suggesting is application of DRY (“Don’t Repeat Yourself”) for fields that have equivalent definitions elsewhere within the same XHTML document or its MIME headers.

See a related discussion on 2006-01-27 on hreview-feedback.

Exemples (Préliminaire)

Listing Simple

Parking space for rent (2/2/06)
2 compact car spaces in a secure underground garage at:
1738 Elm St.
Somewhere, ED 34567 ISA
Available in April 2006 for $215/mo
Please contact John Broker at 110.555.1212 (C)

 <div class="hlisting">
   <p>
     <span class="item fn">Parking space</span>
     <span class="offer rent">for rent</span>
     (<abbr class="dtlisted" title="20060202">2/2/06</abbr>)
   </p>
   <p class="description">
     2 compact car spaces in a secure underground garage at:
     <div class="location vcard">
       <span class="street-address">1738 Elm St.</span>
       <span class="locality">Somewhere</span>, <span class="region">ED</span>
       <span class="postal-code">34567</span> <span class="country">ISA</span> 
     </div>
     Available in <abbr class="dtexpired" title="20060401">April 2006</abbr>
     for <span class="price">$215/qtr</span>
   </p>
   <div class="lister vcard">
      Please contact <span class="fn">John Broker</span> at 
      <span class="tel"><span class="value">(110) 555-1212</span> 
      (<abbr class="type" title="cell">C</abbr>)</span>
   </div>
</div> 

Exemples Etendues

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

Problématiques à défier

See hListing Challenge Problems for some hypothetical examples that illustrate corners of the specification.

Modifications

6 Feb 2006: clarified definitions of fields throughout.

5 Feb 2006: Reformatted into wiki-markup style.

4 Feb 2006: Folded the sense of “taken” into dtexpired, re-imported item type from hReview, and combined action and status. Added an example. Removed anonymous listings, since that is an unlikely use case (pseudonymous, perhaps, but not anonymous).

late Jan 2006: initial conversations started with the insight that hReview does a great job of describing items, and that we could shoehorn in listing semantics using a) magic tags to mean for-sale and b) mapping price onto dimensioned ratings. Tantek correctly nailed this as a-priori thinking, and encouraged us to start by designing the right spec for listings, and only sharing what was necessary.

Discussions

• Feedback encouragé sur la page hlisting-feedback.
• Voir aussi les blogs discutant de cette page.