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

← Older revision		Revision as of 15:39, 31 March 2007
Line 711:		Line 711:
	</nowiki></pre>		</nowiki></pre>

	=== ~~Inforamtion~~ To-Do ===		=== Information To-Do ===

	The [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting - 23 Aug 2005] uses class="vtodo" to capture action items. Clearly recording action items from a meeting and publishing them as minutes is a good practical example use of the VTODO object on the web.		The [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting - 23 Aug 2005] uses class="vtodo" to capture action items. Clearly recording action items from a meeting and publishing them as minutes is a good practical example use of the VTODO object on the web.
Line 721:		Line 721:
	Perhaps with some way of figuring out who the to-do item is assigned to ("ATTENDEE"), who assigned it ("DELEGATED-FROM"), and a whitelisting of who, perhaps the "ORGANIZER" property, (and their domains/URLs) that a user would accept assignments from, a user could aggregate to-do items assigned from other folks. Then question remains how to update the status ("STATUS") (RFC 2445 4.8.1.11 Status) on that to-do item when it is (a) completed ("COMPLETED"), (b) abandoned/cut/rejected ("CANCELLED"), (c) some progress is made ("IN-PROCESS") etc. There certainly seems to be sufficient expressiveness in VTODO and its properties to do a decentralized to-do list / task distribution system. Could be very interesting for helping open source projects and other distributed teams do project management using the Web.		Perhaps with some way of figuring out who the to-do item is assigned to ("ATTENDEE"), who assigned it ("DELEGATED-FROM"), and a whitelisting of who, perhaps the "ORGANIZER" property, (and their domains/URLs) that a user would accept assignments from, a user could aggregate to-do items assigned from other folks. Then question remains how to update the status ("STATUS") (RFC 2445 4.8.1.11 Status) on that to-do item when it is (a) completed ("COMPLETED"), (b) abandoned/cut/rejected ("CANCELLED"), (c) some progress is made ("IN-PROCESS") etc. There certainly seems to be sufficient expressiveness in VTODO and its properties to do a decentralized to-do list / task distribution system. Could be very interesting for helping open source projects and other distributed teams do project management using the Web.

	== ~~References~~ ==		== Références ==
	=== ~~Normative References~~ ===		=== Références Normatives ===
	* [http://www.ietf.org/rfc/rfc2445.txt RFC 2445]		* [http://www.ietf.org/rfc/rfc2445.txt RFC 2445]
	* [http://gmpg.org/xmdp/ XMDP]		* [http://gmpg.org/xmdp/ XMDP]

	=== ~~Informative References~~ ===		=== Références Inforamtives ===
	* [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars HTMLForCalendars (FOO camp)] - presented just a few days before this, hopefully these efforts can be combine		* [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars HTMLForCalendars (FOO camp)] - presented just a few days before this, hopefully these efforts can be combine

Line 736:		Line 736:
	* [http://www.ietf.org/rfc/rfc3283.txt Guide to Internet Calendaring RFC3283]		* [http://www.ietf.org/rfc/rfc3283.txt Guide to Internet Calendaring RFC3283]

	== ~~Other~~ Implementations/~~Ideas~~ ==		== Autres Implementations/Idées ==
	* [http://www.nehmer.net/~bergie/openpsa-calendar-horizontal.jpg OpenPSA calendar screenshot]		* [http://www.nehmer.net/~bergie/openpsa-calendar-horizontal.jpg OpenPSA calendar screenshot]
	* [http://www.w3.org/2002/12/cal/ RDF Calendar Workspace] - some older work done with RDF, not really applicable to the simple XHTML case, but perhaps worthy of analysis for when and why they may have diverged from established iCalendar schemas.		* [http://www.w3.org/2002/12/cal/ RDF Calendar Workspace] - some older work done with RDF, not really applicable to the simple XHTML case, but perhaps worthy of analysis for when and why they may have diverged from established iCalendar schemas.
	* [http://planb.nicecupoftea.org/archives/000072.html 2003 RDF icalendar work, xCal references]		* [http://planb.nicecupoftea.org/archives/000072.html 2003 RDF icalendar work, xCal references]

	== Blogs ~~About Calendaring~~ ==		== Blogs à propos de Calendrier ==
	* http://staff.washington.edu/oren/weblog2/		* http://staff.washington.edu/oren/weblog2/

			==Simplification de date-end==

			Si toutefois il y a un standard "hCalendar 2", on doit penser qu'il pourrait lui être donné pour modifier la manière dont est géré dtend, quand aucune heure n'est spécifiée. Actuellement, nous utilisons :

			:<code><nowiki><abbr class="dtend" title="2007-02-01">31 janvier 2007</abbr></nowiki></code>

			qui est contre-intuitif pour les auteurs (comme les indications passées sur les [[hcalendar-examples-in-wild-fr\|exemples dans la jungle]] et ailleurs [http://rbach.priv.at/Microformats-IRC/2007-03-29#T183612] l'ont montrées). Dans l'intérêt de la ''facilité de pubication'', nous devrions considérer, peut-être une nouveau nom de propriété pour la clarté, utilisant :

			:<code><nowiki><abbr class="enddate" title="2007-03-31">31 janvier 2007</abbr></nowiki></code>

			et faire que les ''parseurs'' soient responsables pour convertir en "2007-02-01" au moment d'exporter sous une vCard. [[User:AndyMabbett\|Andy Mabbett]] 05:28, 29 Mar 2007 (PDT)

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

ChristopheDucamp: /* Questions Générales */ à traduire

2007-03-31T15:33:13Z

Questions Générales: à traduire

← Older revision		Revision as of 15:33, 31 March 2007
Line 460:		Line 460:
	Q: Should vCal entitles be represented in XHTML in classes ONLY on block-level element? or should some like VEVENT be block-level and others be of any? does this impact the semantics at all?		Q: Should vCal entitles be represented in XHTML in classes ONLY on block-level element? or should some like VEVENT be block-level and others be of any? does this impact the semantics at all?

	A: I don't think the (X)HTML notion of "block-level" should have any bearing whatsoever on vCal entities. You should be able to say <span class="vevent"> or <div class="vevent"> and either should work.		A: I don't think the (X)HTML notion of "block-level" should have any bearing whatsoever on vCal entities. You should be able to say <nowiki><span class="vevent"></nowiki> or <nowiki><div class="vevent"></nowiki> and either should work.

	Q: Should the transforming application add any additional information to the iCalendar representation other than what was encoded in the HTML? (i.e. UID, the unique identifier might not be present in the HTML code, but could be generated by the transforming application and added to the iCal file. Should this be allowed? or should the transforming app ONLY be allowed to add X-PROPERTY properties?) IF it was not explicitly encoded in the HTML should it be left out? What about default values?		Q: Should the transforming application add any additional information to the iCalendar representation other than what was encoded in the HTML? (i.e. UID, the unique identifier might not be present in the HTML code, but could be generated by the transforming application and added to the iCal file. Should this be allowed? or should the transforming app ONLY be allowed to add X-PROPERTY properties?) IF it was not explicitly encoded in the HTML should it be left out? What about default values?

hcalendar-brainstorming-fr - Revision history

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

CcoacCvarp: letogeto

ChristopheDucamp: revert vandalism Fr4Axt

Fr4Axt at 08:36, 24 August 2007

Brian at 18:07, 13 June 2007

CtgHtn at 17:59, 13 June 2007

Brian at 16:06, 11 April 2007

Yp1Hsu at 16:00, 11 April 2007

ChristopheDucamp at 15:39, 31 March 2007

ChristopheDucamp: /* Questions Générales */ à traduire