Re: [icalendar] icalendar XML issues

[Mike Douglass <[e-mail]>]

Hi Cyrus.

Thanks for the comments and corrections. We'll probably post a corrected 
schema and we'll certainly be taking your comments and corrections into 
account.

On 04/14/2012 11:01 AM, Cyrus Harmon wrote:
> Hello icalendar folks,
>
> I've been working on an iCalendar/VCARD parsing library and have run across some issues (not covered by the existing errata) in the Relax NG spec in<http://tools.ietf.org/html/rfc632>.
>
> 1. T in patttern-duration and lack of operator precedence.
>
> My reading of<http://www.w3.org/TR/xmlschema11-2/#regexs>, and of section 3.3.6, and of section 2 of<http://relaxng.org/compact-20021121.html>  suggests that the given definition of duration is wrong:
>
>> # 3.3.6 DURATION
>>
>> pattern-duration = xsd:string {
>>      pattern = "(+|-)?P(\d+W)|(\d+D)?"
>>              ~ "(T(\d+H(\d+M)?(\d+S)?)|"
>>              ~   "(\d+M(\d+S)?)|"
>>              ~   "(\d+S))?"
>> }
> I think the T needs to be explicitly grouped around the three HMS/MS/S forms as follows (and, also, the + character needs to be explicitly escaped, assuming that allows for specification of +P3W, e.g.):
>
>> @@ -221,10 +221,10 @@ value-date-time = element date-time {
>>   # 3.3.6 DURATION
>>
>>   pattern-duration = xsd:string {
>> -    pattern = "(+|-)?P(\d+W)|(\d+D)?"
>> -            ~ "(T(\d+H(\d+M)?(\d+S)?)|"
>> -            ~   "(\d+M(\d+S)?)|"
>> -            ~   "(\d+S))?"
>> +    pattern = "(\+|-)?P((\d+W)|(\d+D))?"
>> +            ~ "(T((\d+H(\d+M)?(\d+S)?)|"
>> +            ~    "(\d+M(\d+S)?)|"
>> +            ~    "(\d+S)))?"
>>   }
>>
>>   value-duration = element duration {
> FWIW, perl's regex syntax accepts the former definition, but only applies to the T to the HMS form.
>
> 2. type-date, type-date-time?
>
> I only see single references to type-date and type-date-time.
>
>> type-until = element until {
>>      type-date |
>>      type-date-time
>> }
>>
> Perhaps those should be value-date and value-date-time?
>
>> @@ -290,8 +290,8 @@ type-freq = element freq {
>>   }
>>
>>   type-until = element until {
>> -    type-date |
>> -    type-date-time
>> +    value-date |
>> +    value-date-time
>>   }
>>
>>   type-count = element count {
>>
>
> 3. Bogus Grammar/regex
>
> As discussed in the email message here:<http://lists.common-lisp.net/pipermail/cxml-devel/2012-March/000553.html>
>
>> type-byday = element byday {
>>     xsd:integer?,
>>     type-weekday
>> }
> This mixing of grammar and regex matching in the same node isn't allowed.
>
>> @@ -321,8 +321,7 @@ type-weekday = (
>>   )
>>
>>   type-byday = element byday {
>> -    xsd:integer?,
>> -    type-weekday
>> +    xsd:string { pattern='-?[0-9]+(SU|MO|TU|WE|TH|FR|SA)' }
>>   }
>>
>>   type-bymonthday = element bymonthday {
>>
> Fixes the problem.
>
> 4. The following plus needs to be explicitly escaped:
>
>> @@ -370,7 +369,7 @@ value-uri = element uri {
>>   # 3.3.14 UTC-OFFSET
>>
>>   value-utc-offset = element utc-offset {
>> -    xsd:string { pattern = "(+|-)\d\d:\d\d(:\d\d)?" }
>> +    xsd:string { pattern = "(\+|-)\d\d:\d\d(:\d\d)?" }
>>   }
>>
>>   # UNKNOWN
>>
>
> 5. tzuurl is a typo, it should be tzurl. And, while we're at it, the lack of operator precedence rears it's ugly head again below and can't that be written more simply as follows:
>
>> @@ -567,12 +566,10 @@ component-vtimezone = element vtimezone {
>>           property-tzid&
>>
>>           property-last-mod?&
>> -        property-tzuurl?
>> +        property-tzurl?
>>       },
>>       element components {
>> -        (component-standard | component-daylight)&
>> -        component-standard*&
>> -        component-daylight*
>> +        (component-standard | component-daylight )+
>>       }
>>   }
>>
> 6. Lack of operator precedence rears its ugly head again in property-attach.
>
>> @@ -684,7 +681,7 @@ property-attach = element attach {
>>           encodingparam?
>>       }?,
>>
>> -    value-uri | value-binary
>> +    ( value-uri | value-binary )
>>   }
>>
>>   # 3.8.1.2 Categories
>>
> 7. In property-categories, there is a bogus&  -- there's nothing to interleave!
>
>> @@ -692,7 +689,7 @@ property-attach = element attach {
>>   property-categories = element categories {
>>
>>       element parameters {
>> -        languageparam?&
>> +        languageparam?
>>       }?,
>>
>>       value-text+
>>
> 8. More lack of operator precedence problems. The following all need explicit grouping of value-date-time and value-date:
>
>> @@ -855,8 +852,7 @@ property-dtend = element dtend {
>>           tzidparam?
>>       }?,
>>
>> -    value-date-time |
>> -    value-date
>> +    ( value-date-time | value-date )
>>   }
>>
>>   # 3.8.2.3 Date/Time Due
>> @@ -867,8 +863,7 @@ property-due = element due {
>>           tzidparam?
>>       }?,
>>
>> -    value-date-time |
>> -    value-date
>> +    ( value-date-time | value-date )
>>   }
>>
>>   # 3.8.2.4 Date/Time Start
>> @@ -879,8 +874,7 @@ property-dtstart = element dtstart {
>>           tzidparam?
>>       }?,
>>
>> -    value-date-time |
>> -    value-date
>> +    ( value-date-time | value-date )
>>   }
>>
>>   # 3.8.2.5 Duration
>> @@ -1023,8 +1017,7 @@ property-recurid = element recurrence-id {
>>           rangeparam?
>>       }?,
>>
>> -    value-date-time |
>> -    value-date
>> +    ( value-date-time | value-date )
>>   }
>>
>>   # 3.8.4.5 Related-To
>> @@ -1066,8 +1059,7 @@ property-exdate = element exdate {
>>           tzidparam?
>>       }?,
>>
>> -    value-date-time+ |
>> -    value-date+
>> +    ( value-date-time | value-date)+
>>   }
>>
>>   # 3.8.5.2 Recurrence Date/Times
>>
> 9. One more grouping -- finally, property-rdate needs value-date-time, value-date and value-period grouped:
>
>> @@ -1078,9 +1070,9 @@ property-rdate = element rdate {
>>           tzidparam?
>>       }?,
>>
>> -    value-date-time+ |
>> -    value-date+ |
>> -    value-period+
>> +    ( value-date-time |
>> +    value-date |
>> +    value-period )+
>>   }
>>
>>   # 3.8.5.3 Recurrence Rule
>>
>
> I hope this is the right place to bring these issues up. I'm happy to submit errata if that's the right thing to do. The final (?) RNC schema can be found here:<https://github.com/slyrus/soiree/blob/master/icalendar-2.0.rnc>.
>
> Thanks for all of the work on the iCalendar XML spec,
>
> Cyrus
>
>
>
> _______________________________________________
> icalendar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/icalendar