hcalendar-issues-closed

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

closed issues

Closed issues that have no further actions to take..

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 on the whatwg list:
  1. 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, and whether they are used for styling is orthogonal.
  2. 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.
  3. The use of <abbr> 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 <abbr> Human vs. ISO8601 dates problem solved
  4. You have to create a complex set of rules for all possible uses of legacy markup within 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.
  5. There are styling and tooltip issues that are unresolved.
     • REJECTED (empty statements). See the hCalendar FAQ for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
  6. 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 on the whatwg list:
  1. 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. Tantek

• 2005-07-21 raised by Neil Jensen
  1. should we create a vfreebusy class for HTML representations of freebusy data? Discussion on hCalendar brainstorming. Additional background: 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. - Tantek 08:14, 26 August 2009 (UTC)

closed 2006

• 2006-01-04 raised by CGranade
  1. 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 class 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
  1. 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.
     • UPDATE: hCalendar now explicitly refers to the iCalendar VEVENT object, thus limiting its scope. Tantek

• 2006-02-17 raised by Mark Mansour - notes are summarized here
  1. 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).
     • UPDATE: hCalendar now specifies right at the top that it takes properties 1:1 from the VEVENT object in particular. Tantek

• 2006-09-22 raised by Andy Mabbett

• 1. 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

     <abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> 

     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.

closed 2007

• 2007-05-12 raised by Anon

• 1. A pertinent point from the 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).

closed 2008

• 2008-01-16 raised by Andy Mabbett

• 1. Lack of method for marking up vague dates and eras; see 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.

• 2008-09-30 raised by Thamis

• 1. There is no way to define BC (before Christ) dates, is there? There should be! Thamis 03:58, 30 Sep 2008 (PDT)
     • REJECTED duplicate. See issue #historical-dates.

see also

• hcalendar-issues
• hcalendar-issues-resolved