[uf-dev] problems with testcases

[Ryan King]

On Jan 19, 2007, at 5:22 PM, ☻Mike Samuel wrote:

> 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

Agreed. Document on http://microformats.org/wiki/test-issues


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

Yeah, bug. Also documented.

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

Please speak up any time you see something confusing, it will help us  
provide better documentation.

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

I agree that there are different use-cases for rrule, which could use  
different markup.

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

I certainly agree that we shouldn't even allow embedded timezones.  
I've looked into finding a standard, normative list of timezones  
before, but was unable find anything useful. Is there a normative  
reference for Olson names (and what they mean)? or is it an informal  
list?

thanks,
ryan
--
Ryan King
ryan at technorati.com