From thomas@koch.ro Mon Apr 9 03:25:18 2012 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AACB21F8663; Mon, 9 Apr 2012 03:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.696 X-Spam-Level: ** X-Spam-Status: No, score=2.696 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RO=1.235, HELO_IS_SMALL6=0.556, HOST_EQ_RO=0.904] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSTf7hd9hZzH; Mon, 9 Apr 2012 03:25:17 -0700 (PDT) Received: from koch.ro (koch.ro [88.198.2.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83621F865D; Mon, 9 Apr 2012 03:25:16 -0700 (PDT) Received: from [78.96.158.150] (helo=x121e.localnet) by koch.ro with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHBmV-00053r-Ug; Mon, 09 Apr 2012 12:25:08 +0200 From: Thomas Koch To: atom-protocol@imc.org, caldav@ietf.org, vcarddav@ietf.org, caldeveloper-l@lists.calconnect.org, icalendar@ietf.org, "opensocial-community" , rest-discuss@yahoogroups.com, users@jersey.java.net Date: Mon, 9 Apr 2012 12:25:00 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201204091225.01447.thomas@koch.ro> Subject: [icalendar] Bachelor Thesis on a RESTful API for a Groupware/OpenSocial X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: thomas@koch.ro List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:25:18 -0000 Hi, please allow me to bring to your attention my just finished bachelor thesis on the subject of the design of a restful API to be useful for a Groupware or the person related informations of OpenSocial. I'd appreciate any feedback. The text will be available under a free license after I received the mark for it. Points that might be of special interest for (some of) you: - a modernized design of CalAtom/CardAtom[1] without the need for a new "feature" property - efficient synchronization of collections with restful HTTP - properties of vCard useful (or missing) for OpenSocial - use of OpenSearch for reports - use of nice small value objects replacing some functionality of Jersey (Java REST framework) - a "resource facade" framework to support multiple "views" or media types of the same data - a minimal implementation of an atom pub server on top of Jersey [1] http://robubu.com/?cat=2 http://github.com/thkoch2001/bachelor- thesis/blob/master/latex/restful_groupware.pdf Please be forgiving with the quality of my writing. It's a thesis written under time pressure and other constraints and I'm not a writer. Best regards, Thomas Koch, http://www.koch.ro From quillaud@gmail.com Thu Apr 12 13:10:45 2012 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB58D21F8714 for ; Thu, 12 Apr 2012 13:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlTbVeiq+2Vm for ; Thu, 12 Apr 2012 13:10:45 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57121F8704 for ; Thu, 12 Apr 2012 13:10:44 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1607916wgb.13 for ; Thu, 12 Apr 2012 13:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Hb+UQtu2tvBofI+UcYNGfkF/Fq8LmpnuXa5gfZuyBvU=; b=dQ6pNyNQ5NtjFXIOZhHf0JP7PENQOHeeVeKv4lhqb3Jro7Kgm5w2HvpM0B5zaWeC1B SavfvM6/RCekV697P2qbWg+lApbbXadGUgwMqmKIoWzukrKYoL+mOHEUgW4qtX3pQt1G d/E4tUIS7NuT2qmRlmh3JLdUV1yDsCYSdcBHXP/7xqXeHAE1fR+xQQVVGG7qRrxIE4PC L05uNqfJ3PpVIJlGAuo28/YwndrTwNa9bf70Ng7MvtOdyXtb1KzQYYW6jEYqzXT/CthG n9ARh9xVKiNlgAkgObDDvvm2eBkVhurV1Sj4BjzAUwTi1k+b7LIB4yDpzHdDIIvb+ZF7 /zUw== MIME-Version: 1.0 Received: by 10.216.132.151 with SMTP id o23mr2169292wei.120.1334261443808; Thu, 12 Apr 2012 13:10:43 -0700 (PDT) Sender: quillaud@gmail.com Received: by 10.223.69.142 with HTTP; Thu, 12 Apr 2012 13:10:43 -0700 (PDT) In-Reply-To: <4F398E3E.9090704@stpeter.im> References: <4F398E3E.9090704@stpeter.im> Date: Thu, 12 Apr 2012 22:10:43 +0200 X-Google-Sender-Auth: bqD_mXrMrL0_yFA6sbgiDttcAUw Message-ID: From: Arnaud Quillaud To: icalendar@ietf.org, iana@iana.org Content-Type: multipart/alternative; boundary=0016e6d9a1f9654da704bd80f34e Cc: Pete Resnick , Arnaud Quillaud , Peter Saint-Andre Subject: Re: [icalendar] iCalendar element registrations for CalDAV Scheduling X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:10:45 -0000 --0016e6d9a1f9654da704bd80f34e Content-Type: text/plain; charset=ISO-8859-1 Hello, I have been temporarily appointed by Peter Saint-Andre to review the registry changes mentioned below. They all look good to me. I have just a rather cosmetic suggestion regarding the examples in Section 7.3: << ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com >> It might have been better to show the first example without double quotes around the parameter value, i.e. << ATTENDEE;SCHEDULE-STATUS=2.0:mailto:bernard@example.com ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com >> since the syntax allows both. Probably not worth a new version of the draft... Arnaud Quillaud > > -------- Original Message -------- > Subject: iCalendar element registrations for CalDAV Scheduling > Date: Fri, 10 Feb 2012 14:43:27 -0500 > From: Cyrus Daboo > To: icalendar@ietf.org, iana@iana.org > CC: Peter Saint-Andre > > Hi, > This is to request a review of the new iCalendar elements defined in > draft-desruisseaux-caldav-sched-10, as required by RFC 5545. > > The new elements are new property parameters (to be used on ATTENDEE and > ORGANIZER properties), a new set of REQUEST-STATUS codes, and two new > parameter value registries for two of the new parameters. All documented in > Section 16 of the draft. > > Note, that since the designated experts for this registry are both authors > of this draft, we will be recusing ourselves from the review process. The > responsible AD, Peter Saint-Andre, will appoint a stand-in for the review > process. > > -- > Cyrus Daboo > > --0016e6d9a1f9654da704bd80f34e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I have been temporarily appointed by Peter Saint-= Andre to review the registry changes mentioned below.

<= div>They all look good to me.=A0I have just a rather cosmetic s= uggestion regarding the examples in Section 7.3: <<

ATTENDEE;SCHEDULE-STATU=
S=3D"2.0":mailto:bernard@e=
xample.com
ATTENDEE;SCHEDULE-STATUS=3D"2.0,2.4":mailto:cyrus@example.com
>>

It might have been better to show the first exam= ple without double quotes around the parameter value, i.e.

<<

ATTENDEE;SCHE=
DULE-STATUS=3D2.0:mailto:bernard@exa=
mple.com
ATTENDEE;SCHEDULE-STATUS=3D"2.0,2.4":mailto:cyrus@example.com

>>

since the syntax allows both. Probably= not worth a new version of the draft...

Arnaud Quillaud
=




-------- Original Message --------
Subject: iCalendar element registrations for CalDAV Scheduling
Date: Fri, 10 Feb 2012 14:43:27 -0500
From: Cyrus Daboo <cyrus@daboo.name<= /a>>
To: icalendar@ietf.org, iana@iana.org
CC: Peter Saint-Andre <stpeter@stp= eter.im>

Hi,
This is to request a review of the new iCalendar elements defined in
draft-desruisseaux-caldav-sched-10, as required by RFC 5545.

The new elements are new property parameters (to be used on ATTENDEE and ORGANIZER properties), a new set of REQUEST-STATUS codes, and two new
parameter value registries for two of the new parameters. All documented in=
Section 16 of the draft.

Note, that since the designated experts for this registry are both authors<= br> of this draft, we will be recusing ourselves from the review process. The responsible AD, Peter Saint-Andre, will appoint a stand-in for the review process.

--
Cyrus Daboo


--0016e6d9a1f9654da704bd80f34e-- From cyrus@bobobeach.com Sat Apr 14 08:01:50 2012 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A070421F8642 for ; Sat, 14 Apr 2012 08:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGtLYPR62cWV for ; Sat, 14 Apr 2012 08:01:49 -0700 (PDT) Received: from mail.cyrusharmon.org (mail.cyrusharmon.org [206.125.171.163]) by ietfa.amsl.com (Postfix) with ESMTP id D3E6221F863E for ; Sat, 14 Apr 2012 08:01:49 -0700 (PDT) Received: from mail.cyrusharmon.org (localhost [127.0.0.1]) by mail.cyrusharmon.org (Postfix) with ESMTP id A06D22E05A for ; Sat, 14 Apr 2012 08:01:43 -0700 (PDT) Received: from [192.168.1.102] (99-28-161-110.lightspeed.miamfl.sbcglobal.net [99.28.161.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cyrusharmon.org (Postfix) with ESMTP id 4542F2E059 for ; Sat, 14 Apr 2012 08:01:43 -0700 (PDT) From: Cyrus Harmon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2012 08:01:48 -0700 Message-Id: To: icalendar@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [icalendar] icalendar XML issues X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 15:01:50 -0000 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 . 1. T in patttern-duration and lack of operator precedence. My reading of , and of = section 3.3.6, and of section 2 of = suggests that the given = definition of duration is wrong: > # 3.3.6 DURATION >=20 > pattern-duration =3D xsd:string { > pattern =3D "(+|-)?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.):=20 > @@ -221,10 +221,10 @@ value-date-time =3D element date-time { > # 3.3.6 DURATION > =20 > pattern-duration =3D xsd:string { > - pattern =3D "(+|-)?P(\d+W)|(\d+D)?" > - ~ "(T(\d+H(\d+M)?(\d+S)?)|" > - ~ "(\d+M(\d+S)?)|" > - ~ "(\d+S))?" > + pattern =3D "(\+|-)?P((\d+W)|(\d+D))?" > + ~ "(T((\d+H(\d+M)?(\d+S)?)|" > + ~ "(\d+M(\d+S)?)|" > + ~ "(\d+S)))?" > } > =20 > value-duration =3D 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.=20 > type-until =3D element until { > type-date | > type-date-time > } >=20 Perhaps those should be value-date and value-date-time? > @@ -290,8 +290,8 @@ type-freq =3D element freq { > } > =20 > type-until =3D element until { > - type-date | > - type-date-time > + value-date | > + value-date-time > } > =20 > type-count =3D element count { >=20 3. Bogus Grammar/regex As discussed in the email message here: = = > type-byday =3D 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 =3D ( > ) > =20 > type-byday =3D element byday { > - xsd:integer?, > - type-weekday > + xsd:string { pattern=3D'-?[0-9]+(SU|MO|TU|WE|TH|FR|SA)' } > } > =20 > type-bymonthday =3D element bymonthday { >=20 Fixes the problem. 4. The following plus needs to be explicitly escaped: > @@ -370,7 +369,7 @@ value-uri =3D element uri { > # 3.3.14 UTC-OFFSET > =20 > value-utc-offset =3D element utc-offset { > - xsd:string { pattern =3D "(+|-)\d\d:\d\d(:\d\d)?" } > + xsd:string { pattern =3D "(\+|-)\d\d:\d\d(:\d\d)?" } > } > =20 > # UNKNOWN >=20 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 =3D element vtimezone { > property-tzid & > =20 > property-last-mod? & > - property-tzuurl? > + property-tzurl? > }, > element components { > - (component-standard | component-daylight) & > - component-standard* & > - component-daylight* > + (component-standard | component-daylight )+ > } > } >=20 6. Lack of operator precedence rears its ugly head again in = property-attach. > @@ -684,7 +681,7 @@ property-attach =3D element attach { > encodingparam? > }?, > =20 > - value-uri | value-binary > + ( value-uri | value-binary ) > } > =20 > # 3.8.1.2 Categories >=20 7. In property-categories, there is a bogus & -- there's nothing to = interleave! > @@ -692,7 +689,7 @@ property-attach =3D element attach { > property-categories =3D element categories { > =20 > element parameters { > - languageparam? & > + languageparam? > }?, > =20 > value-text+ >=20 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 =3D element dtend { > tzidparam? > }?, > =20 > - value-date-time | > - value-date > + ( value-date-time | value-date ) > } > =20 > # 3.8.2.3 Date/Time Due > @@ -867,8 +863,7 @@ property-due =3D element due { > tzidparam? > }?, > =20 > - value-date-time | > - value-date > + ( value-date-time | value-date ) > } > =20 > # 3.8.2.4 Date/Time Start > @@ -879,8 +874,7 @@ property-dtstart =3D element dtstart { > tzidparam? > }?, > =20 > - value-date-time | > - value-date > + ( value-date-time | value-date ) > } > =20 > # 3.8.2.5 Duration > @@ -1023,8 +1017,7 @@ property-recurid =3D element recurrence-id { > rangeparam? > }?, > =20 > - value-date-time | > - value-date > + ( value-date-time | value-date ) > } > =20 > # 3.8.4.5 Related-To > @@ -1066,8 +1059,7 @@ property-exdate =3D element exdate { > tzidparam? > }?, > =20 > - value-date-time+ | > - value-date+ > + ( value-date-time | value-date)+ > } > =20 > # 3.8.5.2 Recurrence Date/Times >=20 9. One more grouping -- finally, property-rdate needs value-date-time, = value-date and value-period grouped: > @@ -1078,9 +1070,9 @@ property-rdate =3D element rdate { > tzidparam? > }?, > =20 > - value-date-time+ | > - value-date+ | > - value-period+ > + ( value-date-time | > + value-date | > + value-period )+ > } > =20 > # 3.8.5.3 Recurrence Rule >=20 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: = . Thanks for all of the work on the iCalendar XML spec, Cyrus From mikeadouglass@gmail.com Tue Apr 24 06:42:22 2012 Return-Path: X-Original-To: icalendar@ietfa.amsl.com Delivered-To: icalendar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB621F8812 for ; Tue, 24 Apr 2012 06:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyqoDvHhY1it for ; Tue, 24 Apr 2012 06:42:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9DEF21F8814 for ; Tue, 24 Apr 2012 06:42:21 -0700 (PDT) Received: by yhkk25 with SMTP id k25so397107yhk.31 for ; Tue, 24 Apr 2012 06:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ShwBjeX76J3P4fCa5kpc5gR6yx1YNN2oapg00tZoFrI=; b=OEo7MPfOgeCS6r47veVc2AO8eRdP+m3kTSOHY6y1fBElAALM5vtMFcvbX8KynYFj34 DTozN0EZkO1VUi+keIFs8pIdIkZmvadVLKDlUaIR7kqDoJ6wHD/kajuWaz+rlGiHnmH4 6iylwd15fVWiXtJclhKh71Oixq0YmFSXIPUYmALnD2WiIwpb6z+oEnEXsqTNAsEFNrZ8 +IKtmxBvmCP6NxHBzWsuqtlpNd5dUo1bK0LZeJAm3lnaxU+XpqVWyye7KVvwHAbC1Z6n +/r7S9JpC8W/Z58un2Vo1QMVf9FmuxVB5jfmc6Q4zAE84AX5oTcVwN1vrxDuBdfOE8td HZJw== Received: by 10.236.72.138 with SMTP id t10mr5917369yhd.109.1335274941414; Tue, 24 Apr 2012 06:42:21 -0700 (PDT) Received: from [128.113.124.139] (crustacean-11.dynamic.rpi.edu. [128.113.124.139]) by mx.google.com with ESMTPS id u15sm11758218anb.9.2012.04.24.06.42.19 (version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 06:42:20 -0700 (PDT) Message-ID: <4F96ADBB.30904@gmail.com> Date: Tue, 24 Apr 2012 09:42:19 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Cyrus Harmon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: icalendar@ietf.org Subject: Re: [icalendar] icalendar XML issues X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 13:42:23 -0000 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. > > 1. T in patttern-duration and lack of operator precedence. > > My reading of, and of section 3.3.6, and of section 2 of 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: > >> 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:. > > Thanks for all of the work on the iCalendar XML spec, > > Cyrus > > > > _______________________________________________ > icalendar mailing list > icalendar@ietf.org > https://www.ietf.org/mailman/listinfo/icalendar