hcalendar-issues-closed - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:24:28Z

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

← Older revision		Revision as of 16:24, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~hCalendar closed issues~~</entry-title>~~		{{DISPLAYTITLE:hCalendar closed issues}}

	== closed issues ==		== closed issues ==

Tantek: fix link to history microformat effort

2009-08-28T19:42:39Z

fix link to history microformat effort

← Older revision		Revision as of 19:42, 28 August 2009
Line 67:		Line 67:
	<div class="entry-content">		<div class="entry-content">
	*# Lack of method for marking up vague dates and eras; see [[history-examples#The_Problem\|vague-date examples]] (AKA historical dates).		*# Lack of method for marking up vague dates and eras; see [[history-examples#The_Problem\|vague-date examples]] (AKA historical dates).
	# REJECTED out of scope. While there certainly would be some utility in marking up vague dates and eras for historical purposes, this is outside the scope of and typical (80/20) usage of event publishing on the web. For both this problem of vague dates/eras, and Julian dates, it may be better to do research for a separate [[history]] microformat ([[history-examples]], [[history-formats]], [[history-brainstorming]]) to determine what would be sufficient to capture/publish the 80/20 of historical data/events published on the web. Options considered for [[history-brainstorming]] should include a separate microformat that re-uses [[hCalendar]] properties, perhaps minor extensions to hCalendar (to be considered for inclusion in 1.1) etc. However, all such brainstorming/proposals should be based on examples/formats research first.		# REJECTED out of scope. While there certainly would be some utility in marking up vague dates and eras for historical purposes, this is outside the scope of and typical (80/20) usage of event publishing on the web. For both this problem of vague dates/eras, and Julian dates, it may be better to do research for a separate [[history-effort\|history]] microformat ([[history-examples]], [[history-formats]], [[history-brainstorming]]) to determine what would be sufficient to capture/publish the 80/20 of historical data/events published on the web. Options considered for [[history-brainstorming]] should include a separate microformat that re-uses [[hCalendar]] properties, perhaps minor extensions to hCalendar (to be considered for inclusion in 1.1) etc. However, all such brainstorming/proposals should be based on examples/formats research first.
	</div>		</div>
	</div>		</div>

Tantek: /* closed 2007 */ closed a couple of 2008 issues

2009-08-27T04:34:02Z

closed 2007: closed a couple of 2008 issues

@@ Line 59: / Line 59: @@
 *# A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing.
 *#* REJECTED too little information. Unclear WHICH point from that version of [[hcalendar-issues]] you think is worth keeping and addressing. All issues should be kept and resolved one way or another (with perhaps elimination of dups).
 </div>
 </div>

Tantek: /* closed 2006 */ closed a 2007 issue

2009-08-27T03:40:15Z

closed 2006: closed a 2007 issue

← Older revision		Revision as of 03:40, 27 August 2009
Line 50:		Line 50:
	*# How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.		*# How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.
	# REJECTED not 80/20. Publishing Julian dates on the web is not 80/20, and is thus out of scope for fixing/adding to hCalendar. In addition, extending ISO8601 is also out of scope for hCalendar.		# REJECTED not 80/20. Publishing Julian dates on the web is not 80/20, and is thus out of scope for fixing/adding to hCalendar. In addition, extending ISO8601 is also out of scope for hCalendar.
			</div>
			</div>

			=== closed 2007 ===
			<div class="hentry">
			* <span class="entry-title"><span class="published">2007-05-12</span> raised by <span class="author vcard"><span class="fn">Anon</span></span></span>
			<div class="entry-content">
			*# A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing.
			# REJECTED too little information. Unclear WHICH point from that version of [[hcalendar-issues]] you think is worth keeping and addressing. All issues should be kept and resolved one way or another (with perhaps elimination of dups).
	</div>		</div>
	</div>		</div>

Tantek: /* closed 2006 */ closed a remaining 2006 issue - not doing Julian dates in hCalendar, outside 80/20 of published events on web

2009-08-27T03:02:19Z

closed 2006: closed a remaining 2006 issue - not doing Julian dates in hCalendar, outside 80/20 of published events on web

← Older revision		Revision as of 03:02, 27 August 2009
Line 44:		Line 44:
	# ACCEPTED SPECUPDATE/FAQ. to-do: Explicitly specify which additional iCalendar objects (in addition to VEVENT, if any) 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]]).		# ACCEPTED SPECUPDATE/FAQ. to-do: Explicitly specify which additional iCalendar objects (in addition to VEVENT, if any) 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]]).
	# UPDATE: [[hCalendar]] now specifies right at the top that it takes properties 1:1 from the VEVENT object in particular. [[User:Tantek\|Tantek]]		# UPDATE: [[hCalendar]] now specifies right at the top that it takes properties 1:1 from the VEVENT object in particular. [[User:Tantek\|Tantek]]

			<div class="hentry">
			* <span class="entry-title"><span class="published">2006-09-22</span> raised by <span class="author vcard"><span class="fn">[[User:AndyMabbett\|Andy Mabbett]]</span></span></span>
			<div class="entry-content">
			*# How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.
			# REJECTED not 80/20. Publishing Julian dates on the web is not 80/20, and is thus out of scope for fixing/adding to hCalendar. In addition, extending ISO8601 is also out of scope for hCalendar.
			</div>
			</div>

	== see also ==		== see also ==
	* [[hcalendar-issues]]		* [[hcalendar-issues]]
	* [[hcalendar-issues-resolved]]		* [[hcalendar-issues-resolved]]

Tantek: /* closed 2006 */ close a couple of issues that have been completed

2009-08-26T09:55:59Z

closed 2006: close a couple of issues that have been completed

← Older revision		Revision as of 09:55, 26 August 2009
Line 34:		Line 34:
	*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''		*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
	# REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.		# REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.

			* 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?''
			# ACCEPTED. Yes, we should explicitly DROP "vjournal" from [[hcalendar\|hCalendar]].
			# UPDATE: hCalendar now explicitly refers to the iCalendar VEVENT object, thus limiting its scope. [[User:Tantek\|Tantek]]

			* 2006-02-17 raised by [[User:Mark Mansour\|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225\|here]]
			*# Should embedded 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. to-do: Explicitly specify which additional iCalendar objects (in addition to VEVENT, if any) 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]]).
			# UPDATE: [[hCalendar]] now specifies right at the top that it takes properties 1:1 from the VEVENT object in particular. [[User:Tantek\|Tantek]]

	== see also ==		== see also ==
	* [[hcalendar-issues]]		* [[hcalendar-issues]]
	* [[hcalendar-issues-resolved]]		* [[hcalendar-issues-resolved]]

Tantek: /* closed 2005 */ closed a 2005 issue

2009-08-26T08:14:41Z

closed 2005: closed a 2005 issue

← Older revision		Revision as of 08:14, 26 August 2009
Line 5:		Line 5:

	=== closed 2005 ===		=== closed 2005 ===
			Issues that were raised in 2005 that have been resolved, and any/all related outstanding actions have been completed.


	* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:		* 2005-02-18 raised by 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.''		*# ''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.''
Line 18:		Line 21:
	*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''		*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
	# REJECTED (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.		# REJECTED (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.

			* 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.''
			# ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other microformats) with a standard copyright statement and patent statement. [[User:Tantek\|Tantek]]

			* 2005-07-21 raised by Neil Jensen
			*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''
			# REJECTED out of scope for hCalendar. hCalendar focuses on publishing events on the web. Indication of free/busy time is a different enough semantic that it is probably worth its own microformat research and exploration, and as part of that, listing the iCalendar VFREEBUSY as a previous format. - [[User:Tantek\|Tantek]] 08:14, 26 August 2009 (UTC)

	=== closed 2006 ===		=== closed 2006 ===

Tantek: move from hcalendar-issues, re-reviewed, and clarified a couple of rejected issues

2009-08-26T05:36:27Z

move from hcalendar-issues, re-reviewed, and clarified a couple of rejected issues

New page

<entry-title>hCalendar closed issues</entry-title>

== closed issues ==
<span id="Closed_Issues">Closed issues that have no further actions to take.</span>.

=== closed 2005 ===
* 2005-02-18 raised by 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.''
*#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. Class names should always be [[semantic classes|semantic]], and whether they are used for styling is orthogonal.
*# ''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).''
*#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
*# ''The use of <code><nowiki><abbr></nowiki></code> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-08-05. In fact, the opposite is closer to the truth.''
*#* REJECTED (strawman). In practice the year is often omitted and thus "August 5th" actually ''is'' an abbreviation for 2004-08-05 which specifies the year. See this article for an explanation of this use of <code><nowiki><abbr></nowiki></code> [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.''
*#* REJECTED (empty statements). See the [[hcalendar-faq|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.''
*#* REJECTED (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.

=== closed 2006 ===
* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
*#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.

== see also ==
* [[hcalendar-issues]]
* [[hcalendar-issues-resolved]]