hcalendar-irc-meetup-20060225: Difference between revisions
Jump to navigation
Jump to search
ErmonDronr (talk | contribs) 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
- components live directly inside a calendar -> VEVENT, VTODO, VFREEBUSY, VJOURNAL and VTIMEZONE
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.