[uf-dev] problems with testcases

[Brian Suda]

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
> 1) date and date-time properties missing VALUE=DATE and
> VALUE=DATE-TIME.  I believe RFC-2445 only requires it for one of them
> on.  See section 4.2.20.  Many examples in 2445 omit the value but
> that is being addressed in a draft.

--- this has been addressed and has been updated in the XSLTs (i'll
double check i committed them), but the tests have yet to reflect
this.

> 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

> 3) calendar-del.ics is missing the location specified in calendar-del.html
> 4) calendar-fragment is missing a couple events.

--- these should be updated accordingly

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

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

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

> 7) missing categories in component-vevent-del
> 8) unnecessary escaping of ; in content line values.  e.g. description
> in component-vevent-description-value-in-subelements-2.  RFC 2425
> defines a value as
>     valuespec =  text-list
>               / genericurl       ; from section 5 of RFC 1738
>               / date-list
>               / time-list
>               / date-time-list
>               / boolean
>               / integer-list
>               / float-list
>               / iana-valuespec
>
>    text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)
>
>    TEXT-LIST-CHAR = "\\" / "\," / "\n"
>                   / <any VALUE-CHAR except , or \ or newline>
>        ; Backslashes, newlines, and commas must be encoded.
>        ; \n or \N can be used to encode a newline.
> which neither requires nor allows escaping of semicolons.

--- this certainly looks like a correct interpretation!

> If people agree that these are wrong, I can go ahead and come up with a patch.

--- i don't see why not. Unfortunatly, hCalendar hasn't gotten nearly
as much love as hCard. So anything to bring it back into focus and
help move it forward would be a great help.

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

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.

Any thoughts/comments?

Thanks,
-brian

-- 
brian suda
http://suda.co.uk