[uf-dev] problems with testcases

Mon Jan 22 11:45:00 PST 2007

On 1/22/07, Ryan King <ryan at technorati.com> wrote:
> 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?

The cldr project ( http://unicode.org/cldr/repository_access.html )
has an excellent mapping of colloquial names to Olson names, per
locale.  It also has mappings from commonly used IDs to Olson names in
supplemental/supplementalMetadata.xml

The tzinfo database ( http://www.twinsun.com/tz/tz-link.htm ) has
definitions for all the Olson identifiers, and there are compilers
from the tzinfo format to a variety of other formats, including
VTIMEZONE.

> thanks,
> ryan
> --
> Ryan King
> ryan at technorati.com
>
>
>
>
> _______________________________________________
> microformats-dev mailing list
> microformats-dev at microformats.org
> http://microformats.org/mailman/listinfo/microformats-dev
>