[uf-dev] problems with testcases
ryan at technorati.com
Mon Jan 22 10:21:03 PST 2007
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
>> > 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-
>> > The tests I was looking at live at
>> > http://hg.microformats.org/tests?
>> > There seem to be a few problems
>> > 2) language omitted for X-WR-CALNAME. Occurs in
>> > 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
>> > 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[^:]' *
> 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
>> > 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
>> 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
>> either. Much of the DTSTART/DTEND have been written in ISO format
>> 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
>> 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
> 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
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
ryan at technorati.com
More information about the microformats-dev