[uf-dev] problems with testcases

[☻Mike Samuel]

Ack.  I really have to come off digest-mode if I'm to contribute
anything to this list.
Responses inline.


On 1/17/07, microformats-dev-request at microformats.org >
> Date: Tue, 16 Jan 2007 19:11:00 +0000
> From: "Brian Suda" <brian.suda at gmail.com>
>
> On 1/16/07, ☻Mike Samuel <msamuel at google.com> wrote:
> > I've been going over some unittests for extracting ICS from hcalendar
> > that Robert Bachmann pointed me at and I ran into a few places where I
> > disagree with the expected test results.
>
> Thanks for spotting these issues. I'll try to go through them step-by-step.
>
> > The tests I was looking at live at
> > http://hg.microformats.org/tests?cmd=manifest;manifest=8323e6e893f8f60ded243c97a060f4befd4a2b20;path=/hcalendar/
> >
> > There seem to be a few problems
> > 2) language omitted for X-WR-CALNAME.  Occurs in 15_calendar_xml_lang
> > and others.  The language is added to summary, location, and
> > description.  X-WR-CALNAME is an extension property so this isn't
> > required, but it is human readable.
>
> --- correct this is an X-PARAM, so it is not required. I'm not sure if
> this is more of a feature request or a bug? we have started a wiki
> page to track these sort of things. Please add the issue there if you
> would like and then we can scribble notes and figure out how to
> proceed.
>
> http://microformats.org/wiki/x2v-issues

done

> > 5) use of semicolon to separate value from name instead of colon,
> > especially for the ORGANIZER property.  Occurs in
> > calendar-threeday-conference and others.
>
> --- this a tricky one, there has not been a agreeded apon way to
> correctly mark-up things like ORGANIZER, SENT-TO, SENT-FROM. They (so
> far) have fallen very short of the 80/20 and no one has encountered a
> real-world problem were these were a 'deal-breaker' not to include. So
> this test should probably be either a) removed, or b) any offending
> properties removed.

I'll prepare a patch but since I don't seem to have explained 5 and 6 well:

$ grep -n ORGANIZER\; *
calendar-attachments.ics:16:ORGANIZER;MAILTO:jdoe at host1.com
calendar-threedayconference.ics:13:ORGANIZER;MAILTO:jsmith at host.com

I think these should read ORGANIZER:MAILTO:jdoe at host.com


> > 6) missing : after mailto in component-vevent-attendee-value

> --- ATTENDED is also similar to ORGANIZER, but you are correct MAILTO
> should be present.

$ egrep -ni 'mailto[^:]' *
component-vevent-attendee-value.ics:7:ATTENDEE;RSVP=TRUE:MAILTOjsmith at host1.com


> > Also, I think a few things are missing
> > 1) I see no mention of TZIDs.  This occurs in many tests.  This isn't
> > a problem for non-repeating events since the date format allows a
> > timezone offset, but for anything with an RRULE, the event needs to
> > specify which timezone it repeats in if it might extend past a
> > daylight savings time transition.
>
> --- yes, RRULE is incredible complex, clugy and isn't really been well
> documented or supported in hCalendar. There are several reasons for
> this. A) there has been discussion in the ICAL-BASIC to revamp RRULE.
> B) it isn't always supported well in calendaring applications. Much of
> the basic markup can also be achived in the RDATE. So in an interest
> of time, resources, and 80/20 RRULE has not been pressed very hard.
> And so far no one has complained - so our efforts have been focused on
> other aspected of microformats. Therefore TZIDs has not been addressed
> either. Much of the DTSTART/DTEND have been written in ISO format with
> the timezone offset and they simply converted to UTC and calendar
> applications then convert that UTC to the local timezone.



> > 2) I don't see any tests covering hcards, geos, or addr being used for
> > locations or attendees.  Is that not something I should be testing
> > for?
>
> Well, for locations an hCard is great, but it simply becomes a string
> in the iCal's LOCATION, so it isn't a requirement for hCalendar
> parsers to be aware of. Same goes for ADR. The GEO's map to the GEO
> property in iCalendar - so there should be a test for that at some
> point, but i am not aware of any calendaring app that does anything
> with that data (i would love to be proven wrong). As for ATTENDEES, i
> mentioned before about how the support for them has not been fully
> addressed, so at the moment i don't think tests are useful.
>
> Does this make sense? You might not be able to disclose anything, but
> if you are working in a real-world senario it would help to diagnose
> some of these issues and help clear-away any "non-issues" and help to
> focus on where things are broken between your app/mark-up and
> hcalendar encodings.

I'm not.  I'm just trying to understand hcalendars and saw some
language in the documentation that confused me and was hoping the
testcases might shed some light.


> We want to stay away from theoretical issues, and therefore we
> probably won't have a test for every single item in the RFC. The tests
> suite evolves and the format does, so i want to try to avoid "putting
> the cart before the horse" in some instances.

Fair enough.



> Any thoughts/comments?


On rrule, unless there's a compelling need for a single
representation, it seems that there's a spectrum.  At one end are
named holidays with hard to explain rules

<abbr class="rrule"
title="FREQ=YEARLY;BYYEARDAY=-43,-44,-45,-46,-47,-48,-49;BYDAY=WE">Buss
und Bettag</abbr>

and at the other, easily expressible rules that don't correspond to a holiday:

 <p class=rrule>Every
   <abbr class=interval title=2>second</abbr>
   <abbr class=freq abbr="weekly">week</abbr>
   on
   <abbr class=byday abbr="tu">Tuesday</abbr> and
   <abbr class=byday abbr="th">Thursday</abbr>
 </p>


On timezones, I think trying to embed VTIMEZONEs is a bad idea.  Most
VTIMEZONEs embedded in ical are incomplete or out of date.  I'd just
recommend using the Olson name, so <abbr
title="America/Los_Angeles">PDT</abbr>