hreview-issues-fr - Revision history

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

2007-06-09T04:59:24Z

Reverted edit of TpwQki, changed back to last version by Tantek

← Older revision		Revision as of 04:59, 9 June 2007
Line 12:		Line 12:
	*# ''Problématique 2 : Voici la seconde problématique que j'ai.''		*# ''Problématique 2 : Voici la seconde problématique que j'ai.''

	== rel=		== rel="self" ==

			2005-01-04 par [[User:DavidJanes\|David Janes]]:

			Atom définit rel="self" [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.2.7 ici]

			: La valeur "self" signifie que l'IRI dans la valeur de l'attribut href identifie une ressource équivalente à l'élément conteneur.

			HTML rel="boomark" [http://www.w3.org/TR/REC-html40/types.html#type-links ici]

			: fait référence à un bookmark. Un bookmark est un lien vers un point d'entrée clé dans un document étendu. L'attribut title peut être utilisé, par exemple, pour étiqueter le bookmark. Remarquez que plusieurs bookmarks peuvent être définis dans chaque document.

			Parce que nous utilisons "bookmark" pour signifier le point d'entrée vers la hReview, le "self" n'est t'il pas redondant ou exagérément subtil ?

			== limite par défaut plus basse ==

			* YYYY-MM-DD????? soulevée par [[User:ScottReynen\|Scott Reynen]]
			*# ''Pourquoi la limite la plus basse 1 quand les [[reviews-formats-fr\|exemples dans le vrai monde]] ont presque tous une limite plus basse de 0 ?''
			# REJETE HYPOTHESE INVALIDE. La plupart des [[review-examples-fr\|exemples dans le vrai monde]] ont une borne de 1, pas de 0.

			== gamme par défaut ==
			* 2006-02-23 soulevée par Andy Mabbett
			*# ''Ce ne sont pas toutes les marques qui donne des ratings "sur cinq". La valeur devrait être un pourcentage. Zéro devrait être permis.''
			# REJETE IGNORES RESEARCH. La plupart des [[review-examples-fr\|exemples du vrai monde]] ont une gamme de notation de 1.0-5.0 et pas un pourcentage. Vous pouvez paramtérer le "best" lié à 100 explicitement, et le "worst" lié à 0 explicitement par la spéc si c'est nécessaire.
			# "most" != "all"; bien sûr, la page que vous citez a des exemples de "1-10" et "0-100%". Je n'ai jamais prétendu que beaucoup d'exemples utilisent des pourcentages, mais suis sûr qu'un mathématicien expliquerait que les valeurs dans la gamme "1-5" peuvent être exprimées sous des pourcentages.
			# REJETE RTFM. La plupart des exmples sont ce sur quoi sont basés les défauts. SVP relisez à la fois la spec et la résolution précédente, 1-10 est permis (vous devez explicitement régler "best" à 10), et ainsi est 0-100 (vous devez explicitement régler "worst" à 0 et "best" à 100).

			== Clarifications sur la Spécification ==

			* 2006-02-01 soulevée par [http://tantek.com Tantek].
			*# ''La spec a besoin de clarifier qu'il n'y a qu'un "item" par "hreview".''
			# ACCEPTEE. Resolu dans hReview 0.3.


			== Multilinguisme ==

			* 2006-03-22 soulevée par Fil
			*# l'auteur de la spec ne peut pas dire ''Pour les critiques anonymes, utilisez "anonymous" (sans guillemets) pour le nom complet de l'auteur.'' parce que ce mot ("anonymous") va apparaître sur la page, et n'est pas multilingue (et même en français, quelqu'un pourrait vouloir utiliser un autre mot, comme "un peureux anonyme")

			== Prix ==

			* 2006-04-04 soulevée par [[User:Evan\|Evan]].
			*# Cela ne semble pas possible de donner un '''price''' approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ''ou'' une '''gamme de prix'''. Les prix devraient presque toujours avoir une balise ''currency'' et un ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. Pour une gamme de prix, ''<nowiki><span class="pricerange"><span class="price"> ... </span> jusqu'à <span class="price"> ... </span></span></nowiki>''.


			== Date and Time ==

			* 2006-08-24 soulevée par [[User:Elias\|Elias Sinderson]]
			*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une [http://www.w3.org/TR/NOTE-datetime note] technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la [http://www.w3.org/TR/html401/types.html#h-6.11 spéc HTML 4.0] utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types [http://www.w3.org/TR/xmlschema-2/#date xsd:date] et [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] sont spécifiés comme étant le format étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
			# REJETE. METHODOLOGIE INCORRECTE. "Oblige les utilisateurs à convertir" ?? Non. Nous optimisons pour les éditeurs (les "utilisateurs" dans ce contexte) plus que pour les programmeurs. Chaque fois que vous vous retrouvez à dire ou même à <em>penser</em> "oblige les utilisateurs", vous pensez probablement sur de mauvaises lignes de raisonnement. En particulier, nous avons déjà pris la décision/résolution de permettre la plus large gamme de valeurs datetime permises par la RFC2445, et avons explicitement inclus quelques raccourcis (par ex. timezone offsets) spécifiquement pour rendre les choses <em>plus faciles</em> pour les <em>utilisateurs</em>.

			==Pages apparentées==
			{{hreview-related-pages-fr}}

TpwQki at 04:56, 9 June 2007

2007-06-09T04:56:34Z

← Older revision		Revision as of 04:56, 9 June 2007
Line 12:		Line 12:
	*# ''Problématique 2 : Voici la seconde problématique que j'ai.''		*# ''Problématique 2 : Voici la seconde problématique que j'ai.''

	== rel=~~"self" ==~~		== rel=

	~~2005-01-04 par [[User:DavidJanes\|David Janes]]:~~

	~~Atom définit rel="self" [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.2.7 ici]~~

	~~: La valeur "self" signifie que l'IRI dans la valeur de l'attribut href identifie une ressource équivalente à l'élément conteneur.~~

	~~HTML rel="boomark" [http://www.w3.org/TR/REC-html40/types.html#type-links ici]~~

	: fait référence à un bookmark. Un bookmark est un lien vers un point d'entrée clé dans un document étendu. L'attribut title peut être utilisé, par exemple, pour étiqueter le bookmark. Remarquez que plusieurs bookmarks peuvent être définis dans chaque document.

	~~Parce que nous utilisons "bookmark" pour signifier le point d'entrée vers la hReview, le "self" n'est t'il pas redondant ou exagérément subtil ?~~

	~~== limite par défaut plus basse ==~~

	* YYYY-MM-DD????? soulevée par [[User:ScottReynen\|Scott Reynen]]
	*# ''Pourquoi la limite la plus basse 1 quand les [[reviews-formats-fr\|exemples dans le vrai monde]] ont presque tous une limite plus basse de 0 ?''
	# REJETE HYPOTHESE INVALIDE. La plupart des [[review-examples-fr\|exemples dans le vrai monde]] ont une borne de 1, pas de 0.

	~~== gamme par défaut ==~~
	* 2006-02-23 soulevée par Andy Mabbett
	*# ''Ce ne sont pas toutes les marques qui donne des ratings "sur cinq". La valeur devrait être un pourcentage. Zéro devrait être permis.''
	# REJETE IGNORES RESEARCH. La plupart des [[review-examples-fr\|exemples du vrai monde]] ont une gamme de notation de 1.0-5.0 et pas un pourcentage. Vous pouvez paramtérer le "best" lié à 100 explicitement, et le "worst" lié à 0 explicitement par la spéc si c'est nécessaire.
	# "most" != "all"; bien sûr, la page que vous citez a des exemples de "1-10" et "0-100%". Je n'ai jamais prétendu que beaucoup d'exemples utilisent des pourcentages, mais suis sûr qu'un mathématicien expliquerait que les valeurs dans la gamme "1-5" peuvent être exprimées sous des pourcentages.
	# REJETE RTFM. La plupart des exmples sont ce sur quoi sont basés les défauts. SVP relisez à la fois la spec et la résolution précédente, 1-10 est permis (vous devez explicitement régler "best" à 10), et ainsi est 0-100 (vous devez explicitement régler "worst" à 0 et "best" à 100).

	~~== Clarifications sur la Spécification ==~~

	* 2006-02-01 soulevée par [http://tantek.com Tantek].
	*# ''La spec a besoin de clarifier qu'il n'y a qu'un "item" par "hreview".''
	# ACCEPTEE. Resolu dans hReview 0.3.


	~~== Multilinguisme ==~~

	* 2006-03-22 soulevée par Fil
	*# l'auteur de la spec ne peut pas dire ''Pour les critiques anonymes, utilisez "anonymous" (sans guillemets) pour le nom complet de l'auteur.'' parce que ce mot ("anonymous") va apparaître sur la page, et n'est pas multilingue (et même en français, quelqu'un pourrait vouloir utiliser un autre mot, comme "un peureux anonyme")

	~~== Prix ==~~

	* 2006-04-04 soulevée par [[User:Evan\|Evan]].
	*# Cela ne semble pas possible de donner un '''price''' approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ''ou'' une '''gamme de prix'''. Les prix devraient presque toujours avoir une balise ''currency'' et un ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. Pour une gamme de prix, ''<nowiki><span class="pricerange"><span class="price"> ... </span> jusqu'à <span class="price"> ... </span></span></nowiki>''.


	~~== Date and Time ==~~

	* 2006-08-24 soulevée par [[User:Elias\|Elias Sinderson]]
	*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une [http://www.w3.org/TR/NOTE-datetime note] technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la [http://www.w3.org/TR/html401/types.html#h-6.11 spéc HTML 4.0] utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types [http://www.w3.org/TR/xmlschema-2/#date xsd:date] et [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] sont spécifiés comme étant le format étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
	# REJETE. METHODOLOGIE INCORRECTE. "Oblige les utilisateurs à convertir" ?? Non. Nous optimisons pour les éditeurs (les "utilisateurs" dans ce contexte) plus que pour les programmeurs. Chaque fois que vous vous retrouvez à dire ou même à <em>penser</em> "oblige les utilisateurs", vous pensez probablement sur de mauvaises lignes de raisonnement. En particulier, nous avons déjà pris la décision/résolution de permettre la plus large gamme de valeurs datetime permises par la RFC2445, et avons explicitement inclus quelques raccourcis (par ex. timezone offsets) spécifiquement pour rendre les choses <em>plus faciles</em> pour les <em>utilisateurs</em>.

	~~==Pages apparentées==~~
	~~{{hreview-related-pages-fr}}~~

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

2007-04-11T02:51:36Z

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

← Older revision		Revision as of 02:51, 11 April 2007
Line 12:		Line 12:
	*# ''Problématique 2 : Voici la seconde problématique que j'ai.''		*# ''Problématique 2 : Voici la seconde problématique que j'ai.''

	== rel=		== rel="self" ==

			2005-01-04 par [[User:DavidJanes\|David Janes]]:

			Atom définit rel="self" [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.2.7 ici]

			: La valeur "self" signifie que l'IRI dans la valeur de l'attribut href identifie une ressource équivalente à l'élément conteneur.

			HTML rel="boomark" [http://www.w3.org/TR/REC-html40/types.html#type-links ici]

			: fait référence à un bookmark. Un bookmark est un lien vers un point d'entrée clé dans un document étendu. L'attribut title peut être utilisé, par exemple, pour étiqueter le bookmark. Remarquez que plusieurs bookmarks peuvent être définis dans chaque document.

			Parce que nous utilisons "bookmark" pour signifier le point d'entrée vers la hReview, le "self" n'est t'il pas redondant ou exagérément subtil ?

			== limite par défaut plus basse ==

			* YYYY-MM-DD????? soulevée par [[User:ScottReynen\|Scott Reynen]]
			*# ''Pourquoi la limite la plus basse 1 quand les [[reviews-formats-fr\|exemples dans le vrai monde]] ont presque tous une limite plus basse de 0 ?''
			# REJETE HYPOTHESE INVALIDE. La plupart des [[review-examples-fr\|exemples dans le vrai monde]] ont une borne de 1, pas de 0.

			== gamme par défaut ==
			* 2006-02-23 soulevée par Andy Mabbett
			*# ''Ce ne sont pas toutes les marques qui donne des ratings "sur cinq". La valeur devrait être un pourcentage. Zéro devrait être permis.''
			# REJETE IGNORES RESEARCH. La plupart des [[review-examples-fr\|exemples du vrai monde]] ont une gamme de notation de 1.0-5.0 et pas un pourcentage. Vous pouvez paramtérer le "best" lié à 100 explicitement, et le "worst" lié à 0 explicitement par la spéc si c'est nécessaire.
			# "most" != "all"; bien sûr, la page que vous citez a des exemples de "1-10" et "0-100%". Je n'ai jamais prétendu que beaucoup d'exemples utilisent des pourcentages, mais suis sûr qu'un mathématicien expliquerait que les valeurs dans la gamme "1-5" peuvent être exprimées sous des pourcentages.
			# REJETE RTFM. La plupart des exmples sont ce sur quoi sont basés les défauts. SVP relisez à la fois la spec et la résolution précédente, 1-10 est permis (vous devez explicitement régler "best" à 10), et ainsi est 0-100 (vous devez explicitement régler "worst" à 0 et "best" à 100).

			== Clarifications sur la Spécification ==

			* 2006-02-01 soulevée par [http://tantek.com Tantek].
			*# ''La spec a besoin de clarifier qu'il n'y a qu'un "item" par "hreview".''
			# ACCEPTEE. Resolu dans hReview 0.3.


			== Multilinguisme ==

			* 2006-03-22 soulevée par Fil
			*# l'auteur de la spec ne peut pas dire ''Pour les critiques anonymes, utilisez "anonymous" (sans guillemets) pour le nom complet de l'auteur.'' parce que ce mot ("anonymous") va apparaître sur la page, et n'est pas multilingue (et même en français, quelqu'un pourrait vouloir utiliser un autre mot, comme "un peureux anonyme")

			== Prix ==

			* 2006-04-04 soulevée par [[User:Evan\|Evan]].
			*# Cela ne semble pas possible de donner un '''price''' approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ''ou'' une '''gamme de prix'''. Les prix devraient presque toujours avoir une balise ''currency'' et un ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. Pour une gamme de prix, ''<nowiki><span class="pricerange"><span class="price"> ... </span> jusqu'à <span class="price"> ... </span></span></nowiki>''.


			== Date and Time ==

			* 2006-08-24 soulevée par [[User:Elias\|Elias Sinderson]]
			*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une [http://www.w3.org/TR/NOTE-datetime note] technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la [http://www.w3.org/TR/html401/types.html#h-6.11 spéc HTML 4.0] utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types [http://www.w3.org/TR/xmlschema-2/#date xsd:date] et [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] sont spécifiés comme étant le format étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
			# REJETE. METHODOLOGIE INCORRECTE. "Oblige les utilisateurs à convertir" ?? Non. Nous optimisons pour les éditeurs (les "utilisateurs" dans ce contexte) plus que pour les programmeurs. Chaque fois que vous vous retrouvez à dire ou même à <em>penser</em> "oblige les utilisateurs", vous pensez probablement sur de mauvaises lignes de raisonnement. En particulier, nous avons déjà pris la décision/résolution de permettre la plus large gamme de valeurs datetime permises par la RFC2445, et avons explicitement inclus quelques raccourcis (par ex. timezone offsets) spécifiquement pour rendre les choses <em>plus faciles</em> pour les <em>utilisateurs</em>.

			==Pages apparentées==
			{{hreview-related-pages-fr}}

CsuWt2 at 02:05, 11 April 2007

2007-04-11T02:05:51Z

← Older revision		Revision as of 02:05, 11 April 2007
Line 12:		Line 12:
	*# ''Problématique 2 : Voici la seconde problématique que j'ai.''		*# ''Problématique 2 : Voici la seconde problématique que j'ai.''

	== rel=~~"self" ==~~		== rel=

	~~2005-01-04 par [[User:DavidJanes\|David Janes]]:~~

	~~Atom définit rel="self" [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.2.7 ici]~~

	~~: La valeur "self" signifie que l'IRI dans la valeur de l'attribut href identifie une ressource équivalente à l'élément conteneur.~~

	~~HTML rel="boomark" [http://www.w3.org/TR/REC-html40/types.html#type-links ici]~~

	: fait référence à un bookmark. Un bookmark est un lien vers un point d'entrée clé dans un document étendu. L'attribut title peut être utilisé, par exemple, pour étiqueter le bookmark. Remarquez que plusieurs bookmarks peuvent être définis dans chaque document.

	~~Parce que nous utilisons "bookmark" pour signifier le point d'entrée vers la hReview, le "self" n'est t'il pas redondant ou exagérément subtil ?~~

	~~== limite par défaut plus basse ==~~

	* YYYY-MM-DD????? soulevée par [[User:ScottReynen\|Scott Reynen]]
	*# ''Pourquoi la limite la plus basse 1 quand les [[reviews-formats-fr\|exemples dans le vrai monde]] ont presque tous une limite plus basse de 0 ?''
	# REJETE HYPOTHESE INVALIDE. La plupart des [[review-examples-fr\|exemples dans le vrai monde]] ont une borne de 1, pas de 0.

	~~== gamme par défaut ==~~
	* 2006-02-23 soulevée par Andy Mabbett
	*# ''Ce ne sont pas toutes les marques qui donne des ratings "sur cinq". La valeur devrait être un pourcentage. Zéro devrait être permis.''
	# REJETE IGNORES RESEARCH. La plupart des [[review-examples-fr\|exemples du vrai monde]] ont une gamme de notation de 1.0-5.0 et pas un pourcentage. Vous pouvez paramtérer le "best" lié à 100 explicitement, et le "worst" lié à 0 explicitement par la spéc si c'est nécessaire.
	# "most" != "all"; bien sûr, la page que vous citez a des exemples de "1-10" et "0-100%". Je n'ai jamais prétendu que beaucoup d'exemples utilisent des pourcentages, mais suis sûr qu'un mathématicien expliquerait que les valeurs dans la gamme "1-5" peuvent être exprimées sous des pourcentages.
	# REJETE RTFM. La plupart des exmples sont ce sur quoi sont basés les défauts. SVP relisez à la fois la spec et la résolution précédente, 1-10 est permis (vous devez explicitement régler "best" à 10), et ainsi est 0-100 (vous devez explicitement régler "worst" à 0 et "best" à 100).

	~~== Clarifications sur la Spécification ==~~

	* 2006-02-01 soulevée par [http://tantek.com Tantek].
	*# ''La spec a besoin de clarifier qu'il n'y a qu'un "item" par "hreview".''
	# ACCEPTEE. Resolu dans hReview 0.3.


	~~== Multilinguisme ==~~

	* 2006-03-22 soulevée par Fil
	*# l'auteur de la spec ne peut pas dire ''Pour les critiques anonymes, utilisez "anonymous" (sans guillemets) pour le nom complet de l'auteur.'' parce que ce mot ("anonymous") va apparaître sur la page, et n'est pas multilingue (et même en français, quelqu'un pourrait vouloir utiliser un autre mot, comme "un peureux anonyme")

	~~== Prix ==~~

	* 2006-04-04 soulevée par [[User:Evan\|Evan]].
	*# Cela ne semble pas possible de donner un '''price''' approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ''ou'' une '''gamme de prix'''. Les prix devraient presque toujours avoir une balise ''currency'' et un ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. Pour une gamme de prix, ''<nowiki><span class="pricerange"><span class="price"> ... </span> jusqu'à <span class="price"> ... </span></span></nowiki>''.


	~~== Date and Time ==~~

	* 2006-08-24 soulevée par [[User:Elias\|Elias Sinderson]]
	*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une [http://www.w3.org/TR/NOTE-datetime note] technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la [http://www.w3.org/TR/html401/types.html#h-6.11 spéc HTML 4.0] utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types [http://www.w3.org/TR/xmlschema-2/#date xsd:date] et [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] sont spécifiés comme étant le format étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
	# REJETE. METHODOLOGIE INCORRECTE. "Oblige les utilisateurs à convertir" ?? Non. Nous optimisons pour les éditeurs (les "utilisateurs" dans ce contexte) plus que pour les programmeurs. Chaque fois que vous vous retrouvez à dire ou même à <em>penser</em> "oblige les utilisateurs", vous pensez probablement sur de mauvaises lignes de raisonnement. En particulier, nous avons déjà pris la décision/résolution de permettre la plus large gamme de valeurs datetime permises par la RFC2445, et avons explicitement inclus quelques raccourcis (par ex. timezone offsets) spécifiquement pour rendre les choses <em>plus faciles</em> pour les <em>utilisateurs</em>.

	~~==Pages apparentées==~~
	~~{{hreview-related-pages-fr}}~~

ChristopheDucamp at 23:16, 26 December 2006

2006-12-26T23:16:12Z

← Older revision		Revision as of 23:16, 26 December 2006
Line 60:		Line 60:

	* 2006-08-24 soulevée par [[User:Elias\|Elias Sinderson]]		* 2006-08-24 soulevée par [[User:Elias\|Elias Sinderson]]
	*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). ~~Although~~ ISO 8601 ~~allows both basic~~ (sans ~~delimiters~~) ~~and extended~~ formats, ~~the extended~~ format (~~where hyphens and~~ colons ~~are explicitly added~~) ~~is broadly preferred for the~~ web. ~~While~~ RFC 2445 ~~specifies that the basic form be used in in~~ iCalendar date / time ~~fields~~, ~~the~~ W3C ~~has published~~ a ~~technical~~ [http://www.w3.org/TR/NOTE-datetime note] (~~submitted by~~ Reuters), ~~which recommends that the extended~~ (~~delimited~~) ~~format be used, and the~~ [http://www.w3.org/TR/html401/types.html#h-6.11 HTML 4.0 ~~spec~~] ~~uses the extended~~ format. ~~Further~~, RFC 3339 ~~defines a~~ ISO 8601 ~~profile for~~ dates ~~and~~ time ~~representations on the~~ internet ~~that future specs SHOULD use~~; ~~recommending a fully delimited representation~~ (~~see~~ sec. 5.6). ~~Lastly~~, ~~it should be noted that the~~ [http://www.w3.org/TR/xmlschema-2/#date xsd:date] ~~and~~ [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] ~~types are specified as being the~~ ISO 8601 ~~extended format~~. So, ~~given that~~ hCalendar ~~is based on~~ iCalendar, ~~it is understandable that it allows both~~ formats, ~~however this is clearly a case in which it would be very reasonable to require users to upconvert the~~ format ~~into the least ambiguous and most easily parsed~~ / ~~validated representation~~. ~~Think of the children~~.		*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Bien qu'ISO 8601 permette à la fois des formats basiques (sans délimiteurs) et des formats étendus, le format étendu est largement préféré (là où les traits d'unions et les 'colons' sont explicitement ajoutés) pour le web. Alors que la RFC 2445 spécifie que le format basique soit utilisé dans les champs iCalendar date / time, le W3C a publié une [http://www.w3.org/TR/NOTE-datetime note] technique (soumise par Reuters), qui recommande que le format étendu (délimité) soit utilisé et la [http://www.w3.org/TR/html401/types.html#h-6.11 spéc HTML 4.0] utilise le format étendu. En outre, la RFC 3339 définit un profil ISO 8601 pour les représentations des dates et time sur l'internet que les spécifications futures DEVRAIENT utiliser ; recommandant une représentation complètement délimitée (voir sec. 5.6). Pour finir, il devrait être noté que les types [http://www.w3.org/TR/xmlschema-2/#date xsd:date] et [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] sont spécifiés comme étant le format étendu ISO 8601. Par conséquent, compte tenu du fait que hCalendar soit basé sur iCalendar, il est compréhensible que cela permette les deux formats, néanmoins c'est clairement un cas dans lequel il serait vraiment raisonnable de convertir d'obliger les utilisateurs à convertir vers le haut le format vers la représentation la moins ambigue et la plus facilement parsée/validée. Pensez à l'enfant.
	# REJETE. METHODOLOGIE INCORRECTE. "~~Require users to upconvert~~"?? No. ~~We optimize for publishers~~ (~~the~~ "~~users~~" ~~in this context~~) ~~more than developers~~. ~~Whenever you find yourself saying or even~~ <em>~~thinking~~</em> "~~require users~~", ~~you're probably thinking along the wrong lines of reasoning~~. ~~In particular we have already made the decision~~/~~resolution to permit the broader range of~~ datetime ~~values permitted by~~ RFC2445, ~~and explicitly included some shortcuts~~ (~~e.g~~. timezone offsets) ~~specifically to make things~~ <em>~~easier~~</em> ~~for~~ <em>~~users~~</em>.		# REJETE. METHODOLOGIE INCORRECTE. "Oblige les utilisateurs à convertir" ?? Non. Nous optimisons pour les éditeurs (les "utilisateurs" dans ce contexte) plus que pour les programmeurs. Chaque fois que vous vous retrouvez à dire ou même à <em>penser</em> "oblige les utilisateurs", vous pensez probablement sur de mauvaises lignes de raisonnement. En particulier, nous avons déjà pris la décision/résolution de permettre la plus large gamme de valeurs datetime permises par la RFC2445, et avons explicitement inclus quelques raccourcis (par ex. timezone offsets) spécifiquement pour rendre les choses <em>plus faciles</em> pour les <em>utilisateurs</em>.

	==Pages apparentées==		==Pages apparentées==
	{{hreview-related-pages-fr}}		{{hreview-related-pages-fr}}

ChristopheDucamp at 23:09, 26 December 2006

2006-12-26T23:09:53Z

← Older revision		Revision as of 23:09, 26 December 2006
Line 3:		Line 3:
	Voici des problématiques soulevées à l'extérieur à propos de [[hreview-fr\|hReview]] ayant largement différents degrés de mérite. De ce fait quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont soulevées à nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des changements ou des explications améliorées dans la spec. Les problématiques proposées peuvent (et le pourront probablement) être éditées et récrites pour une meilleure concision, apporter clarté, calme, rationalité et autant que possible sous un point de vue neutre. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]		Voici des problématiques soulevées à l'extérieur à propos de [[hreview-fr\|hReview]] ayant largement différents degrés de mérite. De ce fait quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont soulevées à nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des changements ou des explications améliorées dans la spec. Les problématiques proposées peuvent (et le pourront probablement) être éditées et récrites pour une meilleure concision, apporter clarté, calme, rationalité et autant que possible sous un point de vue neutre. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]

	Voir les [[hcalendar-issues-fr\|problématiques hcalendar]] et les [[hcard-issues\|problématiques hcard]] apparentées.		Voir les [[hcalendar-issues-fr\|problématiques hcalendar]] et les [[hcard-issues-fr\|problématiques hcard]] apparentées.

	== Gabarit ==		== Gabarit ==
Line 34:		Line 34:
	== gamme par défaut ==		== gamme par défaut ==
	* 2006-02-23 soulevée par Andy Mabbett		* 2006-02-23 soulevée par Andy Mabbett
	*# ''~~Not all marks give~~ ratings "~~out of five~~". ~~The value should be a percentage~~. ~~Zero should be allowed~~.''		*# ''Ce ne sont pas toutes les marques qui donne des ratings "sur cinq". La valeur devrait être un pourcentage. Zéro devrait être permis.''
	# REJETE IGNORES RESEARCH. ~~Most~~ [[review-examples\|~~real-world examples~~]] ~~have a range of~~ 1.0-5.0 ~~not a percentage~~. ~~You may set the~~ "best" ~~bound to~~ 100 ~~explicitly~~, ~~and the~~ "worst" ~~bound to~~ 0 ~~explicitly per the spec if necessary~~.		# REJETE IGNORES RESEARCH. La plupart des [[review-examples-fr\|exemples du vrai monde]] ont une gamme de notation de 1.0-5.0 et pas un pourcentage. Vous pouvez paramtérer le "best" lié à 100 explicitement, et le "worst" lié à 0 explicitement par la spéc si c'est nécessaire.
	# "most" != "all"; ~~indeed~~, ~~the~~ page ~~you cite has examples of~~ "1-10" ~~and~~ "0-100%". ~~I never claimed that many examples use percentages~~, ~~but I~~'~~m sure a mathematician would explain that values in the range~~ "1-5" ~~may be expressed as percentages~~.		# "most" != "all"; bien sûr, la page que vous citez a des exemples de "1-10" et "0-100%". Je n'ai jamais prétendu que beaucoup d'exemples utilisent des pourcentages, mais suis sûr qu'un mathématicien expliquerait que les valeurs dans la gamme "1-5" peuvent être exprimées sous des pourcentages.
	# REJETE RTFM. ~~Most examples are what the defaults are based on~~. ~~Please re-read both the~~ spec ~~and the previous resolution~~, 1-10 ~~is allowed~~ (~~you have to explicitly set~~ "best" to 10), ~~and so is~~ 0-100 (~~you have to explicitly set~~ "worst" to 0 ~~and~~ "best" to 100).		# REJETE RTFM. La plupart des exmples sont ce sur quoi sont basés les défauts. SVP relisez à la fois la spec et la résolution précédente, 1-10 est permis (vous devez explicitement régler "best" à 10), et ainsi est 0-100 (vous devez explicitement régler "worst" à 0 et "best" à 100).

	== Clarifications sur la Spécification ==		== Clarifications sur la Spécification ==

	* 2006-02-01 soulevée par [http://tantek.com Tantek].		* 2006-02-01 soulevée par [http://tantek.com Tantek].
	*# ''~~The~~ spec ~~needs to clarify that there is only one~~ "item" ~~per~~ "hreview".''		*# ''La spec a besoin de clarifier qu'il n'y a qu'un "item" par "hreview".''
	# ACCEPTEE. ~~Resolved in~~ hReview 0.3.		# ACCEPTEE. Resolu dans hReview 0.3.

ChristopheDucamp at 23:03, 26 December 2006

2006-12-26T23:03:19Z

← Older revision		Revision as of 23:03, 26 December 2006
Line 55:		Line 55:
	* 2006-04-04 soulevée par [[User:Evan\|Evan]].		* 2006-04-04 soulevée par [[User:Evan\|Evan]].
	*# Cela ne semble pas possible de donner un '''price''' approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ''ou'' une '''gamme de prix'''. Les prix devraient presque toujours avoir une balise ''currency'' et un ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. Pour une gamme de prix, ''<nowiki><span class="pricerange"><span class="price"> ... </span> jusqu'à <span class="price"> ... </span></span></nowiki>''.		*# Cela ne semble pas possible de donner un '''price''' approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ''ou'' une '''gamme de prix'''. Les prix devraient presque toujours avoir une balise ''currency'' et un ''amount''. Suggestion: ''<nowiki><span class="price"><abbr class="currency" title="Canadian dollars">$</abbr><span class="amount">10.99</span></span></nowiki>''. Pour une gamme de prix, ''<nowiki><span class="pricerange"><span class="price"> ... </span> jusqu'à <span class="price"> ... </span></span></nowiki>''.


			== Date and Time ==

			* 2006-08-24 soulevée par [[User:Elias\|Elias Sinderson]]
			*# ''Problématique 1 : (copiée à partir de la page hcalendar-issues-fr, parce que cela s'applique tout aussi bien à hReview). Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical [http://www.w3.org/TR/NOTE-datetime note] (submitted by Reuters), which recommends that the extended (delimited) format be used, and the [http://www.w3.org/TR/html401/types.html#h-6.11 HTML 4.0 spec] uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the [http://www.w3.org/TR/xmlschema-2/#date xsd:date] and [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed / validated representation. Think of the children.
			# REJETE. METHODOLOGIE INCORRECTE. "Require users to upconvert"?? No. We optimize for publishers (the "users" in this context) more than developers. Whenever you find yourself saying or even <em>thinking</em> "require users", you're probably thinking along the wrong lines of reasoning. In particular we have already made the decision/resolution to permit the broader range of datetime values permitted by RFC2445, and explicitly included some shortcuts (e.g. timezone offsets) specifically to make things <em>easier</em> for <em>users</em>.

			==Pages apparentées==
			{{hreview-related-pages-fr}}

ChristopheDucamp: [fr: translation]

2006-07-22T07:34:47Z

[fr: translation]

New page

= Problématiques hReview =

Voici des problématiques soulevées à l'extérieur à propos de [[hreview-fr|hReview]] ayant largement différents degrés de mérite. De ce fait quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici si elles sont soulevées à nouveau), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des changements ou des explications améliorées dans la spec. Les problématiques proposées peuvent (et le pourront probablement) être éditées et récrites pour une meilleure concision, apporter clarté, calme, rationalité et autant que possible sous un point de vue neutre. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]

Voir les [[hcalendar-issues-fr|problématiques hcalendar]] et les [[hcard-issues|problématiques hcard]] apparentées.

== Gabarit ==

SVP utilisez ce format (copiez et collez cela à la fin de la liste pour ajouter vos problématiques) :
* YYYY-MM-DD soulevée par [http://votrepagepersonnelle.exemple.com VOTRENOM].
*# ''Problématique 1 : Voici la première problématique que j'ai.''
*# ''Problématique 2 : Voici la seconde problématique que j'ai.''

== rel="self" ==

2005-01-04 par [[User:DavidJanes|David Janes]]:

Atom définit rel="self" [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.2.7 ici]

: La valeur "self" signifie que l'IRI dans la valeur de l'attribut href identifie une ressource équivalente à l'élément conteneur.

HTML rel="boomark" [http://www.w3.org/TR/REC-html40/types.html#type-links ici]

: fait référence à un bookmark. Un bookmark est un lien vers un point d'entrée clé dans un document étendu. L'attribut title peut être utilisé, par exemple, pour étiqueter le bookmark. Remarquez que plusieurs bookmarks peuvent être définis dans chaque document.

Parce que nous utilisons "bookmark" pour signifier le point d'entrée vers la hReview, le "self" n'est t'il pas redondant ou exagérément subtil ?

== limite par défaut plus basse ==

* YYYY-MM-DD????? soulevée par [[User:ScottReynen|Scott Reynen]]
*# ''Pourquoi la limite la plus basse 1 quand les [[reviews-formats-fr|exemples dans le vrai monde]] ont presque tous une limite plus basse de 0 ?''
*#* REJETE HYPOTHESE INVALIDE. La plupart des [[review-examples-fr|exemples dans le vrai monde]] ont une borne de 1, pas de 0.

== gamme par défaut ==
* 2006-02-23 soulevée par Andy Mabbett
*# ''Not all marks give ratings "out of five". The value should be a percentage. Zero should be allowed.''
*#* REJETE IGNORES RESEARCH. Most [[review-examples|real-world examples]] have a range of 1.0-5.0 not a percentage. You may set the "best" bound to 100 explicitly, and the "worst" bound to 0 explicitly per the spec if necessary.
*#* "most" != "all"; indeed, the page you cite has examples of "1-10" and "0-100%". I never claimed that many examples use percentages, but I'm sure a mathematician would explain that values in the range "1-5" may be expressed as percentages.
*#* REJETE RTFM. Most examples are what the defaults are based on. Please re-read both the spec and the previous resolution, 1-10 is allowed (you have to explicitly set "best" to 10), and so is 0-100 (you have to explicitly set "worst" to 0 and "best" to 100).

== Clarifications sur la Spécification ==

* 2006-02-01 soulevée par [http://tantek.com Tantek].
*# ''The spec needs to clarify that there is only one "item" per "hreview".''
*#* ACCEPTEE. Resolved in hReview 0.3.

== Multilinguisme ==

* 2006-03-22 soulevée par Fil
*# l'auteur de la spec ne peut pas dire ''Pour les critiques anonymes, utilisez "anonymous" (sans guillemets) pour le nom complet de l'auteur.'' parce que ce mot ("anonymous") va apparaître sur la page, et n'est pas multilingue (et même en français, quelqu'un pourrait vouloir utiliser un autre mot, comme "un peureux anonyme")

== Prix ==

* 2006-04-04 soulevée par [[User:Evan|Evan]].
*# Cela ne semble pas possible de donner un '''price''' approximatif ou absolu du produit ou service en question. Exemples : pour un bout de logiciel, le prix moyen d'une entrée, ''ou'' une '''gamme de prix'''. Les prix devraient presque toujours avoir une balise ''currency'' et un ''amount''. Suggestion: ''<nowiki><abbr class="currency" title="Canadian dollars">$</abbr>10.99</nowiki>''. Pour une gamme de prix, ''<nowiki> ... jusqu'à ... </nowiki>''.