hproduct-fr

<entry-title>hProduct</entry-title> 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é.

hProduct est a microformat approprié pour publier et embarquer de la donnée produit. hProduct est l'un des nombreux microformats ouverts appproprié pour l'embarquement dans le HTML, XHTML, Atom, RSS et le XML arbitraire.

hProduct Microformat Spécification Draft

Editeurs/Auteurs

(alphabétique)

Paul Lee, Google Product Search

Jay Myers, Best Buy, Co., Inc.

Contributeurs

(alphabétique)

Craig Cook, Focal Curve

Aaron Gustafson, Easy! Designs

Traduction: Christophe Ducamp

Les déclarations de copyright et de brevets s'appliquent.

Statut

Draft, version 0.3.

Introduction

Le web est une place de marché consommateur en pleine santé avec une pléthore de fabricants et vendeurs éparpillés tout autour du globe. Le vannage au travers de quantités massives de données produits non structurées est une tâche difficile tant pour les navigateurs que pour les machines. Le microformat hProduct donne de la structure à cette métadonnée en fournissant les briques pour identifier les attributs universels de produit, plus un mécanisme pour s'adapter à la grande variation dans les attributs de produit.

Le microformat hProduct peut aider les consommateurs, fabricants et distributeurs sur un grand nombre de voies. Si un navigateur ou une application comprend qu'une page web spécifique contient le microformat hProduct, il peut informer et aider à faciliter le meilleur choix produit au consommateur pour servir ses besoins. Un standard ouvert, adopté assurera que la donnée produit correcte est publiée entre fabricants et détaillants, pour le bénéfice du client. Apporter de l'ordre et de la structure aux données produits facilite tant pour les personnes que pour les organisations la production de liste pour les produits et services offerts, et aide les services web à consommer cette données produit pour l'analyse et la syndication.

Principes de Design XHTML Sémantique

Note : les Principes de Design XHTML Sémantique ont été écrits initialement dans le contexte de développement de hCard et hCalendar, par conséquent il peut être plus facile de comprendre ces principes dans le contexte de la méthodologie de design hCard (ce qui veut dire, lisez ça d'abord). Tantek

XHTML est construit sur du XML, et par conséquent les formats fondés sur XHTML peuvent être utilisés non seulement pour une présentation d'affichage pratique, mais aussi à des fins d'échanges de données. A bien des façons, les formats fondés sur XHTML illustrent le meilleur des mondes tant du HTML que du XML. Néanmoins au moment de construire des formats basés sur XHTML, cela aide d'avoir un ensemble de principes directeurs.

Réutilisez autant que possible le schéma (noms, objets, propriétés, valeurs, types, hiérarchies, contraintes) à partir des standards de référence établis et bien supportés. Evitez de redéclarer les contraintes exprimées dans le standard source. Des mentions à titre d'information peuvent passer.
1. Pour les types avec plusieurs composants, utilisez des éléments imbriqués avec des noms de classe équivalents aux noms des composants.
2. Les composants pluriels sont produits au singulier, et par conséquent plusieurs éléments imbriqués sont utilisés pour représenter plusieurs valeurs de texte qui sont délimitées par des virgules.
Utilisez la sémantique XHTML la plus précise pour construire des blocs pour chaque objet, etc.
Autrement utilisez un élément générique structurel (par ex. <span> ou <div>), ou l'élément contextuel approprié (par ex. un <li> dans un <ul> ou <ol>).
Utilisez des noms de classes basés sur des noms extraits du schéma original, à moins que le XHTML sémantique de construction de bloc ne représente précisément cette partie du schéma original. Si les noms dans le schéma original ne sont pas sensibles la casse, alors mettez tout dans un équivalent en bas de casse. Les noms de composants implicites en prose (plutôt qu'explicites dans le schéma défini) devraient aussi utiliser les équivalents bas de casse pour une facilité d'utilisation. Les espaces dans les noms des composants deviennent des caractères tiret '-'.
Pour finir, si le format de la donnée selon le schéma original est trop long et/ou non amical sur le plan humain, utilisez <abbr> au lieu d'un élément générique structurel, et placez les données littérales dans l'attribut 'title' (là où vont les expansions abbr), et l'équivalent le plus bref et le plus lisible humainement dans l'élément lui-même. De plus amples explications de cet usage de <abbr> : Human vs. ISO8601 dates problem solved

Inspiration et Remerciements

Remerciements à tous les contributeurs qui ont aidé à poser la fondation de la spécification draft hProduct en cours.

Champ d'application

Donner les détails d'un produit particulier est parfois très complexe, car les paramètres sont différents pour les livres et les CDs tout comme la différence existante entre des iPods ou des voitures. Il devrait être très facile de marquer un item en utilisant hProduct et la syntaxe devrait être simple à cette heure et suffisamment flexible pour des applications plus avancées.

Hors du champ

Ce microformat n'a pas l'intention de repliquer tout le contenu proposé dans hListing et s'inclinera pour tous les problèmes transactionnels/argent à ce microformat. Ce microformat ne tente pas aussi de spécifier une ontologie produit, ou des attributs spécifiques de catégories ; il vise plutôt à créer un cadre pour permettre une expression flexible des deux.

Format

Les mots-clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "OPTIONNELLE" dans ce document doivent être interprétés comme décrits dans la RFC 2119.

En Général

Le format hProduct est basé sur un ensemble de champs communs à de nombreux sites de ecommerce et des formats utilisés aujourd'hui sur le web.

Schéma

Le schéma hProduct se compose de ce qui suit (voir les noms de classes existants pour référence) :

hproduct
- brand. optionnel. texte. peut aussi utiliser hCard pour les fabricants.
- category. optionnel. texte. peut aussi utiliser rel-tag. ré-utilisé à partir de hCard.
- price. optionnel. floating point number. peut utiliser un format de devise.
- description. optionnel. texte. peut aussi inclure un marquage HTML valide. réutilisé à partir de hReview.
- fn. requis. texte. nom du produit ou titre. réutilisé de hCard.
- photo. optionnel. élément image ou lien. réutilisé de hCard.
- url. optionnel. href. peut contenir rel-tag rel='product'. ré-utilisé de hCard.
- review. optionnel. hReview, ou hReview-aggregate.
- listing. optionnel. hListing, ou hListing-aggregate.
- identifier. optionnel.
  - type. requis. - exemples :
    - model
    - mpn
    - upc
    - isbn
    - issn
    - ean
    - jan
    - sn
    - vin
    - sku
  - value. requis. - l'étiquette peut être implicite.

Détails des champs

Les noms de classe category, fn, photo, url sont réutilisés à partir de hCard. description est réutilisé à partir de hReview.

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

hproduct:: Nom de classe racine
brand:: Le nom de classe brand est utilisé pour identifier la marque du produit. DEVRAIT utiliser hCard pour le nom du fabricant. DOIT être singulier.
category:: le nom de classe identifie la catégorie produit. PEUT utiliser le microformat rel-tag. PEUT être pluriel pour représenter plusieurs catégories.
price:: le nom de classe price est utilisé pour indiquer le prix du produit. DOIT être singulier.
description:: le nom de classe description est utilisé pour décrire le produit. DOIT être singulier.
fn:: nom du produit en texte. DOIT être singulier.
photo:: le nom de classe photo PEUT être appoliqué à un élément <img> ou <a>. PEUT être pluriel.
url:: le nom de classe url DEVRAIT faire référence à la page web associée avec les détails produits. PEUT utiliser rel-tag, rel='product'. DOIT être singulier.
review:: le nom de classe review identifie les avis pour le produit. DEVRAIT utiliser hReview. PEUT être pluriel.
listing:: le nom de classe listing identifie les listings de produits. DEVRAIT utiliser hListing. PEUT être pluriel.
identifier:: la structure identifier est utilisée pour décrire les identifiants produits comme Model, UPC ou SKU, et elle est conçue pour s'adapter aux nouveaux identifiants ou non-identifiés-à-cette-heure. DEVRAIT être singulier.
- type:: le nom de classe type identifie le type d'identifiant.
- value:: label PEUT être implicite

Détails complémentaires

Note : Si le marquage hProduct est utilisé d'une manière "autonome" (par ex. un site de fabricant qui ne vend pas, à titre purement informationnel), il est supposé que l'attribut price représente le prix de détail suggéré par le fabricant. Toute représentation transactionnelle (commerce) du prix devrait être déléguée à hListing.

Internationalisation : Même s'il existe beaucoup de tokens en anglais, ce ne sont que des noms de classe invisibles ; la liste des informations visible pour les utilisateurs peut être complètement localisée. Remarquez que les règles d'attribut (X)HTML LANG s'appliquent comme d'habitude, pour les agrégateurs multilingues de hProduct.

Relations avec d'autres microformats

Les produits peuvent être des structures complexes avec des attributs et caractéristiques qui peuvent tomber à côté des limites du microformat hProduct proposé. Un soin particulier a été pris pour fournir juste assez d'attributs pour représenter de façon précise des produits tout en ne surchargeant pas la spec hProduct. Ceci veut dire que les solutions sémantique complètes s'appuieraient sur l'utilisation de hProduct en combinaison avec d'autres microformats pour parvenir à leurs fins. A travers les exemples (voir aussi : recipes) et analysis, il y a quelques relations claires entre hProduct et ces microformats :

hListing :: fournit un contexte additionnel au côté transactionnel d'un produit, incluant des éléments comme le prix de transaction.
hReview/hAggregate(concept) :: la recherche montre que de nombreux sites de commerce incluent des critiques de produits et ils sont souvent agrégés pour fournir des avis globaux et des critiques sur le web. Utiliser ces microformats peut fournir de la donnée additionnelle autour d'un produit ou service.
xoxo :: pour adresser les données property-value qui peuvent être nécessaire pour une représentation complète d'un produit.

Bien sûr, ce ne sont que très peu des nombreuses combinaisons qui pourraient être utilisées avec le microformat hProduct.

Profil XMDP

<dl class="profile">
	<dt>class</dt>
	<dd><p>
  <a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
   la définition HTML4 de l'attribut 'class'.</a>
  Ce profil de méta donnée définit quelques valeurs d'attribut 'class' (noms de classes) 
  et leurs significations comme suggéré par un 
  <a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
   draft de "Liens Hypertexte en HTML"</a>.</p>
	<dl>
		<dt>hproduct</dt>
		<dd>Utilisé pour identifier et décrire les métadonnées universellement communes aux produits.</dd>
		<dt>brand</dt>
		<dd>Le nom de marque du produit.</dd>
		<dt>category</dt>
		<dd>La (ou les) catégorie(s) à laquelle appartient le produit.</dd>
		<dt>price</dt>
		<dd>Le prix du produit.</dd>
		<dt>description</dt>
		<dd>Le plein texte représentant la description écrite du produit.</dd>
		<dt>fn</dt>
		<dd>Le nom commun du produit.</dd>
		<dt>photo</dt>
		<dd>L'image accompagnant le produit.</dd>
		<dt>url</dt>
		<dd>Un lien vers les détails du produit.</dd>
		<dt>review</dt>
		<dd>Un avis du produit.</dd>
		<dt>listing</dt>
		<dd>Listing détails du produit.</dd>
		<dt>identifier</dt>
		<dd>L'identifiant produit comme Modèle, SKU, ISBN, ou EAN associé au produit</dd>
	</dl>
	</dd>
</dl>

Notes

Cette section est informative.

...

Autres exemples

Regardez svp les exemples sur hProduct examples.

Copyright

JayMyers: I release all of my contributions to the public domain.

Obligation de Contribution dans le Domaine Public. Du fait que le(s) auteur(s) aient publié leurs travaux dans le domaine public, afin de maintenir le statut de ce travail dans le domaine public, tous les contributeurs sur cette page sont aussi d'accord pour publier leurs contributions dans le domaine public. Les contributeurs peuvent indiquer leur consentement en ajoutant le modèle "public-domain-release" sur leur page utilisateur selon les instructions de Déclarations d'être Volontaire pour le Domaine Public. Les contributions non publiées dans le domaine public peuvent être défaites/retirées.

Brevets

Cette spécification est sujette à une politique de brevets libres de droits, par ex. pour la Politique de Brevet du W3C, IETF RFC3667 et RFC3668.

En rappport