hcalendar-issues-fr - Revision history

RyanKing: Reverted edits by LivirIcnoc (Talk) to last version by Brian

2009-01-08T20:05:41Z

Reverted edits by LivirIcnoc (Talk) to last version by Brian

Show changes

LivirIcnoc: http://huruple.qsh.eu/20081225-prince-the-most.htm

2009-01-08T13:44:28Z

http://huruple.qsh.eu/20081225-prince-the-most.htm

Show changes

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

2008-12-16T19:31:48Z

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

Show changes

LivirIcnoc: lic4torace

2008-12-16T17:49:57Z

lic4torace

Show changes

ChristopheDucamp: page to be sync'd with original - in progress

2007-07-02T15:06:56Z

page to be sync'd with original - in progress

Show changes

Brian: Reverted edit of CwlP8v, changed back to last version by ChristopheDucamp

2007-06-13T17:35:24Z

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

← Older revision		Revision as of 17:35, 13 June 2007
Line 143:		Line 143:

	* 2005-07-11 soulevée par Kragen		* 2005-07-11 soulevée par Kragen
	*# ''The specification of class="url" as		*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk-fr\|xFolk]].''
			# REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

			* 2005-06-21 raised by Hixie
			*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?

			# ACCEPTEE. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing-fr]] that documents precisely how user agents are to parse [[hcalendar-fr\|hCalendar]] markup.

			* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
			*# ''There is no copyright statement and no patent statement.''
			# ACCEPTEE. I have updated [[hcalendar-fr\|hCalendar]] (and [[hcard-fr\|hCard]], and all other MicroFormats) with a standard copyright statement and patent statement.

			* 2005-02-18 soulevée par Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
			*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
			# REJETEE (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
			*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
			# REJETEE (out of scope). Extension properties are outside the current scope of hCalendar.
			*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
			# REJETEE (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
			*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
			# REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
			*# ''There are styling and tooltip issues that are unresolved.''
			# REJETEE (empty statements). Voir [[hcalendar-faq-fr\|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
			*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
			# REJETEE (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
			*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
			# ACCEPTEE-PARTIELLEMENT. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar-fr\|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
			# ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats-fr\|microformats]] specifications in general? (If not, why not?)''
			#* ACCEPTEE. Yes, all [[microformats-fr\|microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
			#** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
			#*** ACCEPTEE. voir [[profile-uris]] ; ceci est une migration à partir de la liste [[to-do]] de Tantek, pour que les deux puissent fournir des probils d 'auteurs amateurs et d'URLs (probablement sur gmpg.org) pour ces profils sur hCalenar.
			* {{OpenIssue-fr}} 2006-04-10 raised by [[User:ScottReynen\|Scott Reynen]].
			*# ''Quand quelqu'un cherche des pages [[hcalendar-fr\|hCalendar]], on ne voit pas de collection de publication du vrai monde de données événements ni de discussion des propriétés implicites par de tels exemples, je pense que c'est bien plus facile d'inférer que les microformats proviennent d'autres formats plus que des comportements véritables. Il n'y a rien dans le [[process-fr\|processus]] ni dans les pages hCalendar expliquant ce décalage. J'argumenterais qu'il devrait y avoir une explication, probablement dans les deux lieux.''
			* {{OpenIssue-fr}} 2006-04-13 soulevée par Tantek
			*# ''Besoin d'ajouter une section sur "Exceptions de Propriétés" comme dans [[hcard-fr\|hCard]] pour documenter comment publier / gérer la propriété '''METHOD''' et potentiellement d'autres. Par ex, généralement les auteurs peuvent omettre la propriété METHOD, néanmoins les convertisseurs dont la fonction est de convertir [[hcalendar-fr\|hCalendar]] vers iCalendar pour la consommation / abonnnement par un agrégateur de calendrier, devrait probablement insérer un '''METHOD:PUBLISH''' par défaut sur l'objet '''VCALENDAR''' dans le flux résultant .ics.''


			== Pages en rapport ==
			{{hcalendar-related-pages-fr}}

CwlP8v at 17:32, 13 June 2007

2007-06-13T17:32:55Z

← Older revision		Revision as of 17:32, 13 June 2007
Line 143:		Line 143:

	* 2005-07-11 soulevée par Kragen		* 2005-07-11 soulevée par Kragen
	*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk-fr\|xFolk]].''		*# ''The specification of class="url" as
	# REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

	* 2005-06-21 raised by Hixie
	*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?

	# ACCEPTEE. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing-fr]] that documents precisely how user agents are to parse [[hcalendar-fr\|hCalendar]] markup.

	* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
	*# ''There is no copyright statement and no patent statement.''
	# ACCEPTEE. I have updated [[hcalendar-fr\|hCalendar]] (and [[hcard-fr\|hCard]], and all other MicroFormats) with a standard copyright statement and patent statement.

	* 2005-02-18 soulevée par Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
	*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
	# REJETEE (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
	*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
	# REJETEE (out of scope). Extension properties are outside the current scope of hCalendar.
	*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
	# REJETEE (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
	*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
	# REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
	*# ''There are styling and tooltip issues that are unresolved.''
	# REJETEE (empty statements). Voir [[hcalendar-faq-fr\|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
	*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
	# REJETEE (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
	*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
	# ACCEPTEE-PARTIELLEMENT. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar-fr\|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
	# ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats-fr\|microformats]] specifications in general? (If not, why not?)''
	#* ACCEPTEE. Yes, all [[microformats-fr\|microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
	#** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
	#*** ACCEPTEE. voir [[profile-uris]] ; ceci est une migration à partir de la liste [[to-do]] de Tantek, pour que les deux puissent fournir des probils d 'auteurs amateurs et d'URLs (probablement sur gmpg.org) pour ces profils sur hCalenar.
	* {{OpenIssue-fr}} 2006-04-10 raised by [[User:ScottReynen\|Scott Reynen]].
	*# ''Quand quelqu'un cherche des pages [[hcalendar-fr\|hCalendar]], on ne voit pas de collection de publication du vrai monde de données événements ni de discussion des propriétés implicites par de tels exemples, je pense que c'est bien plus facile d'inférer que les microformats proviennent d'autres formats plus que des comportements véritables. Il n'y a rien dans le [[process-fr\|processus]] ni dans les pages hCalendar expliquant ce décalage. J'argumenterais qu'il devrait y avoir une explication, probablement dans les deux lieux.''
	* {{OpenIssue-fr}} 2006-04-13 soulevée par Tantek
	*# ''Besoin d'ajouter une section sur "Exceptions de Propriétés" comme dans [[hcard-fr\|hCard]] pour documenter comment publier / gérer la propriété '''METHOD''' et potentiellement d'autres. Par ex, généralement les auteurs peuvent omettre la propriété METHOD, néanmoins les convertisseurs dont la fonction est de convertir [[hcalendar-fr\|hCalendar]] vers iCalendar pour la consommation / abonnnement par un agrégateur de calendrier, devrait probablement insérer un '''METHOD:PUBLISH''' par défaut sur l'objet '''VCALENDAR''' dans le flux résultant .ics.''


	~~== Pages en rapport ==~~
	~~{{hcalendar-related-pages-fr}}~~

ChristopheDucamp at 22:48, 14 April 2007

2007-04-14T22:48:53Z

← Older revision		Revision as of 22:48, 14 April 2007
Line 18:		Line 18:

	Et ajoutez de nouvelles problématiques '''en haut''' de la liste :		Et ajoutez de nouvelles problématiques '''en haut''' de la liste :
			* {{OpenIssue-fr}} 2007-01-20 soulevée par [[User:AndyMabbett\|Andy Mabbett]]
			*# Là où <code>DTEND</code> est une date, et non une date-time, il est requis que ce soit le jour après la fin de l'événement, par conséquent : <code><nowiki>
			<abbr class="dtend" title="2007-04-30">29 avril 2007</abbr></nowiki></code>. Néanmoins, "29 Avril 2007" n'est '''''pas''''' une abréviation de 2007-04-30 ; c'est une abréviation de 2007-04-29. Le balisage comme montré est sémantiquement incorrect et sujet probablement à problèmes pour les utilisateurs ou agents utilisateurs qui isent l'attribut 'title', et non la valeur texte, de l'élément <code>abbr</code>.
	* {{OpenIssue-fr}} 2007-01-07 soulevée par [[User:Webf\|Webf]]		* {{OpenIssue-fr}} 2007-01-07 soulevée par [[User:Webf\|Webf]]
	*# A la recherche d'un mécanisme pour spécifier un dtstart sans utiliser <nowiki><abbr></nowiki>. Ce serait utilisé où il existe un certain nombre d'événements (comme dans les [http://www.webfeet.org/events.html listes d'événéments de Webfeet]) où vous ne voulez pas avoir la date visible répétée.		*# A la recherche d'un mécanisme pour spécifier un dtstart sans utiliser <nowiki><abbr></nowiki>. Ce serait utilisé où il existe un certain nombre d'événements (comme dans les [http://www.webfeet.org/events.html listes d'événéments de Webfeet]) où vous ne voulez pas avoir la date visible répétée.

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

2007-04-11T18:03:11Z

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

← Older revision		Revision as of 18:03, 11 April 2007
Line 141:		Line 141:

	* 2005-07-11 soulevée par Kragen		* 2005-07-11 soulevée par Kragen
	*# ''The specification of class="url" as		*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk-fr\|xFolk]].''
			# REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

			* 2005-06-21 raised by Hixie
			*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?

			# ACCEPTEE. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing-fr]] that documents precisely how user agents are to parse [[hcalendar-fr\|hCalendar]] markup.

			* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
			*# ''There is no copyright statement and no patent statement.''
			# ACCEPTEE. I have updated [[hcalendar-fr\|hCalendar]] (and [[hcard-fr\|hCard]], and all other MicroFormats) with a standard copyright statement and patent statement.

			* 2005-02-18 soulevée par Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
			*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
			# REJETEE (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
			*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
			# REJETEE (out of scope). Extension properties are outside the current scope of hCalendar.
			*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
			# REJETEE (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
			*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
			# REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
			*# ''There are styling and tooltip issues that are unresolved.''
			# REJETEE (empty statements). Voir [[hcalendar-faq-fr\|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
			*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
			# REJETEE (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
			*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
			# ACCEPTEE-PARTIELLEMENT. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar-fr\|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
			# ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats-fr\|microformats]] specifications in general? (If not, why not?)''
			#* ACCEPTEE. Yes, all [[microformats-fr\|microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
			#** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
			#*** ACCEPTEE. voir [[profile-uris]] ; ceci est une migration à partir de la liste [[to-do]] de Tantek, pour que les deux puissent fournir des probils d 'auteurs amateurs et d'URLs (probablement sur gmpg.org) pour ces profils sur hCalenar.
			* {{OpenIssue-fr}} 2006-04-10 raised by [[User:ScottReynen\|Scott Reynen]].
			*# ''Quand quelqu'un cherche des pages [[hcalendar-fr\|hCalendar]], on ne voit pas de collection de publication du vrai monde de données événements ni de discussion des propriétés implicites par de tels exemples, je pense que c'est bien plus facile d'inférer que les microformats proviennent d'autres formats plus que des comportements véritables. Il n'y a rien dans le [[process-fr\|processus]] ni dans les pages hCalendar expliquant ce décalage. J'argumenterais qu'il devrait y avoir une explication, probablement dans les deux lieux.''
			* {{OpenIssue-fr}} 2006-04-13 soulevée par Tantek
			*# ''Besoin d'ajouter une section sur "Exceptions de Propriétés" comme dans [[hcard-fr\|hCard]] pour documenter comment publier / gérer la propriété '''METHOD''' et potentiellement d'autres. Par ex, généralement les auteurs peuvent omettre la propriété METHOD, néanmoins les convertisseurs dont la fonction est de convertir [[hcalendar-fr\|hCalendar]] vers iCalendar pour la consommation / abonnnement par un agrégateur de calendrier, devrait probablement insérer un '''METHOD:PUBLISH''' par défaut sur l'objet '''VCALENDAR''' dans le flux résultant .ics.''


			== Pages en rapport ==
			{{hcalendar-related-pages-fr}}

Nu9N0r at 17:57, 11 April 2007

2007-04-11T17:57:28Z

← Older revision		Revision as of 17:57, 11 April 2007
Line 141:		Line 141:

	* 2005-07-11 soulevée par Kragen		* 2005-07-11 soulevée par Kragen
	*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk-fr\|xFolk]].''		*# ''The specification of class="url" as
	# REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

	* 2005-06-21 raised by Hixie
	*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?

	# ACCEPTEE. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing-fr]] that documents precisely how user agents are to parse [[hcalendar-fr\|hCalendar]] markup.

	* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
	*# ''There is no copyright statement and no patent statement.''
	# ACCEPTEE. I have updated [[hcalendar-fr\|hCalendar]] (and [[hcard-fr\|hCard]], and all other MicroFormats) with a standard copyright statement and patent statement.

	* 2005-02-18 soulevée par Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
	*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
	# REJETEE (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
	*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
	# REJETEE (out of scope). Extension properties are outside the current scope of hCalendar.
	*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
	# REJETEE (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
	*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
	# REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
	*# ''There are styling and tooltip issues that are unresolved.''
	# REJETEE (empty statements). Voir [[hcalendar-faq-fr\|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
	*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
	# REJETEE (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
	*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
	# ACCEPTEE-PARTIELLEMENT. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar-fr\|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
	# ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats-fr\|microformats]] specifications in general? (If not, why not?)''
	#* ACCEPTEE. Yes, all [[microformats-fr\|microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
	#** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
	#*** ACCEPTEE. voir [[profile-uris]] ; ceci est une migration à partir de la liste [[to-do]] de Tantek, pour que les deux puissent fournir des probils d 'auteurs amateurs et d'URLs (probablement sur gmpg.org) pour ces profils sur hCalenar.
	* {{OpenIssue-fr}} 2006-04-10 raised by [[User:ScottReynen\|Scott Reynen]].
	*# ''Quand quelqu'un cherche des pages [[hcalendar-fr\|hCalendar]], on ne voit pas de collection de publication du vrai monde de données événements ni de discussion des propriétés implicites par de tels exemples, je pense que c'est bien plus facile d'inférer que les microformats proviennent d'autres formats plus que des comportements véritables. Il n'y a rien dans le [[process-fr\|processus]] ni dans les pages hCalendar expliquant ce décalage. J'argumenterais qu'il devrait y avoir une explication, probablement dans les deux lieux.''
	* {{OpenIssue-fr}} 2006-04-13 soulevée par Tantek
	*# ''Besoin d'ajouter une section sur "Exceptions de Propriétés" comme dans [[hcard-fr\|hCard]] pour documenter comment publier / gérer la propriété '''METHOD''' et potentiellement d'autres. Par ex, généralement les auteurs peuvent omettre la propriété METHOD, néanmoins les convertisseurs dont la fonction est de convertir [[hcalendar-fr\|hCalendar]] vers iCalendar pour la consommation / abonnnement par un agrégateur de calendrier, devrait probablement insérer un '''METHOD:PUBLISH''' par défaut sur l'objet '''VCALENDAR''' dans le flux résultant .ics.''


	~~== Pages en rapport ==~~
	~~{{hcalendar-related-pages-fr}}~~