hcalendar-issues-resolved

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

resolved issues

hCalendar issues that are resolved but may have outstanding to-do items.

As issues are resolved, they will be moved from the Issues list to this section.

As actions are taken according to the resolutions noted in the issues, they are moved to hcalendar-issues-closed.

resolved 2005

• 2005-02-18 raised by Matt Raymond on the whatwg list:
  1. ...
  2. ...
  3. ...
  4. ...
  5. ...
  6. ...
  7. I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.
     • ACCEPT-PARTIAL FAQ. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay A Touch of Class. And yes, class names can and should be used for user-defined semantics. hCalendar is one such user, and it is reasonable for users to use each others class names.
     • Would it be more in the spirit of HTML to define these classes in a metadata profile, so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of microformats specifications in general? (If not, why not?)
       • ACCEPTED. Yes, all microformats that introduce new classnames SHOULD include an XMDP profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
         • Ok, but in order to refer to a profile, it needs a URI. Tantek writes in a message of Jul 21 "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?
           • ACCEPTED. See profile-uris; this is moving from Tantek's to-do list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.
           • UPDATE: hCalendar profile: http://microformats.org/profile/hcalendar. to-do - add this to hcalendar-faq.

• 2005-06-21 raised by Hixie
  1. Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
     • ACCEPTED. Another to-do for Tantek, write-up hcalendar-parsing that documents precisely how user agents are to parse hCalendar markup.

• 2005-07-11 raised by Kragen
  1. The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, should be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about xFolk.
     • REJECTED feature request. Lack of use case. We should not add new "ways of referencing the event URL" unless there are concrete real world example on the Web which requires it.
     • ACCEPTED clarification. The processing model for "url" properties (e.g. hcard-parsing, hcalendar-parsing) should state what to do with all valid HTML4 elements that reference external URLs (like <iframe>), and all such valid HTML5 elements (like <embed> - Tantek 08:16, 26 August 2009 (UTC)

• 2005-07-27 raised by Paolo Massa
  1. I tried to add a hcalendar event in my blog but it rendered horribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

     .vevent .summary { text-decoration: none; font-size: 100%; }
     

     Since the hCalendar microformat is the following,

     <span class="vevent"><a class="url" href="http://www.web2con.com/"><span class="summary">Web 2.0 Conference</span></a></span>
     

     ... I hope to have been clear but I'm not so sure ;-)
     • ACCEPTED FAQ. to-do expand the current FAQ class interactions entry with contextual selector examples.

• 2005-09-29 raised by RyanKing
  1. How does one use ATTENDEE?
     • ACCEPTED. Another to-do for Tantek - document how to use ATTENDEE with hCard.
     • UPDATE: This has now been documented in hCalendar brainstorming: hCard attendees. The remaining to-do is to incorporate the SHOULD use hCard attendees suggestion into the hCalendar 1.0.1 specification.

• 2005-10-14 raised by MarkoMrdjenovic
  1. 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. RFC recommends use of addr format for uids which is problematic in html id (does not validate). 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.
     • UPDATE: Which version(s) of Microsoft Outlook have this problem? Please document in icalendar-implementations.
  2. 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
     • ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
  3. Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):

  <li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
    <abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
    <abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
    <a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
        <span class="summary">From the other cal</span>
    </a>
    <abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
  </li>

• 1. • For more discussion of this, please see hCalendar brainstorming: UID handling

resolved 2006

• 2006-01-04 raised by CGranade
  1. ...
  2. 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 Mark Mansour - notes are summarized here
  1. 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 spec should say *precisely* how to generate VCALENDAR properties in their absence. Tantek
  2. How are axis and headers going to be handled?
     • ACCEPTED. This is documented in hcalendar-brainstorming but to-do MUST be moved to hCalendar proper as the editors and implementers have all agreed on it (months ago). Tantek
  3. 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 spec for *either* "axis" or "headers" would have found the following example in the wild: Web Essentials 05 (original page http://we05.com/ is offline) has marked up their program schedule table with hCalendar (original page http://we05.com/program.cfm is offline), using the 'axis' and 'headers' attributes. to-do: write up in the hcalendar-faq.
  4. 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.
     • UPDATE: We should try Optimus with these existing hCalendar tests. Tantek
  5. 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.

<a name="myfrag">heading</a>
<div class="vevent">
  <div class="description">A nice event</div>
  <abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>

• 1. • 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-03-07 raised by Justin McDowell

• 1. 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.
     • See hcalendar-cheatsheet . Michael Leikam 2007-01-29
     • ACCEPTED. to-do hCalendar should list all applicable properties in the hCalendar property list, similar to hCard. Tantek

• 2006-04-10 raised by Scott Reynen

• 1. When someone looks at the hCalendar pages, one sees no collection of real-world publishing of event data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the process nor the hCalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.
     • ACCEPTED update spec and faq. to-do add links/documentation on both hCalendar, with more in hcalendar-faq, on why did hCalendar simply re-use the VEVENT object (previous format) from iCalendar without first researching/documenting real-world publishing data, and lessons learned. I.e. were we to do an "event" microformat today, we would likely omit most VEVENT properties because they would very likely not meet the 80/20 real-world publishing of event data implied schema requirement of the process. In effect, most VEVENT properties were omitted in that they were not explicitly listed in the hCalendar spec. It may still reasonable to document event-examples, and any VEVENT properties that didn't show sufficient at least implicit usage could be listed in hCalendar as merely "reserved" terms that have seen little use.

• 2006-04-13 raised by Tantek

• 1. Need to add a section on "Property Exceptions" like that in hCard to document how to publish / handle the METHOD property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert hCalendar to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default METHOD:PUBLISH on the VCALENDAR object in the resultant .ics stream.
     • ACCEPTED update spec and hCalendar-to-iCalendar processing conformance requirements accordingly.

• 2006-08-14 raised by Elias Sinderson

• 1. Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical note (submitted by Reuters), which recommends that the extended (delimited) format be used, and the HTML 4.01 spec uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the xsd:date and xsd:dateTime types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed/ validated representation. Think of the children.
     • ACCEPTED update spec. More important than easy parsing/validation is the fact that the extended format (with explicit hyphens and colons) is both more readable and more listenable (per experience with accessibility testing), and thus better suited for both in-line text inclusion, and title attribute inclusion, both of which should be human readable and listenable.
       • Update hCalendar 1.0 to make it a SHOULD for authors to use hyphens/colons for dates and times respectively, make it a MUST for processors to accept both formats for compatibility.
       • In hCalendar 1.0.1 make it a SHOULD for authors to use hyphens/colons for dates and times respectively, and deprecate dates/times without separators. Keep it as a MUST for processors to accept both formats for compatibility.
       • In hCalendar 1.1 make it a MUST for authors to use hyphens/colons for dates and times respectively, and obsolete dates/times without separators. Note for hCalendar 1.0.x compat that processors MUST accept both formats.

resolved 2007

• ...

see also

• hcalendar-issues
• hcalendar-issues-closed