View source for hcalendar-issues-closed

{{DISPLAYTITLE:hCalendar closed issues}}

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

=== 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]:
*# ''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.

* 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 ===
* 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.

* 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]]

<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>

=== 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>

=== closed 2008 ===
<div class="hentry" id="historical-dates">
* <span class="entry-title"><span class="published">2008-01-16</span> raised by <span class="author vcard"><span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span></span>
<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).
*#* 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 class="hentry">
* <span class="entry-title"><span class="published">2008-09-30</span> raised by <span class="author vcard"><span class="fn">[[User:Thamis|Thamis]]</span></span></span>
<div class="entry-content">
*# There is no way to define BC (before Christ) dates, is there? There should be! [[User:Thamis|Thamis]] 03:58, 30 Sep 2008 (PDT)
*#* REJECTED duplicate. See issue [[#historical-dates]].
</div>
</div>

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