http://icalvalid.cloudapp.net/?uri=http://jonudell.net/examples/sc_calendar_3325.ics
The error is: The calendar could not be parsed due to a serious error in the structure of the calendar: expecting "COLON", found ' '
It would be great to notice that this happens in the DESCRIPTION: field, and to point to examples of properly and improperly formed descriptions.
Ideally the tests included in the schema would be materialized as individual URIs in an HTML namespace, as targets for those pointers.
http://test.westborough.com/missing_eventprops_calendar.ics
The full test has 277 events missing one or both of DTSTART and DTEND, yet it scores 100 in the validator.
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-SchoolCenter/NONSGML Calendar v9.0EN
BEGIN:VTIMEZONE
TZID:CST
BEGIN:STANDARD
TZNAME:CST
TZOFFSETFROM:-0600
TZOFFSETTO:-0600
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:moc.segapbewloohcs.am.hguorobtsew|51848.5233#moc.segapbewloohcs.am.hguorobtsew|51848.5233
URL:http://westborough.ma.schoolwebpages.com/education/components/calend
ar/default.php?sectiondetailid=3325&rid=84815&viewType=detail&et=day
DTSTAMP:20091215T010635Z
LAST-MODIFIED:20090831T180330Z
CLASS:PUBLIC
DESCRIPTION:
END:VEVENT
BEGIN:VEVENT
UID:moc.segapbewloohcs.am.hguorobtsew|82848.5233#moc.segapbewloohcs.am.hguorobtsew|82848.5233
URL:http://westborough.ma.schoolwebpages.com/education/components/calend
ar/default.php?sectiondetailid=3325&rid=84828&viewType=detail&et=day
DTSTAMP:20091215T010638Z
LAST-MODIFIED:20090831T181303Z
DTEND:20100512T230000Z
CLASS:PUBLIC
DESCRIPTION:
END:VEVENT
END:VCALENDAR
Doug: I've started validation in a strict sense against RFC 2445. Here's a snippet:
; the following are optional,
; but MUST NOT occur more than once
class / created / description / dtstart / geo /
last-mod / location / organizer / priority /
dtstamp / seq / status / summary / transp /
uid / url / recurid /
; either 'dtend' or 'duration' may appear in
; a 'eventprop', but 'dtend' and 'duration'
; MUST NOT occur in the same 'eventprop'
dtend / duration /
So, the main problem is I haven't put together a validation test that goes a step further than this to say "Hey, even though it's technically OK to not have a DTSTART/DTEND, nearly all calendaring applications require them." Thoughts?
Jon Chuckle. You had this page locked as I was about to copy what I wrote over in the FriendFeed room (http://friendfeed.com/elmcity/96125f0c/need-some-help-with-busted-ical-file-i-m-crafting):
"This is quite interesting. You've omitted DTSTART and/or DTEND from all of those events. It turns out that's still valid per RFC2445, because all properties are optional. This is a good example of a case where the validator will want to pipe and say: "Did you /really/ mean that?"
Michael's example could serve as the test for that, eh?
http://www.blogto.com/events/ical/
DDay: expecting "COLON", found ' '
iCal4J: Error was: Error at line 18: Illegal property [ART DOLL GALLERY IN CANADA]
PRODID:PRODID:-blogTONONSGML Toronto Events V1.0//EN
X-WR-CALNAME:blogTO Toronto Events
X-ORIGINAL-URL:http://www.blogto.com/events/VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
BEGIN:VEVENT
DTSTAMP:20090920T000000
LAST-MODIFIED:20090920T000000
CREATED:20090920T000000
DTSTART:20090901T000000
DTEND:20090901T000000
UID:
SUMMARY: Grand Opening of Art Doll Gallery
LOCATION:The Distillery District
URL:http://www.blogto.com/events/12776
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Doll Collection presents the grand opening of the first ever =
art doll gallery in Canada=2E
CLASS:PRIVATE
CATEGORIES:
STATUS:CONFIRMED
PARTSTAT:ACCEPTED
END:VEVENT
The PRODID is strange, but I guess the empy UID is the dealbreaker?
Doug: Yes, looks like DDay.iCal is breaking on the empty UID. Technically, the parser shouldn't complain about this, however. I'll file a bug report and fix this ASAP. It fails in iCal4j due to the improper line folding on the DESCRIPTION property. It would fail in DDay.iCal as well if the parser wasn't already failing on the UID.
Doug: After some more digging, it appears that DDay.iCal wasn't failing on the empty UID at all. It looks to me like both DDay.iCal and iCal4j are failing on the improper line folding. I'd love to give a better error on this, but the parser isn't very error-friendly with line folding problems.
On a side note, I see a lot of ENCODING=QUOTED-PRINTABLE with the iCalendars you found in the wild, and I don't see any supporting documentation in RFC2445. They mention using Quoted-Printable as a transfer-level encoding, but not in a strict file-encoding sense, and certainly not per-parameter encoding. That's one of the things I'd like to have in icalvalid, is a test to ensure calendars only use universally-supported encodings.
Doug: More digging… QUOTED-PRINTABLE is actually declared in the vCalendar standard (i.e. iCalendar 1.0), and is a recommended form in version 1.0. The iCalendar standard (iCalendar 2.0, aka RFC 2445) doesn't really address it. In my mind, that means they're purposefully avoiding backwards-compatibility with this (which I believe is wise, considering how incomplete iCalendar 1.0 was). So, the question of the day is: Should DDay.iCal and/or iCal4j support backwards-compatibility with QUOTED-PRINTABLE-encoded properties?
For reference, here's the VCalendar 1.0 spec.
Doug: OK, so after reviewing the VCalendar 1.0 spec a bit further, it looks like even though the spec supports AND recommends QUOTED-PRINTABLE encoding on the per-property basis, it still follows proper line folding techniques. This means DDay.iCal and iCal4j are still correctly handling this — i.e. failing at the parser level. Unfortunately, Outlook 2003+ supports QUOTED-PRINTABLE with improper line folding, which means people may have a lot of incompatibilities between applications that don't like the line folding problems.
In any case, I suppose this just goes to show how much an iCalendar validator would have saved the producers of these calendars from compatibility issues.
http://www.mobilegeographics.com:81/ical/3988.ics
Are X- properties not supposed to be multiline?
Error: Error was: Error at line 6: Illegal property [ USES UNVERIFIED DATA]
Cause: Caused by: Illegal property [ USES UNVERIFIED DATA]
Context for line 6:
3: WR-CALNAME:Myrtle Beach, South Carolina 2009
4: PRODID:Mobile Geographics Tides 3988 2009
5: X-WR-CALDESC:Tide/current predictions for Myrtle Beach, South Carolina.
6: Uses unverified data; not for use in navigation. Includes times/values of
7: high/low tides, max ebb/flood currents, times of sunrise/sunset/slack,
8: and dates of moon phases.
Doug: No, any item contained in a content line can (and should) be "folded" using this technique. This should not be giving an error. Is it giving an error in both ical4j and DDay.iCal?
Jon: I thought so. But testing with DDay.iCal outside the aggregator, it seems OK. Must have been a different problem. I'll reset Myrtle Beach and have it try again. Thanks Doug!
This source, found by Dave Slusher, is really cool, BTW. Tides: What a cool thing to put onto a community calendar!
Jon: PS: Turns out to have been network related. That server makes .NET complain about "protocol violation" — explanation here, http://www.cookcomputing.com/blog/archives/000556.html, I'm trying the various solutions now.
Doug: Sounds great, let me know if I can do anything else.
elmcity generated feeds
Example: http://elmcity.cloudapp.net/services/fallschurchcals/ics
I recently made some changes to the DDay.iCal-based service that generates ICS for the combined feeds of each location processed by the aggregator. We noticed problems described here: http://friendfeed.com/elmcity/fbcb2591/elmcity-feed-for-falls-church-is-very-useful. ical4j and DDay.iCal both parse the feed successfully, but not all calendar programs seem to. Am investigating why, suggestions welcome.
Doug: A quick review - the May 21, 2009 7:30am event titled "Breakfast Connection" exists in the Google calendar, but not in the URL listed above. Also, it looks like the Google calendar has duplicate entries all over the place. Do you know which calendar feed appears to be "accurate" (if any)?
Jon: Yes, they're out of sync. GCal is showing the last version it could read. The dupes there are a separate problem with the Eventful API. The version I consider accurate is: http://elmcity.cloudapp.net/services/fallschurchcals/ics, also rendered as http://elmcity.cloudapp.net/services/fallschurchcals/html, http://elmcity.cloudapp.net/services/fallschurchcals/xml, http://elmcity.cloudapp.net/services/fallschurchcals/json
Jon: Found the problem:
curl http://elmcity.cloudapp.net/services/fallschurchcals/ics | grep UID | wc
222
curl http://elmcity.cloudapp.net/services/fallschurchcals/ics | grep UID | uniq | wc
580
I goofed generating UIDs. This highlights an interesting test case, eh?
Gilsum, NH
http://www.google.com/calendar/ical/gilsumrocks@gmail.com/public/basic.ics
BEGIN:VEVENT
DTSTART;TZID=America/New_York:20090302T181500
DTEND;TZID=America/New_York:20090302T193000
RRULE:FREQ=WEEKLY;BYDAY=MO;UNTIL=20090330T221500Z;WKST=SU
DTSTAMP:20090309T231544Z
UID:moc.elgoog|s1g7gei0534mma1dmciikg21m2#moc.elgoog|s1g7gei0534mma1dmciikg21m2
CLASS:PUBLIC
CREATED:00001231T000000Z
DESCRIPTION:Open to all children. Free! Sponsored by the Gilsum Recreation
Commission.
LAST-MODIFIED:20090305T022216Z
LOCATION:Gilsum Elementary School and Community Center
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Youth Basketball
TRANSP:OPAQUE
END:VEVENT
OK in iCal4J.
DDay.iCal: ValueError: Year, Month, Day params describe unrepresentable DateTime.
Doug: The .NET Framework can only represent DateTime values between January 1, 0001 and December 31, 9999. Since this is represented in the year "0000", it is slightly out of the date/time range that the .NET Framework supports.
Jon: The spec sez:
Property Name: CREATED
Purpose: This property specifies the date and time that the calendar
information was created by the calendar user agent in the calendar
store.
On the one hand it is silly to claim that the information was created in the year zero. OTOH, the spec doesn't seem to preclude it, so in this case DDay.iCal is arguably penalizing the user for a limitation of the .NET Framework.
Ideally a validator would warn the user that the date is kind of weird, and suggest something more reasonable, but not actually fail.
Since DDay.iCal cannot accommodate the value given, could/should it modify the value to the earliest acceptable one, and insert a COMMENT field explaining that it did that?
Doug: I think simply mentioning that the date range must be from January 1, 0001 to December 31, 9999 when it fails to parse is sufficient to ensure people stay within a reasonable time frame. Realistically the document was not created in year "0000", so semantically this presents a problem anyhow. I don't think the "penalizing" that occurs here is really out of bounds.
Jon: Yeah, fair enough. If 10 millenia isn't enough for you, well, get a life :-)
Michigan Gourmet Club
https://ross.ecampusgroups.com/ical/ical_club_7423.ics
BEGIN:VEVENT
DTSTAMP:20090207T142943
LAST-MODIFIED:20090207T142943
CREATED:20090111T120000
CATEGORIES:GOURMET
DTSTART:20090111T220000Z
DTEND:20090112T000000Z
UID:48c1f4a6-1da2-102c-ac69-00e04cf077a2272009_2:29:moc.spuorgsupmace|MP_34#moc.spuorgsupmace|MP_34
SUMMARY;ENCODING=QUOTED-PRINTABLE:Wild Game Follow-Up
LOCATION:
URL:https://ross-gourmet.ecampusgroups.com/rsvp.aspx?event_uid=48c1f4a6-1da2-102c-ac69-00e04cf077a2
DESCRIPTION:Wild Game Follow-Up\n\n—-\nRSVP: https://ross-gourmet.ecampusgroups.com/rsvp.aspx?event_uid=48c1f4a6-1da2-102c-ac69-00e04cf077a2
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20090207T142944
LAST-MODIFIED:20090207T142944
CREATED:20090128T120000
CATEGORIES:GOURMET
DTSTART:20090128T230000Z
DTEND:20090129T010000Z
UID:9aff2740-37b8-102c-ac69-00e04cf077a2272009_2:29:moc.spuorgsupmace|MP_44#moc.spuorgsupmace|MP_44
SUMMARY;ENCODING=QUOTED-PRINTABLE:Happy Hour at the Earle
LOCATION:The Earle, 121 West Washington, , Ann Arbor, MI, 48104
URL:https://ross-gourmet.ecampusgroups.com/rsvp.aspx?event_uid=9aff2740-37b8-102c-ac69-00e04cf077a2
DESCRIPTION:Happy Hour at the Earle\nThe Earle
121 West Washington
\nAnn Arbor, MI 48104\n—-\nRSVP: https://ross-gourmet.ecampusgroups.com/rsvp.aspx?event_uid=9aff2740-37b8-102c-ac69-00e04cf077a2
END:VEVENT
Both iCal4J and DDay.iCal choke on 121 West Washington. DESCRIPTION needs to be either all one long line, or preferably broken lines with leading whitespace 2nd and following.
Explaining this to Ross, who runs this Drupal site, will not do him any good. So I'm going to try to compensate with pre-processing. And will point this out to the Drupal folks.
Hmm. Maybe there is a workaround for Ross. He has another Drupal iCalendar feed that works:
https://ross.ecampusgroups.com/ical/ical_club_1657.ics
Given this information, he might be able to figure out what borked the Gourmet feed and write its description differently.
Doug: I personally don't believe any iCalendar parser will work well with the above item. Logically speaking about parsing issues such as these, there are few options available to automatically detect things like this. I would consider this the fault of whoever generated the feed.
Jon: I agree. In these (common) cases where text formatting in DESCRIPTION goes wrong, I am tempted to use pre-processing in my aggregator to try to fix it, and if successful, to insert a COMMENT explaining that I did that. Perhaps a validator could do the same. So in this case it would be forced to report an error instead of a warning. But it could show the user what a successful reformatting would look like.
Meetup DC
iCal4J doesn't like this, but DDay.iCal is OK with it.
URL: http://www.meetup.com/cities/us/dc/washington/events/ical
Error: Error was: Error at line 11: Illegal property [ \N\NI'VE STARTED THIS BASED ON THE IDEA OF JELLY\, WHICH ALLOWS PEOPLE WHO ]
Cause: Caused by: Illegal property [ \N\NI'VE STARTED THIS BASED ON THE IDEA OF JELLY\, WHICH ALLOWS PEOPLE WHO ]
Context for line 11:
8: BEGIN:VEVENT
9: SUMMARY:Ebenezer Cafe
10: DESCRIPTION:Telecommuters Meetups > The DC Metro Telecommuters Meetup Group
11: \n\nI've started this based on the idea of Jelly\, which allows people who
12: work from home to have an office-like setting where you can cowork with oth
13: ers\, have a bit of social time\, or just enjoy getting away from your cat
14: for a few hours (sorry to any offende\n\nWashington\, DC 20002 - USA\n\nMo
Localist
http://baltimore.localist.com/calendar/ics
iCal4J has one complaint:
Error: Error was: Error at line 122: Unparseable date: "20090331"
Cause: Caused by: Unparseable date: "20090331"
Context for line 122:
119: nhttp:www.wodnb.com\nhttp:www.formationrecords.com\n\nhttp:www.shorty
120: sbaltimore.com\nhttp:www.myspace.com/shortysbaltimore\nwww.bmcon.org\nwww
121: .myspace.com/bmoremusic
122: DTSTART:20090331
123: DTSTAMP:20090406T085200
124: LOCATION:Shorty's Martini Bar & Lounge
125: END:VEVENT
DDay.iCal has a different complaint:
Error loading iCalendar: Geo.Parse cannot parse the value '38.8878738\;-77.4407031' because it is not formatted correctly.
GEO:39.281734\;-76.581864
Doug: The first error that occurs in iCal4J is that DTSTART did not specify VALUE=DATE. The parser was then unable to recognize the date (not datetime) value that followed. As for the second error - the '\' character is illegal according to RFC 2445. I suppose in DDay.iCal the error message could provide what the format should look like, then in the validation tool provide that message to the user?
Jon:
The spec:
Value Type: The default value type is DATE-TIME. The time value MUST
be one of the forms defined for the DATE-TIME value type. The value
type can be set to a DATE value type.
OK. I understand now. DATE-TIME is the default, if supplying only a DATE, must override with VALUE=DATE. Thanks Doug.
"As for the second error - the '\' character is illegal according to RFC 2445. I suppose in DDay.iCal the error message could provide what the format should look like, then in the validation tool provide that message to the user?"
Or at least explain what went wrong. You have told me here that "the '\' character is illegal according to RFC 2445" but although I might guess that from "Geo.Parse cannot parse the value '38.8878738\;-77.4407031' because it is not formatted correctly" I don't really know without investigating.
Doug: With the missing VALUE=DATE, the parsing engine should be able to allow this. This should instead provide a validation error indicating that VALUE=DATE must be present on their date/time property. With the "Geo.Parse" error, yes, I'll add some additional explanation when it fails to make it clearer what's going on.
Jon: "With the missing VALUE=DATE, the parsing engine should be able to allow this."
For those of us not very adept at interpreting spec-speak, are you deriving "should be able to allow" from this paragraph?
Value Type: The default value type is DATE-TIME. The time value MUST
be one of the forms defined for the DATE-TIME value type. The value
type can be set to a DATE value type.
My understanding of that para:
1. "The default value type is DATE-TIME." All 3 of the forms mentioned in 4.3.5 of the spec include a TIME value.
2. "The time value MUST be one of the forms defined for the DATE-TIME value type." Given that DATE-TIME is defined in 4.3.5, this stipulation doesn't seem to add any new information, but moving on…
3. "The value type can be set to a DATE value type." Using VALUE=DATE as you suggested, correct? Or are you suggesting that DTSTART:20090331 could be understood by the parser to mean:
DTSTART:20090331T000000
or
DTSTART;VALUE=20090331 ?
Doug: Lol, I wasn't intending to use "spec-speak" when I said "should be able to allow," but I was merely suggesting that it's not difficult to have your parser "roll with the punches" here. As far as the spec goes, DTSTART states:
dtstart = "DTSTART" dtstparam ":" dtstval CRLF
dtstparam = *(
; the following are optional,
; but MUST NOT occur more than once
(";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
(";" tzidparam) /
; the following is optional,
; and MAY occur more than once
*(";" xparam)
)
This suggests that the VALUE=DATE is optional, as per the actual parsing of the iCalendar file. However, in section 4.3 it states:
"The properties in an iCalendar object are strongly typed. The
definition of each property restricts the value to be one of the
value data types, or simply value types, defined in this section. The
value type for a property will either be specified implicitly as the
default value type or will be explicitly specified with the "VALUE"
parameter. If the value type of a property is one of the alternate
valid types, then it MUST be explicitly specified with the "VALUE"
parameter."
Hence, the parser SHOULD be able to handle it (not MUST), but since the value is not the default value type for DTSTART, the spec states it "MUST be explicitly specified with the "VALUE"
parameter."
Jon:
Hmm. I had overlooked:
dtstval = date-time / date
That suggests you can do this:
DTSTART:20090331T000000
Or this:
DTSTART:20090331
Without any warning or error in either case. Not so?
Doug: No, it should provide at least a warning (but probably an error). As you noted above for DTSTART, "The default value type is DATE-TIME." According to Section 4.3 it states that if you're using a value type other than the default value type, "it MUST be explicitly specified with the 'VALUE' parameter." Therefore, this is incorrect:
DTSTART:20090331
You must instead do this:
DTSTART;VALUE=DATE:20090331
However, this is correct (because it is a date-time type):
DTSTART:20090331T000000
That said, a validation engine should be able to roll with the punches here and accept the value anyway with a warning/error that it does not conform to the standard and may cause problems on some systems.
Ben: iCal4j will parse this, however you need to enable the "relaxed parsing" Compatibility Hint. Current behaviour will convert the specified date value to a date-time instance, however I'm considering changing this to added the missing "VALUE=DATE" parameter and leaving the date intact..
Jon:
This narrative needs to be refactored :-)
But anyway, the curator for Baltimore, who is using this feed, reminded me that the issue is unresolved. When I rechecked, I reminded myself that DDay.iCal is OK with the DTSTART as is, but not the GEO. Until I can contact the author of the software that writes that feed, I'm preprocessing to change all occurrences of "\;" to just ";" — and that appears to work. But…after I strip out the DTSTARTs that iCal4J doesn't like, it's happy with "\;" which I think is wrong. It's OK to escape a semicolon in a TEXT property, but not in a GEO (or other param=value) property, correct?
Projo the Beat
iCal4J is OK with it. DDay.iCal complains:
Error loading iCalendar: expecting "END", found 'VERSION'
BEGIN:VCALENDAR
BEGIN:VTIMEZONE
TZID:US/Eastern
X-LIC-LOCATION:US/Eastern
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700405T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
PRODID:Zvents Ical
BEGIN:X-CALCONNECT-LOCATION
X-CALCONNECT-NAME:Providence Performing Arts Center
X-CALCONNECT-ADR-REGION:RI
X-CALCONNECT-NAME-CITY:Providence
X-CALCONNECT-NAME-STREET:220 Weybosset St.
X-CALCONNECT-LOCATION-ID:moc.stnevz|55671#moc.stnevz|55671
X-CALCONNECT-ADR-POSTAL-CODE:02903
X-CALCONNECT-ADR-COUNTRY:United States
END:X-CALCONNECT-LOCATION
BEGIN:VEVENT
SEQUENCE:0
URL;VALUE=URI:http://www.ppacri.org/schedules/index.cfm
CLASS:PUBLIC
PRIORITY:5
UID:84221069:zvents.com
DESCRIPTION:http://www.zvents.com/providence-ri/events/show/84221069-david-
sedaris
SUMMARY:David Sedaris
DTSTART;TZID=US/Eastern:20090406T200000
TRANSP:OPAQUE
DTSTAMP:20090406T132803
LOCATION;X-CALCONNECT-LOCATION-ID=moc.stnevz|55671#moc.stnevz|55671:Providence Performing Ar
ts Center 220 Weybosset St. Providence RI United States
END:VEVENT
Doug: Once again, in RFC 2445, calendar properties must be specified before calendar components. This particular feed is "mix and matching" calendar components and properties. It would be nice if a validator noticed this and pointed that out, however.
Jon: Exactly. And for now, this document will serve as a proxy for the validator. In a day or so, if somebody is searching for:
Error loading iCalendar: expecting "END", found 'VERSION'
they'll land here, and read your explanation. It's an important first step!
What Grows on in Rhode Island
iCal4J complains, DDay.iCal is OK with it.
http://www.trumba.com/calendars/what-grows-on-in-Rhode-Island.ics
Error: Error was: Error at line 43: Invalid parameter name: NAME
Cause: Caused by: Invalid parameter name: NAME
Context for line 43:
40: CATEGORIES:Service of Providential Gardener ~ http://www.whatgrowsonri.c
41: om,Art &\; Photography ~ Exhibits\, Workshops
42: DTSTAMP:20090215T181200Z
43: X-TRUMBA-CUSTOMFIELD;NAME="Keywords";ID=8318;TYPE=SingleLine:Art Show
44: X-TRUMBA-CUSTOMFIELD;NAME="Additional Info";ID=8089;TYPE=MultiLine:Art O
45: pening will be March 1\, 2009 from 1-3pm
46: X-TRUMBA-CUSTOMFIELD;NAME="Audubon Location";ID=11181;TYPE=Enumeration:A
Jon:
xparam =x-name "=" param-value *("," param-value)
x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
So it should maybe rather be?
X-TRUMBA-CUSTOMFIELD;X-NAME="Keywords";X-ID=8318;X-TYPE=SingleLine:Art Show
or
or X-TRUMBA-NAME, X-TRUMBA-TYPE
DDay.iCal does not refuse to load this feed. Should it?
Doug: Technically, yes; realistically, no. The parser can and should handle this just fine - this, once again, should be a validation error warning that "parameters of custom properties must begin with 'X-', or they may not work with all systems.", or something along those lines. Once the icalvalid is further along, this should be one of the tests that it provides to consumers.
Jon: OK. As per http://www.feedvalidator.org/docs/ I guess we'll want to start two new groupings here, one to collect ValidationErrors and one to collect ValidationWarnings. This, I believe you are indicating, would be a Warning but not an Error? That sounds right to me.
Doug: Yep, I'd put that in the "warning" group.
Ben: Again, iCal4j will parse it when the "relaxed parsing" Compatibility Hint is enabled. By default iCal4j is as strict as possible, but Compatibility Hints allow for relaxing of commonly broken rules.
Jon: I found http://wiki.modularity.net.au/ical4j/index.php?title=Compatibility. Is there elsewhere a description of what the relaxed mode allows? That'd help us develop a taxonomy of errors vs warnings.
Ben: Yup, this is all I have documented on the wiki so far. Some more information on what the Compatibility Hints do is available in my recent presentation at CalConnect (slides 9-15): http://calconnect.org/presentations/iCal4j_Calconnect.pdf
Carnation Library
http://eventinfo.kcls.org/evanced/lib/eventsxml.asp?dm=ical&lib=7&alltime=1&nd=60
iCal4J complains: Error was: Error at line 12: Illegal property [TITLE]
DDay.iCal is OK with it.
BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:e-vanced event management system
X-WR-CALNAME;VALUE=TEXT:Upcoming library events at Carnation Library
X-WR-CALDESC;VALUE=TEXT:Upcoming library events at Carnation Library
VERSION:2.0
BEGIN:VEVENT
UID:http://eventinfo.kcls.org/evanced/lib/eventsignup.asp?ID=71954
DTSTAMP:20090404T171308Z
DTSTART:20090421T223000Z
DTEND:20090422T003000Z
TITLE;ENCODING=QUOTED-PRINTABLE:Study Zone
SUMMARY;ENCODING=QUOTED-PRINTABLE:Study Zone
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Drop-in during scheduled Study Zone hours for free homework help from volunteer tutors. Monday 5:30-7:30pm\nTuesday 3:30-5:30pm\nWednesday, 3:30-5:30pm
LOCATION:Carnation Library at Meeting Room
URL:http://eventinfo.kcls.org/evanced/lib/eventsignup.asp?ID=71954
CATEGORIES:Study Zone (K-12)
END:VEVENT
BEGIN:VEVENT
Doug: I think this is the same issue with Compatibility Hints in iCal4J. "TITLE" is a non-standard property - to be technically correct it should be "X-TITLE".
