hlisting-feedback-fr - Revision history

Brian: Reverted edits by TroccHidro (Talk) to last version by ChristopheDucamp

2008-12-20T21:06:22Z

Reverted edits by TroccHidro (Talk) to last version by ChristopheDucamp

← Older revision		Revision as of 21:06, 20 December 2008
Line 1:		Line 1:
	~~relbode~~		<h1> hlisting-réactions </h1>
	<h1> hlisting-~~rÃ©actions~~ </h1>
	{{TOC-right}}		{{TOC-right}}
	Ce document est ~~destinÃ© Ã~~ conserver trace des ~~rÃ©actions~~ concernant le [[hlisting-fr\|hListing]], l'un des nombreux [[microformats-fr\|microformats]].		Ce document est destiné à conserver trace des réactions concernant le [[hlisting-fr\|hListing]], l'un des nombreux [[microformats-fr\|microformats]].


Line 8:		Line 7:
	{{issues-format-fr}}		{{issues-format-fr}}

	== ~~ProblÃ©matiques~~ du ~~SchÃ©ma~~ ==		== Problématiques du Schéma ==

	=== Item ===		=== Item ===

	* est-ce que class="item" fait partie de la spec ? Ce n'est pas clair dans la proposition.		* est-ce que class="item" fait partie de la spec ? Ce n'est pas clair dans la proposition.
	* si ce l'est, est-ce optionnel (comme dans le [[hlisting-proposal-fr#~~SchÃ©ma~~\|~~schÃ©ma~~]]) ou requis (comme sous-entendu par la section de l'item [[hlisting-proposal-fr#Item_Metadata\|item ~~mÃ©tadonnÃ©es~~]]). Mon sentiment est que cela devrait ~~Ãªtre~~ requis		* si ce l'est, est-ce optionnel (comme dans le [[hlisting-proposal-fr#Schéma\|schéma]]) ou requis (comme sous-entendu par la section de l'item [[hlisting-proposal-fr#Item_Metadata\|item métadonnées]]). Mon sentiment est que cela devrait être requis

	-- [[DavidJanes]] 2006-11-18		-- [[DavidJanes]] 2006-11-18
Line 29:		Line 28:
	=== '''Faire que les champs Info/Photo soient Optionnels''' ===		=== '''Faire que les champs Info/Photo soient Optionnels''' ===

	WordPress a un ~~Ã©diteur~~ WYSIWYG ~~gÃ©nial~~ qui vous laisse glisser et ~~dÃ©poser~~ des images.		WordPress a un éditeur WYSIWYG génial qui vous laisse glisser et déposer des images.
	Mais la seule identification ~~sÃ©mantique~~ qu'il utilise est l'~~Ã©lÃ©ment~~ HTML <img>.		Mais la seule identification sémantique qu'il utilise est l'élément HTML <img>.
	Ainsi comment obtenons-nous qu'une photo soit ~~identifiÃ©e Ã~~ partir de toutes les images dans la description ?		Ainsi comment obtenons-nous qu'une photo soit identifiée à partir de toutes les images dans la description ?

	1. ~~Ã©diter~~ manuellement le HTML que WordPress ~~crÃ©e~~ et ajouter la classe.		1. éditer manuellement le HTML que WordPress crée et ajouter la classe.
	2. Ajouter une autre IU doublant celle ~~dÃ©jÃ utilisÃ©e~~ par WordPress, sans drag & drop, strictement pour les images ~~dÃ©signÃ©es~~ comme des photos.		2. Ajouter une autre IU doublant celle déjà utilisée par WordPress, sans drag & drop, strictement pour les images désignées comme des photos.
	3. Taguer chaque image unique sous photo.		3. Taguer chaque image unique sous photo.
	4. Faire que le crawler ~~interprÃ¨te~~ chaque image unique comme une photo.		4. Faire que le crawler interprète chaque image unique comme une photo.

	Je ne suis pas ~~sÃ»r~~ que nous voulions pousser la ~~complexitÃ© Ã~~ la ~~frontiÃ¨re~~, c'est comme demander aux gens de ne ~~crÃ©er~~ que des pages XHTML valides et ne pas restituer tout ce qui refuse de valider. Ceci est d'abord pour les humains, en second pour les machines. Si la ~~complexitÃ©~~ a besoin d'exister, ce ne devrait pas l'~~Ãªtre~~ dans les blogs, mais dans les crawlers.		Je ne suis pas sûr que nous voulions pousser la complexité à la frontière, c'est comme demander aux gens de ne créer que des pages XHTML valides et ne pas restituer tout ce qui refuse de valider. Ceci est d'abord pour les humains, en second pour les machines. Si la complexité a besoin d'exister, ce ne devrait pas l'être dans les blogs, mais dans les crawlers.


Line 60:		Line 59:
	This should be called "location", taking a string or an hCard, as in [[hcalendar-fr\|hCalendar]]. [[User:AndyMabbett\|Andy Mabbett]] 09:54, 8 Jan 2008 (PST)		This should be called "location", taking a string or an hCard, as in [[hcalendar-fr\|hCalendar]]. [[User:AndyMabbett\|Andy Mabbett]] 09:54, 8 Jan 2008 (PST)

	== Action par ~~DÃ©faut~~ ==		== Action par Défaut ==
	je pense que c'est un bon format d'avoir un par ~~dÃ©faut~~ pour chaque champ obligatoire, parce quelqu'un lÃ va laisser tomber n'importe quel champ ~~donnÃ©~~ obligatoire dans le champ des microformats. Dans cet esprit, la valeur par ~~dÃ©faut~~ pour l'annonce ~~classÃ©e~~ est l'offre, parce que les annonces "voulu" sont bien << 10% dans le vrai monde. Ce que je ne sais pas est ce que devrait ~~Ãªtre~~ l'action par ~~dÃ©faut~~ ; la plus neutre d'entre elles est ''announce'', ce que j'utilise dans mon parseur.		je pense que c'est un bon format d'avoir un par défaut pour chaque champ obligatoire, parce quelqu'un là va laisser tomber n'importe quel champ donné obligatoire dans le champ des microformats. Dans cet esprit, la valeur par défaut pour l'annonce classée est l'offre, parce que les annonces "voulu" sont bien << 10% dans le vrai monde. Ce que je ne sais pas est ce que devrait être l'action par défaut ; la plus neutre d'entre elles est ''announce'', ce que j'utilise dans mon parseur.

	-- Rohit		-- Rohit
Line 67:		Line 66:
	== Donations ==		== Donations ==

	Vendre et Louer sont des verbes assez ~~Ã©vidents~~ ; que veux dire Trade ~~nÃ©anmoins~~, et Barter. Que penser des dons, comme les donations ou "libre pour recyclage" ? Devrions-nous remplacer Trade et offrir Donate Ã sa place ?		Vendre et Louer sont des verbes assez évidents ; que veux dire Trade néanmoins, et Barter. Que penser des dons, comme les donations ou "libre pour recyclage" ? Devrions-nous remplacer Trade et offrir Donate à sa place ?

	-- Rohit		-- Rohit

	== ~~DÃ©sir~~ d'~~HÃ©riter~~ du Contexte ==		== Désir d'Hériter du Contexte ==

	Quand cela vient au billet de blog, j'aimerais nous avoir adresser ce qui suit :		Quand cela vient au billet de blog, j'aimerais nous avoir adresser ce qui suit :
Line 94:		Line 93:
	== '''Sur hReview''' ==		== '''Sur hReview''' ==

	This draft was heavily influenced by hReview. That's a good thing. We ~~donât~~ want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.		This draft was heavily influenced by hReview. That's a good thing. We don’t want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.

	But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.		But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.
Line 107:		Line 106:
	== '''Nom Voisinage''' ==		== '''Nom Voisinage''' ==

	With the exception of housing, most classified listings ~~donât~~ contain a specific address (e.g., if ~~Iâm~~ selling my couch, you ~~donât~~ need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).		With the exception of housing, most classified listings don’t contain a specific address (e.g., if I’m selling my couch, you don’t need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).

	This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)		This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)
Line 200:		Line 199:
	There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station?		There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station?

	== Que penser de la vente au ~~dÃ©tail~~ ? ==		== Que penser de la vente au détail ? ==

	Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?		Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?

TroccHidro: rotacasitvi

2008-12-19T12:57:47Z

rotacasitvi

← Older revision		Revision as of 12:57, 19 December 2008
Line 1:		Line 1:
	<h1> hlisting-~~réactions~~ </h1>		relbode
			<h1> hlisting-rÃ©actions </h1>
	{{TOC-right}}		{{TOC-right}}
	Ce document est ~~destiné à~~ conserver trace des ~~réactions~~ concernant le [[hlisting-fr\|hListing]], l'un des nombreux [[microformats-fr\|microformats]].		Ce document est destinÃ© Ã conserver trace des rÃ©actions concernant le [[hlisting-fr\|hListing]], l'un des nombreux [[microformats-fr\|microformats]].


Line 7:		Line 8:
	{{issues-format-fr}}		{{issues-format-fr}}

	== ~~Problématiques~~ du ~~Schéma~~ ==		== ProblÃ©matiques du SchÃ©ma ==

	=== Item ===		=== Item ===

	* est-ce que class="item" fait partie de la spec ? Ce n'est pas clair dans la proposition.		* est-ce que class="item" fait partie de la spec ? Ce n'est pas clair dans la proposition.
	* si ce l'est, est-ce optionnel (comme dans le [[hlisting-proposal-fr#~~Schéma~~\|~~schéma~~]]) ou requis (comme sous-entendu par la section de l'item [[hlisting-proposal-fr#Item_Metadata\|item ~~métadonnées~~]]). Mon sentiment est que cela devrait ~~être~~ requis		* si ce l'est, est-ce optionnel (comme dans le [[hlisting-proposal-fr#SchÃ©ma\|schÃ©ma]]) ou requis (comme sous-entendu par la section de l'item [[hlisting-proposal-fr#Item_Metadata\|item mÃ©tadonnÃ©es]]). Mon sentiment est que cela devrait Ãªtre requis

	-- [[DavidJanes]] 2006-11-18		-- [[DavidJanes]] 2006-11-18
Line 28:		Line 29:
	=== '''Faire que les champs Info/Photo soient Optionnels''' ===		=== '''Faire que les champs Info/Photo soient Optionnels''' ===

	WordPress a un ~~éditeur~~ WYSIWYG ~~génial~~ qui vous laisse glisser et ~~déposer~~ des images.		WordPress a un Ã©diteur WYSIWYG gÃ©nial qui vous laisse glisser et dÃ©poser des images.
	Mais la seule identification ~~sémantique~~ qu'il utilise est l'~~élément~~ HTML <img>.		Mais la seule identification sÃ©mantique qu'il utilise est l'Ã©lÃ©ment HTML <img>.
	Ainsi comment obtenons-nous qu'une photo soit ~~identifiée à~~ partir de toutes les images dans la description ?		Ainsi comment obtenons-nous qu'une photo soit identifiÃ©e Ã partir de toutes les images dans la description ?

	1. ~~éditer~~ manuellement le HTML que WordPress ~~crée~~ et ajouter la classe.		1. Ã©diter manuellement le HTML que WordPress crÃ©e et ajouter la classe.
	2. Ajouter une autre IU doublant celle ~~déjà utilisée~~ par WordPress, sans drag & drop, strictement pour les images ~~désignées~~ comme des photos.		2. Ajouter une autre IU doublant celle dÃ©jÃ utilisÃ©e par WordPress, sans drag & drop, strictement pour les images dÃ©signÃ©es comme des photos.
	3. Taguer chaque image unique sous photo.		3. Taguer chaque image unique sous photo.
	4. Faire que le crawler ~~interprète~~ chaque image unique comme une photo.		4. Faire que le crawler interprÃ¨te chaque image unique comme une photo.

	Je ne suis pas ~~sûr~~ que nous voulions pousser la ~~complexité à~~ la ~~frontière~~, c'est comme demander aux gens de ne ~~créer~~ que des pages XHTML valides et ne pas restituer tout ce qui refuse de valider. Ceci est d'abord pour les humains, en second pour les machines. Si la ~~complexité~~ a besoin d'exister, ce ne devrait pas l'~~être~~ dans les blogs, mais dans les crawlers.		Je ne suis pas sÃ»r que nous voulions pousser la complexitÃ© Ã la frontiÃ¨re, c'est comme demander aux gens de ne crÃ©er que des pages XHTML valides et ne pas restituer tout ce qui refuse de valider. Ceci est d'abord pour les humains, en second pour les machines. Si la complexitÃ© a besoin d'exister, ce ne devrait pas l'Ãªtre dans les blogs, mais dans les crawlers.


Line 59:		Line 60:
	This should be called "location", taking a string or an hCard, as in [[hcalendar-fr\|hCalendar]]. [[User:AndyMabbett\|Andy Mabbett]] 09:54, 8 Jan 2008 (PST)		This should be called "location", taking a string or an hCard, as in [[hcalendar-fr\|hCalendar]]. [[User:AndyMabbett\|Andy Mabbett]] 09:54, 8 Jan 2008 (PST)

	== Action par ~~Défaut~~ ==		== Action par DÃ©faut ==
	je pense que c'est un bon format d'avoir un par ~~défaut~~ pour chaque champ obligatoire, parce quelqu'un là va laisser tomber n'importe quel champ ~~donné~~ obligatoire dans le champ des microformats. Dans cet esprit, la valeur par ~~défaut~~ pour l'annonce ~~classée~~ est l'offre, parce que les annonces "voulu" sont bien << 10% dans le vrai monde. Ce que je ne sais pas est ce que devrait ~~être~~ l'action par ~~défaut~~ ; la plus neutre d'entre elles est ''announce'', ce que j'utilise dans mon parseur.		je pense que c'est un bon format d'avoir un par dÃ©faut pour chaque champ obligatoire, parce quelqu'un lÃ va laisser tomber n'importe quel champ donnÃ© obligatoire dans le champ des microformats. Dans cet esprit, la valeur par dÃ©faut pour l'annonce classÃ©e est l'offre, parce que les annonces "voulu" sont bien << 10% dans le vrai monde. Ce que je ne sais pas est ce que devrait Ãªtre l'action par dÃ©faut ; la plus neutre d'entre elles est ''announce'', ce que j'utilise dans mon parseur.

	-- Rohit		-- Rohit
Line 66:		Line 67:
	== Donations ==		== Donations ==

	Vendre et Louer sont des verbes assez ~~évidents~~ ; que veux dire Trade ~~néanmoins~~, et Barter. Que penser des dons, comme les donations ou "libre pour recyclage" ? Devrions-nous remplacer Trade et offrir Donate à sa place ?		Vendre et Louer sont des verbes assez Ã©vidents ; que veux dire Trade nÃ©anmoins, et Barter. Que penser des dons, comme les donations ou "libre pour recyclage" ? Devrions-nous remplacer Trade et offrir Donate Ã sa place ?

	-- Rohit		-- Rohit

	== ~~Désir~~ d'~~Hériter~~ du Contexte ==		== DÃ©sir d'HÃ©riter du Contexte ==

	Quand cela vient au billet de blog, j'aimerais nous avoir adresser ce qui suit :		Quand cela vient au billet de blog, j'aimerais nous avoir adresser ce qui suit :
Line 93:		Line 94:
	== '''Sur hReview''' ==		== '''Sur hReview''' ==

	This draft was heavily influenced by hReview. That's a good thing. We ~~don’t~~ want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.		This draft was heavily influenced by hReview. That's a good thing. We donât want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.

	But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.		But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.
Line 106:		Line 107:
	== '''Nom Voisinage''' ==		== '''Nom Voisinage''' ==

	With the exception of housing, most classified listings ~~don’t~~ contain a specific address (e.g., if ~~I’m~~ selling my couch, you ~~don’t~~ need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).		With the exception of housing, most classified listings donât contain a specific address (e.g., if Iâm selling my couch, you donât need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).

	This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)		This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)
Line 199:		Line 200:
	There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station?		There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station?

	== Que penser de la vente au ~~détail~~ ? ==		== Que penser de la vente au dÃ©tail ? ==

	Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?		Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?

ChristopheDucamp: [fr:sync'd with english version-to be translated]

2008-01-27T07:38:01Z

[fr:sync'd with english version-to be translated]

Show changes

Tantek: Reverted edit of IjdOi7, changed back to last version by ChristopheDucamp

2007-07-14T17:26:11Z

Reverted edit of IjdOi7, changed back to last version by ChristopheDucamp

Show changes

IjdOi7 at 16:59, 14 July 2007

2007-07-14T16:59:50Z

Show changes

ChristopheDucamp: traduction en cours

2006-09-09T14:27:57Z

traduction en cours

New page

== Action par Défaut ==
je pense que c'est un bon format d'avoir un par défaut pour chaque champ obligatoire, parce quelqu'un là va laisser tomber n'importe quel champ donné obligatoire dans le champ des microformats. Dans cet esprit, la valeur par défaut pour l'annonce classée est l'offre, parce que les annonces "voulu" sont bien << 10% dans le vrai monde. Ce que je ne sais pas est ce que devrait être l'action par défaut ; la plus neutre d'entre elles est ''announce'', ce que j'utilise dans mon parseur.

-- Rohit

== Donations ==

Vendre et Louer sont des verbes assez évidents ; que veux dire Trade néanmoins, et Barter. Que penser des dons, comme les donations ou "libre pour recyclage" ? Devrions-nous remplacer Trade et offrir Donate à sa place ?

-- Rohit

== Dérir d'Hériter du Contexte ==

Quand cela vient au billet de blog, j'aimerais nous avoir adresser ce qui suit :

1. '''Less is more'''. Or in reverse, people are lazy, and the less fields they need to fill in order to sell a couch or find a date, the more they'll use the plugin. So I'm trying to visualize how this plays in with the user interface and how we can keep it as simple as possible.

2. '''DRY'''. We want to capture as much information as possible from what is already available in the blog post. We already have summary (title), listing date/time (post date/time), permalink, author information, tags/categories.

3. '''Keep it simple'''. And here I'm talking about setup and being able to extend your blog's functionality without too much fuss. This one is a bit more tricky, so I'll go into details.

WordPress uses templates to render the blog post. The template then calls the WordPress API to render the title, a second call to render the content, and another call to render any additional metadata (e.g.
publish date, categories, author). These separate calls allow people to play with the formatting and apply any styling they like.

The way uPress works, is by processing the blog post before it goes back to the filter, creating the hEvent (to be: hListing) element around it, and adding any relevant fields into the blog post. So what you fill in the form, finds its way to the post content. As a result, setting up the plugin requires two steps: drop it to the plugins directory, and activate.

Unfortunately, I only get to process the content of the post. I can't easily include the title inside the hListing element, or any other metadata about the post, even though I have access to it. If I duplicate that information, the post stops being readable. And to wrap the entire post (not just body) inside a microformat element, I need to tweak the template. Except people use different templates, and I can't tweak all of them.

So the more context we use, the better the plugin becomes.

-- Assaf Arkin

== '''Faire que les champs Info/Photo soient Optionnels''' ==

WordPress a un éditeur WYSIWYG génial qui vous laisse glisser et déposer des images.
Mais la seule identification sémantique qu'il utilise est l'élément HTML <img>.
Ainsi comment obtenons-nous qu'une photo soit identifiée à partir de toutes les images dans la description ?

1. éditer manuellemen le HTML que WordPress crée et ajouter la classe.
2. Ajouter une autre IU doublant celle déjà utilisée par WordPress, sans drag & drop, strictement pour les images désignées comme des photos.
3. Taguer chaque image unique sous photo.
4. Faire que le crawler interprète chaque image unique comme une photo.

Je ne suis pas sûr que nous voulions pousser la complexité à la frontière, c'est comme demander aux gens de ne créer que des pages XHTML valides et ne pas restituer tout ce qui refuse de valider. Ceci est d'abord pour les humains, en second pour les machines. Si la complexité a besoin d'exister, ce ne devrait pas l'être dans les blogs, mais dans les crawlers.

-- Assaf Arkin

== '''Sur hReview''' ==

This draft was heavily influenced by hReview. That's a good thing. We don’t want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.

But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.

We want to appeal to the wide populace of bloggers who just want to get stuff done. Rather than put the burden on millions of bloggers out there, we should place the burden on the few companies developing crawlers.

What would Tantek say? I think he'd ask us to focus on use cases, real examples. I'm presenting one such example. The use case involves a blogger who just wants to sell something on their blog, with the minimum amount of effort and cognitive friction. They want the listing to be discovered, aggregated and searched by others.

-- Assaf Arkin

== '''Nom Voisinage''' ==

With the exception of housing, most classified listings don’t contain a specific address (e.g., if I’m selling my couch, you don’t need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).

This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)

-- Craig Donato & Assaf Arkin

== '''Listing Action, Listing Type, Item Type''' ==

We heavily debated how to classify a listing. Search engines or marketplaces typically need to understand what type of listing it is (e.g., personal ad, house for sale, music) to effectively reference or index a listing.

We initially considered proposing a single category field that contained tags (in addition to the tags field). Not only did this seem duplicative, it also seemed like too much of a good thing. In a previous project, Assaf managed to successfully overload everything into tags (including dates and locations), and run time-based and location-based searches, and ended up concluding it's a bad idea.

We eventually decided to propose the use three parametric field that when used together could define any type of listing independent of the words use to describe. These ended up being: listing-type (are you offering something or looking for something; listing-action (are you trying to sell, rent, or announce something); and item type (what item is referenced by the action such as a job opening, product, housing). By making small modifications to this vocabulary, users can specify an extremely wide range of potential transactions. This seemed more feasible given that the UI used to produce the hListing could abstract some of this from the user (as Assaf demonstrated in his demo plugin).

For example:

{|
!Desired Transaction
!Listing Type
!Listing Action
!Item Type
|-
|Merchandise For Sale
|Offer
|Sell
|Product
|-
|Looking to Buy Merchandise
|Wanted
|Sell
|Product
|-
|Selling Tickets
|Offer
|Sell
|Event
|-
|Apartment For Rent
|Offer
|Rent
|Housing
|-
|Looking for Apartment
|Wanted
|Rent
|Housing
|-
|Room for Rent (Roommate)
|Offer
|Rent
|Housing
|-
|Looking for a Date
|Offer||Wanted
|Announce, Meet
|-
|Job Opening
|Offer
|Announce
|Opening
|-
|Looking for a Job (Resume)
|Wanted
|Announce
|Opening
|-
|Music Lessons
|Offer
|Service
|Business
|-
|Trade Couch for TV
|Offer
|Trade
|Product
|-
|Pet for Adoption
|Offer
|Announce
|Animal?
|}
-- Craig Donato

== Eliminate Item Type ==

Can we eliminate item type and simply use tags? Or perhaps inferred item type from the item info?

== hClassified? ==

There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station?

== Que penser de la vente au détail ? ==

Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?

== Retail ==

Funnily enough, hProduct is always something that I've thought about.

I'd be bold enough to say that it will be one of the main uses of microformats in the future. Imagine the amount of shops, price comparison, product review and many more type of sites. It doesn't have to be for profit, it could just be someones product, on their site, that they are displaying.

I'd be willing to help and continue development of a spec for 'hProduct'.

Adam Craven

== Classe Thumbnail ==
Hello. I'm not sure I understand everything correctly, but from reading the hListing proposal it seems that one should put pictures of the listed subject into the "photo" class. I'm wondering if also we may wish to have a "thumnail" class or perhaps something like "photo-thumbnail" to denote thumbnail images.
-Andrew

== Validateur ==
Perhaps to foster development of this type, someone (who knows a lot more about microformats than I) should put a validator type page out there. I realize that microformats, by their nature are a loose specification (it's not as strict as validating say an XML rss feed). But having something that I can use to at least verify that what I'm coding is actually recognized as an hListing by someone other than myself would be very helpful.
-Andrew