hcalendar-irc-meetup-20060225: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (darrolva)
Line 1: Line 1:
elpascna
= Attendees =
= Attendees =
* Mark Mansour
* Mark Mansour

Revision as of 03:13, 20 December 2008

elpascna

Attendees

  • Mark Mansour
  • Brian Suda
  • Kevin Marks
  • Ryan King

Source

The hcalendar irc meetup on 20060225 attempted to solve the issues listed on 2006-02-17.

hCalendar tests

The LifeLint hCalendar tests are to be donated to microformats.org. RyanKing will move these over to a subversion server at microformats.org. No time was given for when these tests would be available at microformats.org.

The worth of a vcalendar class

  • vcalendar class allows multiple calendars to appear on the one web page
    • this is not being done in the wild
  • vcalendar class allows items to be added to a calendar object
    • there are four properties on a calendar which are PRODID, VERSION, METHOD, CALSCALE. VERSION is always 2.0 and does not look likely to change. PRODID tells us who made the calendar, but if it gets transformed a new PRODID will be added - i.e. it gets overridden. CALSCALE value is GREGORIAN as is the whole ical spec - there would have to be massive changes for this to be a different value. The METHOD property is disucced in more detail in iTIP and defines the possible values. It appears that calendar user agents ignore this anyway. NOTE: If producing an ICS for consumption by Outlook, then the METHOD property must be set.

Therefore:

  • the vcalendar class is not needed and it can be assumed that if a vevent is found on a page, then it is part of a hCalendar.
  • when producing ICS files, the METHOD property on the VCALENDAR should be set to PUBLISH.
    • The PUBLISH value seems to be the most suitable value as it works for all component types and posting information to a web page is equivalent to publishing a calendar.

Axis/Header layout of calendar data

  • There are no examples in the wild. RyanKing and Brian Suda have examples which they are going to make public.

Correction (later): there is an example in the wild: http://we05.com/program.cfm --RyanKing 12:08, 27 Feb 2006 (PST)

Components

  • The components defined by ical are VEVENT, VTODO, VALARM, VFREEBUSY, VJOURNAL and VTIMEZONE.
  • There are two places that components can exist, either as "components" or "subcomponents"
    • components live directly inside a calendar -> VEVENT, VTODO, VFREEBUSY, VJOURNAL and VTIMEZONE
      • VTIMEZONE has been removed from ical-basic draft 04 so should probably be removed from hCalendar
      • the value of VJOURNAL has been questioned by RyanKing since since hAtom probably serves the same purpose.
      • VEVENT are currently allowed and are used in the wild
      • VALARMs may not appear at the same level as events (line 2864 of ical)
      • need to work out if VTODO, VFREEBUSY are worth having.
    • subcomponents live within other components -> VALARM
      • VALARMs must be nested inside VEVENTs or VTODOs. (line 3912 of ical)
      • hCalendar does not support these at the moment

Followup:

  • find VTODOs, VFREEBUSYs and VALARMs in the wild

Fragments

  • As both RyanKing and Brian Suda point out, the fragment hCalendar test are wrong because:
    • The XHTML spec defines fragments to use the id attribute and the test was using the name attribute
    • The child elements of a fragment should be inspected to determine values.