Subject: Re: Parsing iCalendar

From: Frank Dawson/CAM/Lotus <[email-masked]>
Date: Mon, 24 May 1999 14:50:16 GMT

Joshua Ostrowalker wrote, in part:

>I have come across a problem when parsing properties in iCalendar (and
>it affects vCard as well) and was wondering if anyone else has come
>across the same sort of thing.
>
>There is well-defined behaviour when processing the ',', ';', and ':'
>characters... they either have to be escaped, or placed within a
>quoted-text value.  However, there is no specification for dealing with
>the '"' and '=' characters.

<fd>Slight clarificaiton needed. There is one behavior for dealing with
special characters in the property value strings and another one for
dealing with special characters in the property parameter value strings.
The COMMA character is used to as a value list delimiter in both behaviors.
The SEMICOLON is used as a parameter separator and also as a value field
separator. The COLON is only used as a property value separator. It only
needs to be escaped within the property parameter values. You are right,
that COMMA, SEMICOLON and COLON characters in the property parameter values
are addressed by placing the property parameter values in QUOTE (i.e.,
double quote) characters. However, in the property values strings they are
escaped using the REVERSE SOLIDUS or BACKSLASH character.</fd>

>With the '"' character, the parser would assume the following characters
>to be a quoted-text value, however, there are certainly cases where the
>'"' character would be inside the value.  This really becomes a problem
>if there are an odd number of '"' characters in the value string.

<fd>Quoted strings are only appropriate for the property parameter values
that contain the special characters. This will most likely appear in the
property parameter values of type "URI". Hence, all URI values in property
parameters must be placed in quoted strings, per iCalendar specification. A
QUOTE character in the property value string would be part of the value. I
don't think there is a problem here.</fd>
>The problem with the '=' character is that it is used by the parser to
>create name-value pairs (eg. "TYPE=TEL").  This isn't a problem in
>property parameters in which the first '=' will always be used for this
>purpose and all following ones can be assumed as part of the value.
>However, in iCalendar there are '=' characters used for this purpose in
>the property value.  Eg. in the RRULE and EXRULE.  Other property values
>can just be a text-value containing the '=' character.  Without creating
>a special case for properties that might use the '=' character as a
>token, we have a problem discerning the two.

<fd>This apparent problem may be the result of your parser design? A
content line in iCalendar and vCard should be parsed such that you first
separate the value part from the name/parameter part. This is identified by
the first unescaped/quoted COLON character found on the line. Then you need
to parse the name/parameter part to get the property name and the optional
parameter parts. The name part will identify what are the valid parameters.
The parameter part can be parsed to find the meta information you need to
correctly parse the value part.</fd>

<fd>There are quite a number of "text/directory" and also "text/calendar"
parsers out there. This doesn't seem to be an insurmountable problem for
others.</fd>
<fd>This is a good question to ask. Thank you for contributing it. You also
point out that the design of the common syntax used by both vCard and
iCalendar could have been designed to be simpler to understand and parse.
But in any case, I am not convinced that it is ambiguous to parse or that
we have a design problem with the current syntax.</fd>

-- Frank Dawson
(See attached file: myvcard-v30.vcf)

---

From: Joshua Ostrowalker <[email-masked]>
Date: Mon, 24 May 1999 13:14:18 -0400

> escaped using the REVERSE SOLIDUS or BACKSLASH character.</fd>

Agreed.  This is consistent with my understanding.

> don't think there is a problem here.</fd>

I see your point.  The parser can easily recognize a property parameter
value placed entirely within a quoted string and ignore any special
characters within that string.  Simple enough.  I was under the
impression that quoted strings would appear in property values as well.

> correctly parse the value part.</fd>

My parser design does extract the property name, property parameters,
and property value.  However, in an attempt to keep the parser small and
efficient, it has no concept of the context of the properties.  In other
words, it does not understand or recognize the particular properties and
what valid parameters/values can be used with that property.  Data
validation is done by the objects using the resultant data structures. 
As a result, the parser has no way of knowing that because the current
property being parsed is "RRULE" that the '=' characters in the property
value are significant.  Whereas with another property, the character
would just be part of the value.

I will be surprised if no one else has attempted to create a lightweight
parser like this.  In any case, I will have to work something out to
overcome this problem.
 
> we have a design problem with the current syntax.</fd>

I agree that vCard and iCalendar can be parsed without any ambiguity,
however the parser must be aware of the property specific syntax it is
processing.  I simply point out that there are some holes when
attempting to parse with a general syntax rule set.  Although it is very
close, I prefer to avoid "special cases" if I can.

Thank you for your thoughts, they are helpful.

Joshua Ostrowalker.