hcalendar-issues-resolved - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:24:30Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:24, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~hCalendar resolved issues~~</entry-title>~~		{{DISPLAYTITLE:hCalendar resolved issues}}
	== resolved issues ==		== resolved issues ==
	[[hCalendar]] <span id="Resolved_Issues">issues that are resolved but may have outstanding [[to-do]] items.</span>		[[hCalendar]] <span id="Resolved_Issues">issues that are resolved but may have outstanding [[to-do]] items.</span>

Tantek: add shortlink

2009-10-01T01:36:58Z

add shortlink

← Older revision		Revision as of 01:36, 1 October 2009
Line 2:		Line 2:
	== resolved issues ==		== resolved issues ==
	[[hCalendar]] <span id="Resolved_Issues">issues that are resolved but may have outstanding [[to-do]] items.</span>		[[hCalendar]] <span id="Resolved_Issues">issues that are resolved but may have outstanding [[to-do]] items.</span>

			;shortlink
			:http://tr.im/hcalri

	As issues are resolved, they will be moved from the [[hcalendar-issues\|Issues list]] to this section.		As issues are resolved, they will be moved from the [[hcalendar-issues\|Issues list]] to this section.

Tantek: /* resolved 2009 */ resolved a recently added issue, made value-class-pattern and human readable/listenable use of title attribute a MUST for authors in hCalendar 1.0.1; too important to wait til 1.1

2009-10-01T01:19:20Z

resolved 2009: resolved a recently added issue, made value-class-pattern and human readable/listenable use of title attribute a MUST for authors in hCalendar 1.0.1; too important to wait til 1.1

← Older revision		Revision as of 01:19, 1 October 2009
Line 264:		Line 264:
	* <strong class="entry-title">Specification references to <code>abbr</code> pattern need to be removed/updated</strong>. See: [http://microformats.org/wiki/hcalendar#Human_vs._Machine_readable /hcalendar#Human_vs._Machine_readable] — the spec currently reads “This specification recommends that such <code><abbr></code> elements be used for the following iCalendar properties: DTSTART, DTEND, DURATION, RDATE, RRULE</code>. That is no-longer appropriate. In fact, I think it should be made clearer that those properties ''may'' be marked up using the abbr, or value-class patterns, but that it isn't required. The current language basically masks the fact that you might publish <samp>2009-07-14</samp> literally, and may be some reason why people believe that they ''have'' to use the abbr pattern. Further, this language is incompatible with publishing HTML5 with the <code>time</code> element.		* <strong class="entry-title">Specification references to <code>abbr</code> pattern need to be removed/updated</strong>. See: [http://microformats.org/wiki/hcalendar#Human_vs._Machine_readable /hcalendar#Human_vs._Machine_readable] — the spec currently reads “This specification recommends that such <code><abbr></code> elements be used for the following iCalendar properties: DTSTART, DTEND, DURATION, RDATE, RRULE</code>. That is no-longer appropriate. In fact, I think it should be made clearer that those properties ''may'' be marked up using the abbr, or value-class patterns, but that it isn't required. The current language basically masks the fact that you might publish <samp>2009-07-14</samp> literally, and may be some reason why people believe that they ''have'' to use the abbr pattern. Further, this language is incompatible with publishing HTML5 with the <code>time</code> element.
	** Proposed resolution: Remove all ‘endorsement’ language regarding specific optimization patterns from the spec. The properties concerned should link to appropriate patterns and suggest uses ‘may’ use them to control the presentation of dates. --[[User:BenWard\|BenWard]] 17:39, 14 July 2009 (UTC)		** Proposed resolution: Remove all ‘endorsement’ language regarding specific optimization patterns from the spec. The properties concerned should link to appropriate patterns and suggest uses ‘may’ use them to control the presentation of dates. --[[User:BenWard\|BenWard]] 17:39, 14 July 2009 (UTC)
	*** '''ACCEPTED update spec.''' hCalendar 1.0.1 will state that authors ~~SHOULD~~ use the [[value-class-pattern]] accordingly, and should only use abbr pattern when the author determines that the expanded title value is both human and machine readable and listenable, deprecating other uses of the abbr pattern. hCalendar 1.0.1 will also state that implementations ~~MUST~~ support the [[value-class-pattern]]~~. hCalendar 1.1 will make that authoring SHOULD a MUST, and obsolete other uses of the abbr pattern~~.		*** '''ACCEPTED update spec.''' hCalendar 1.0.1 will state that authors {{must}} use the [[value-class-pattern]] accordingly, and should only use abbr pattern when the author determines that the expanded title value is both human and machine readable and listenable, deprecating other uses of the abbr pattern. hCalendar 1.0.1 will also state that implementations {{must}} support the [[value-class-pattern]].
	</div>		</div>
	</div>		</div>
Line 273:		Line 273:
	* <strong class="entry-title">All properties that are appropriate for use with the [[value-class-pattern]] must opt in to using it.</strong>. See: [[machine-data]] for the current reference for which properties have value-class-patterns support. Revisions of specifications should be updated to opt-in to value-class where appropriate.		* <strong class="entry-title">All properties that are appropriate for use with the [[value-class-pattern]] must opt in to using it.</strong>. See: [[machine-data]] for the current reference for which properties have value-class-patterns support. Revisions of specifications should be updated to opt-in to value-class where appropriate.
	** '''ACCEPTED update spec.''' See resolution to previous issue regarding [[#abbr-to-value-class]].		** '''ACCEPTED update spec.''' See resolution to previous issue regarding [[#abbr-to-value-class]].
			</div>
			</div>

			<div class="hentry">
			{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-09-01</span> raised by <span class="fn">[[User:Martin de la Iglesia\|Martin de la Iglesia]]</span></span>
			<div class="entry-content discussion issues">
			* <strong class="entry-title">DURATION format</strong>. Is there a specification of the format used for durations? In example 4 (http://microformats.org/wiki/hcalendar-examples), the duration value is "PT1H". I guess "1H" is one hour, but what does "PT" mean? And this example doesn't work anyway; neither Google calendar nor Yahoo! calendar recognize this duration.
			** Part 1 ACCEPTED FAQ, SPECUPDATE. The format for durations is from iCalendar [[RFC2445]] which gets it from [[ISO8601]]. [[to-do]] this should be documented in [[hcalendar-faq]], and explicitly referenced in an update to the hCalendar spec itself. [[User:Tantek\|Tantek]] 01:19, 1 October 2009 (UTC)
			** Part 2 REJECTED, NEED STEPS TO DEMONSTRATE. What steps were taken which led to the conclusion that "neither Google calendar nor Yahoo! calendar recognize this duration" ? Without more information, this aspect of the issue will have to be closed, insufficient information. [[User:Tantek\|Tantek]] 01:19, 1 October 2009 (UTC)
	</div>		</div>
	</div>		</div>

Tantek: /* resolved 2007 */ resolved last outstanding 2007 issue - dtend-issue

2009-10-01T00:59:29Z

resolved 2007: resolved last outstanding 2007 issue - dtend-issue

@@ Line 155: / Line 155: @@
 *#**Feel free to move the above thoughts to a brainstorming area. I might come back to the other points later - but maybe better in a talk page. :-) [[User:Webf|Webf]] 13:23, 21 Jan 2007 (PST)
 *#* ACCEPTED FAQ. Two FAQs to add. 1. Yes, elements other than abbr can and should be used for marking up dates and times when they are more semantically appropriate, and especially when they minimize duplicating data.  2. object is a variant of the [[include-pattern]] and thus can be used for the requested functionality. The table cell headers attribute can also be used.
 </div>
 </div>

Tantek: /* resolved 2008 */ resolved 2009 issues

2009-08-27T05:02:58Z

resolved 2008: resolved 2009 issues

@@ Line 224: / Line 224: @@
 *# To sum up, how would you write an event that has no duration but which is only a moment in the life (this recalls the first of my issues where there is an event with no known end date, which is different from an event which has no end date because it has no duration!).
 *#* '''ACCEPTED faq.''' Add to [[hcalendar-faq]]. You can mark up an event which is only a moment (presuming a moment is less than a second) as having the same dtstart and dtend.
 </div>
 </div>

Tantek: /* resolved 2007 */ resolved 2008 issues

2009-08-27T04:35:43Z

resolved 2007: resolved 2008 issues

@@ Line 155: / Line 155: @@
 *#**Feel free to move the above thoughts to a brainstorming area. I might come back to the other points later - but maybe better in a talk page. :-) [[User:Webf|Webf]] 13:23, 21 Jan 2007 (PST)
 *#* ACCEPTED FAQ. Two FAQs to add. 1. Yes, elements other than abbr can and should be used for marking up dates and times when they are more semantically appropriate, and especially when they minimize duplicating data.  2. object is a variant of the [[include-pattern]] and thus can be used for the requested functionality. The table cell headers attribute can also be used.
 </div>
 </div>

Tantek: /* resolved 2007 */ resolved all but one 2007 issue

2009-08-27T03:40:12Z

resolved 2007: resolved all but one 2007 issue

@@ Line 122: / Line 122: @@
 === resolved 2007 ===
-* ...
+<div class="hentry">
 == see also ==
 * [[hcalendar-issues]]
 * [[hcalendar-issues-closed]]

Tantek: /* resolved 2006 */ resolved remaining 2006 issues

2009-08-27T03:12:20Z

resolved 2006: resolved remaining 2006 issues

@@ Line 91: / Line 91: @@
 *#* See [[hcalendar-cheatsheet]] . [[User:Leikam|Michael Leikam]] 2007-01-29
 *#* ACCEPTED. [[to-do]] hCalendar should list all applicable properties in the [[hCalendar#Property_List|hCalendar property list]], similar to hCard. [[User:Tantek|Tantek]]
 </div>
 </div>

Tantek: /* resolved 2006 */ resolve a couple more issues, close a couple that have been completed

2009-08-26T09:56:24Z

resolved 2006: resolve a couple more issues, close a couple that have been completed

← Older revision		Revision as of 09:56, 26 August 2009
Line 60:		Line 60:

	=== resolved 2006 ===		=== resolved 2006 ===
			* 2006-01-04 raised by [[User:CGranade\|CGranade]]
			*# ''...''
			*# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
			# ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.

	* 2006-02-17 raised by [[User:Mark Mansour\|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225\|here]]		* 2006-02-17 raised by [[User:Mark Mansour\|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225\|here]]
	*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).		*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
	# ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar\|hCalendar]] spec should say precisely how to generate VCALENDAR properties in their absence.		# ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar\|hCalendar]] spec should say precisely how to generate VCALENDAR properties in their absence. [[User:Tantek\|Tantek]]
	*# How are axis and headers going to be handled?		*# How are axis and headers going to be handled?
	# ACCEPTED. This is documented in [[hcalendar-brainstorming]] but MUST be moved to [[hcalendar\|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). ~~Add this as a~~ [[~~to-do~~]] ~~for Tantek.~~		# ACCEPTED. This is documented in [[hcalendar-brainstorming]] but [[to-do]] MUST be moved to [[hcalendar\|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). [[User:Tantek\|Tantek]]
	*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?		*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
	# ACCEPTED FAQ. Searching the [[hcalendar\|hCalendar]] spec for either "axis" or "headers" would have found the following example in the wild: [http://web.archive.org/web/20051102094339/we05.com/ Web Essentials 05] (original page <nowiki>http://we05.com/</nowiki> is offline) has marked up their [http://web.archive.org/web/20051102094339/we05.com/program.cfm program schedule table with hCalendar] (original page <nowiki>http://we05.com/program.cfm</nowiki> is offline), using the 'axis' and 'headers' attributes. ~~This should be written up in the [[hcalendar-faq]].~~		# ACCEPTED FAQ. Searching the [[hcalendar\|hCalendar]] spec for either "axis" or "headers" would have found the following example in the wild: [http://web.archive.org/web/20051102094339/we05.com/ Web Essentials 05] (original page <nowiki>http://we05.com/</nowiki> is offline) has marked up their [http://web.archive.org/web/20051102094339/we05.com/program.cfm program schedule table with hCalendar] (original page <nowiki>http://we05.com/program.cfm</nowiki> is offline), using the 'axis' and 'headers' attributes. [[to-do]]: write up in the [[hcalendar-faq]].
	*# Should embeded components be allowed? [[RyanKing]] has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
	# ACCEPTED SPECUPDATE/FAQ. Another [[to-do]] ~~for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted~~ in ~~hCalendar. Current additional candidates: VTODO (many examples of this info on~~ the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by [[~~hatom\|hAtom~~]]).
	*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?		*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
	# ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.		# ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.
	*# The use of fragments is unclear. Fragment interpretation seems to be agent ~~dependant~~. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.		# UPDATE: We should try [[Optimus]] with these existing hCalendar tests. [[User:Tantek\|Tantek]]
			*# The use of fragments is unclear. Fragment interpretation seems to be agent dependent. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
	<pre>		<pre>
	<a name="myfrag">heading</a>		<a name="myfrag">heading</a>
Line 79:		Line 83:
	</div>		</div>
	</pre>		</pre>
	# ACCEPTED. We should clarify to converters how to interpret a ~~fragement~~ id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.		# ACCEPTED. We should clarify to converters how to interpret a fragment id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation. [[to-do]]: add said documentation to [[hCalendar-faq]].
	* 2006-02-01 raised by [[~~RyanKing~~]]
	*# '~~'Issue 1: Given that now~~, ~~or soon will have hAtom~~, ~~should we disallow vJournal, so~~ that ~~we don't have 2 blog~~-~~post formats?''~~		<div class="hentry issue">
	# ~~ACCEPTED. Yes, we should expliclty DROP "vjournal" from~~ [[hcalendar~~\|hCalendar~~]].		* <span class="entry-title"><span class="published">2006-03-07</span> raised by <span class="author vcard"><span class="fn">[[User:Ragdoll\|Justin McDowell]]</span></span></span>
	* 2006-01-04 raised by [[User:~~CGranade~~\|~~CGranade~~]]		<div class="entry-content discussion">
	*# ~~''...''~~		*# I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting acquainted with the possibilities of vCalendar.
	*~~# ''All examples in XHTML~~. ~~XHTML should not be the only host~~ to ~~microformats, and thus it~~ should ~~not be~~ the ~~only example host language. Rather~~, ~~examples in Atom, RSS, RDF, etc~~. ~~should also be provided.''~~		# See [[hcalendar-cheatsheet]] . [[User:Leikam\|Michael Leikam]] 2007-01-29
	# ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.		# ACCEPTED. [[to-do]] hCalendar should list all applicable properties in the [[hCalendar#Property_List\|hCalendar property list]], similar to hCard. [[User:Tantek\|Tantek]]
			</div>
			</div>

	=== resolved 2007 ===		=== resolved 2007 ===

Tantek: /* resolved 2005 */ resolve remaining open 2005 issues

2009-08-26T08:16:03Z

resolved 2005: resolve remaining open 2005 issues

@@ Line 8: / Line 8: @@
 === resolved 2005 ===
 * 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
 *# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''.
 *#* ACCEPTED-PARTIAL.  Yes, it appears RFC2445 requires UID.  However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so.  Thus we must come up with an algorithm for implied UID, similar to some of the other properties.  We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic.  As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
-*# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.'' [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- [[DimitriGlazkov]]
+*#* UPDATE: Which version(s) of Microsoft Outlook have this problem? Please document in [[icalendar-implementations]].
 *#* ACCEPTED.  We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
 *# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
 <pre><nowiki>
    <li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
@@ Line 24: / Line 57: @@
      <abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
    </li></nowiki></pre>
-* 2005-09-29 raised by RyanKing
+*#* For more discussion of this, please see [[hcalendar-brainstorming#UID_handling| hCalendar brainstorming: UID handling]]
 === resolved 2006 ===