hcalendar-issues

(Difference between revisions)

Jump to: navigation, search
(Suggestion to infer DTSTAMP)
Line 48: Line 48:
*# ''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''.
*# ''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.
*#* 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
+
*# ''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.
*#* 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):''
*# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''

Revision as of 17:48, 3 July 2006

hCalendar Issues

These are externally raised issues about hCalendar with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

See related hcard-issues.

Issues

Please use this format:

And add new issues to the top of the list:

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

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<a class="url" href="http://www.web2con.com/">

Web 2.0 Conference:

...

I hope to have been clear but I'm not so sure ;-)


hcalendar-issues was last modified: Wednesday, December 31st, 1969

Views