ghopp
/
server_playground
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Another abandoned server code base... this is kind of an ancestor of taskrambler.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
106 Commits
1 Branch
0 Tags
51 MiB
 
 
 
 
 
 
Tree: f31b619095
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'f31b619095'
${ noResults }
server_playground/doc/www.w3.org/2000/01/foo.html

1443 lines
39 KiB
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<title>A quick look at iCalendar</title>
<link rel="stylesheet" href="/StyleSheets/base.css">
<!-- Changed by: tbl 19990524 -->
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body lang="en">
<p><a href="../"><img alt="W3" border="0" src="/Icons/WWW/w3c_home"
width="72" height="48"></a></p>
<h2>Building an RDF model:</h2>
<h1>A quick look at iCalendar</h1>
<p>I spent a few hours reading 50 pages of the iCalendar <a
href="http://www.ietf.org/rfc/rfc2445.txt">RFC2445</a> with a view to
evaluating proposals to put it into XML. My conclusion early on was that the
spec should be written in terms of <a href="/RDF">RDF</a> properties,
particularly as it has a clear property/value and parameter/value
structure.</p>
<blockquote style="background-color: #E1E1E1">
<p>Epilogue: see also the <a href="/2002/12/cal/">RDF Calendar
Workspace</a>, started late 2002, which takes a similar approach to this
"quick look" with running code, example data, and schemas.</p>
<address style="text-align: right">
<p><a href="/People/Connolly/">DanC</a></p>
</address>
</blockquote>
<h2><a name="Summary">Summary</a></h2>
<p>General points I noticed included</p>
<ol>
<li>The spec is full of x-extensions and IANA registries. these would all
be done using namespaces in XML</li>
<li>There is no summary of properties with their domains and ranges, which
would make the spec much clearer.</li>
<li>The parameter value type of "URI" implicitly causes dereferencing. This
is not clear from the spec but is assumed by the examples.</li>
<li>There are a few example of wanton reification, e.g. relationship
type.</li>
<li>Encodings, for cleanliness: the encoding is a relationship between two
objects, not the property of an object. Same comment on XML DSig.</li>
<li>I am concerned that I have not found very much protocol defining what
how agents interact, or what a message containing a calendar entry means.
But maybe that is elsewhere in the spec.</li>
</ol>
<h2><a name="Narrative">Narrative</a></h2>
<p>When looking for a natural representation of data in a given lanbguage in
RDF, one looks at first for the natural structureo fthe language. iCalndar
has a nested set of structures which naturally lend themselves to an RDF
graph interpretation. Apart from the noted exceptions, this translatoin leads
to a set of fairly logically defined RDF properties which could form
iCalendar's contribution to the semantic web.</p>
<p>A "calendar" consists of a set of components, such as events, and to-do
list and journal entries. These seem natural RDF types. (There is a choice
of whether to introduce special a specific property as the relationship
between the containing calendar and a specfic type of component, or whther to
use generic inclusion property and then specifythe subtype of the
component.)</p>
<p>The components have properties, even known as properties in iCalendar. Now
each property is in fact a complex thing which has a "value" (implcitly
named) and various "parameters" with names.</p>
<p>The named parameters are clearly easily represented as RDF properties.</p>
<p>The values are generally atomic things suhc as integers and strings, with
two exceptions. One is when the valeu if the URI and this implies that the
actual value is in a document with that URI. Another is that the value
datatype "rcecur"is a string which itself has a substructure. This recurrence
substructure takes the form of (guess what!) a set of attribute value
pairs.</p>
<h2><a name="Detailed">Detailed comments</a></h2>
<h3>2.3 Internationalization</h3>
<p>If this were XML this would be done for you, with Unicode and the various
encodings etc.</p>
<h3>4.1 Content Lines</h3>
<p>x-name and iana-token are extensions which XML would give for free using
namespaces.</p>
<p></p>
<p>"Each property defines the specific ABNF for the parameters allowed on the
property"</p>
<p>This makes general parsing impossible, direct conversion into XML
difficult. The only hope is that in fact that it not true and there is more
consistency than this line leads you to believe! This sounds like a remake of
the RFC822 problem which HTTP has in spades: One parser per page of the
spec.</p>
<h3><a name="4.1.3">4.1.3</a></h3>
<p>Here in the example</p>
<pre>ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE &lt;...remainder of "BASE64" encoded binary data...&gt;</pre>
<p>represents the encoding as though it were a property of the value. It
isn't: it is a relationship between the value and thestring expressed here.
Nicer to write that.</p>
<p></p>
<pre>&lt;attach&gt;
&lt;fmttype&gt;image/basic&lt;/fmttype&gt;
&lt;base64&gt;MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
[...]
&lt;/base64&gt;
&lt;/attach&gt;</pre>
<p>which would mean (in XML or RDF nonstriped strawman syntax) "Something is
attached which has content type image/basic and has base64 encoding
MMICCblablahblah".</p>
<p>Note that making base64 a first class relationship (subclass of encoding)
makes for brevity and extensibility: with a namespace I can introduce a new
one.</p>
<p>Value=binary has all these problems and is unnecessary. It is assumed in
base64. The earlier example with the URI</p>
<pre>ATTACH:http://xyz.com/public/quarterly-report.doc</pre>
<p>has an implicit dereferencing operation which it would be best to
expose:</p>
<p></p>
<pre>&lt;attach&gt;
&lt;uri&gt;http://xyz.com/public/quarterly-report.doc
&lt;/uri&gt;
&lt;/attach&gt;</pre>
<p>which means, consistently with the previous example, "something is
attached which is identified by URI http://...."</p>
<h3>4.2 property parameters</h3>
<p>Property parameter values MUST NOT contain a double quote. So I guess that
if i want to represent something which does... I attach it?</p>
<p></p>
<p>4.2.1</p>
<p>ALTREP and many of the following parameters can be represented obviously
as RDF properties. There needs to be an explicit property between the
introduced thing and any "value".</p>
<pre>&lt;description&gt;
&lt;altrep&gt;cid:asdfsadf@sdfsdaf.com&lt;/altrep&gt;
&lt;text&gt;Proext XYZ review meeting&lt;/text&gt;
&lt;description&gt;</pre>
<p>This becomes more obvious when you look at things like ATTENDEE.</p>
<p></p>
<p>4.2.2.</p>
<p>There seems to be an embryonic notion of type here ("properties with the
CAL-ADDRESS value type". I assume this can be formalized. it would be so much
simpler if this were tabulated.</p>
<p></p>
<p>4.2.3 Calendar User Type.</p>
<p>"mailto:" is usually in lower case. I thought it was in fact mandatory
that it be in lower case.</p>
<p></p>
<h3>4.2.5 Delegatees</h3>
<p>It is very confusing who ends up being the attendee notionally when both
delegates-to and -from are specified. Changing this to RDF, or contemplating
doing logical operations on this make one queasy about the solidity here.</p>
<p>ATTENDEE;DELEGATED-TO="mailto:a@y.com";DELEGATED-FROM="mailto:b@y.com":c@y.com</p>
<p>What is that equivalent to? I assume a@y.com goes to the meeting.</p>
<p></p>
<h3>4.2.7. See comment about 4.1.3</h3>
<h3>4.2.9 Free/Busy Time type</h3>
<p>make relationships first class</p>
<p>FREEBUSY=FREE: would be better as FREE: to reduce unnecessary complication
and allow extension.</p>
<p>If that section of the spec (4.2.9) seems to be self-referential and
difficult to read, that is also because it is describing an unnatural part of
a clumsy syntax. You don't say "I am free or busy as follows: 12-1pm and we
are talking about free here"! because RDF makes these things first class
objects and allow you to group FREE and BUSY and REALLYBUSY as subclases of
FREEBUSYTYPE life is easier.</p>
<h3>4.2.10 language</h3>
<p>xml:lang of course is what one would get for free with XML.</p>
<h3>4.2.15</h3>
<p>"RELATED-TO:RELTYPE=SIBLING" is a classic wanton reification. Just say
SIBLING:</p>
<p>Unfortunately the specification defined how calendars can be put into a
hierarchical relationship but doesn't say what that relationship *means*.
Maybe it does later in the spec.</p>
<p></p>
<h3>4.2.18 Sent By</h3>
<p>This is a relationship between a mailbox and another mailbox. It is that
the owner of one mailbox is being represented by the owner of another. Yes,
the message which asserted this data was probably sent by the agent, but the
term is misleading when it crops up in the data. This will cause confusion.
This is an example of the clarification which arises when you try to
represent the meaning of each rdf:property (icalendar:parameter)
independently.</p>
<h3>4.2.20 Value Data Type</h3>
<p>Note that the "URI" data type does not just constrain the value string to
be a valid URI, but indicated that the value string is the document you get
when you dereference the URI. Big difference, particularly when you automate
the base 64 decoding of something.</p>
<p></p>
<p>In general, note XML data types are defined by XML schema working group.
See draft @@. A comparison would be a useful exercise.</p>
<h3>4.8.4.1 <a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor105">ATTENDEE</a></h3>
<p>"If the LANGUAGE property parameter is specified, the identified language
applies to the CN parameter"</p>
<p>That is a terrible bit of design - a typical bit of interference between
different headers which is so temping for designers in these flat specs which
can't use nesting. How many other clauses like this are there?</p>
<p>LANGUAGE is, I must admit, a problem RDF has a bug with in general. It is
difficult to specify that a string has a language without making an
intermediate node that you don't want. This is, I realize the same as the
intermediate packaging problem: how to let a system know that what it asked
for is inside, but in the mean time, here is some useful information about
it. Here is a number and by the way it is prime. here is a GIF and by ht way
it is copyright. Here is a common name and by the way it is in English. It is
interesting to see the way iCalendar has the same problem</p>
<p></p>
<h3>4.8.4 <a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor111">UID</a></h3>
<p>There is linking between components of calendars which uses "UIDs" which
are mid URIs with the prefix removed. This is a bug</p>
<ul>
<li>It removes calendar objects from the URI space so that one cannot refer
to them with any other system which uses a URI -- unless you simply
assume that you can by using mid:</li>
<li>The spec is full of recommendations for making identifiers unique.</li>
<li>It has a given length of 255 characters which is y2k bug asking to
happen. Never specify fixed buffer sizes.</li>
</ul>
<p></p>
<h4>4.8.7.4 "<a
href="http://xml.resource.org/public/rfc/html/rfc2445.html#anchor125">SEQUENCE</a>"</h4>
<p>This is not in fact a property of an event, but is a property of a given
expression of the state of an event. the rule is that it must be incremented
by the organizer if the event changes significantly. In a peer-peer world, it
is not obvious what to do. </p>
<p></p>
<p></p>
<h2><a name="reviewed">Not reviewed</a></h2>
<p>I skipped most of the rest of the spec but a few very similar concerns
arose with some other parts I glanced at.</p>
<p></p>
<h2><a name="Conclusion">Conclusion</a></h2>
<p>It seems that RDF nodes for the calendar, for each event etc, and for each
icalendar:property is a fairly straightforward mapping.</p>
<p>A spinoff would be a vocabulary which would include useful reusable models
of time.The timezone work could be factored out if it is definitive.</p>
<p>Where RDF mapping was not obvious this sometimes coincided with unclear
aspects of the specification.</p>
<p>There are three levels at which the RDF mapping could be made</p>
<ol>
<li>A very direct mapping of the ical:properties and parameters onto
rdf:properties. Always use the same "value" rdf:property for the VALUE of
an ical:property. This would leave some things looking illogical in
RDF. It would be simple to define as a mapping, but the definitoin of
the properties would be strange in some cases.</li>
<li>Make a few simple adjustments to make the RDF more natural. Places to
lok for these arehese have been indicated with a @@ in the table. This
will make the mapping obvious to an iCal expert reading the RDF, but at
the same time make the RDF queries simpler and the properties more
reusable. It would move things like RELATED RELTYPE=X into a subclass
relationship between X and RELATED which allows generic RDF machinery to
process it.</li>
<li>An extensive rework in which the logic of rules was largely exposed in
RDFS or something stronger would of course be great.</li>
</ol>
<h3><a name="Appendix:1">Appendix: Node types</a></h3>
<table border="1">
<caption>Node types infered</caption>
<tbody>
<tr>
<td>party</td>
<td>implicit node in all properties with a CAL-ADDRESS value type.
(person or group: anything which can have a mailbox)</td>
<td></td>
</tr>
<tr>
<td>cal-address</td>
<td>A mailbox - normally mailto:...</td>
<td>URI</td>
</tr>
<tr>
<td>CU</td>
<td>Calendar user defined in <a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor29">CUTYPE</a></td>
<td></td>
</tr>
<tr>
<td>INDIVIDUAL, GROUP, RESOURCE, ROOM</td>
<td></td>
<td>CU</td>
</tr>
<tr>
<td>ldap-directory</td>
<td>starts "ldap:" (is this a standard?)</td>
<td>URI</td>
</tr>
<tr>
<td>mime-type</td>
<td></td>
<td>string</td>
</tr>
<tr>
<td>participation status</td>
<td>needs-action, accepted, declines, tentative, delegated, ... (an
enum type- could do better. <a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor38">Constraints
in the spec</a>.)</td>
<td>string</td>
</tr>
<tr>
<td>component</td>
<td>of a calendar</td>
<td></td>
</tr>
<tr>
<td>EVENT, TODO, etc</td>
<td></td>
<td>component</td>
</tr>
<tr>
<td>TimeProperty</td>
<td>DTSTART, DTEND, DUE, EXDATE, RDATE</td>
<td></td>
</tr>
<tr>
<td>Timezone</td>
<td>see <a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor45">TZID</a></td>
<td>string</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor62">icalobject</a></td>
<td></td>
<td></td>
</tr>
<tr>
<td>recur</td>
<td>defined by recurrence properties</td>
<td>-Really complex datatype could be broken down into RDF! Contains
its own nested attr/value structure.</td>
</tr>
</tbody>
</table>
<h2>Appendix: rdf:Properties - from "parameters"</h2>
<table border="1">
<caption>Properties from section 4</caption>
<tbody>
<tr>
<th>iCalendar name</th>
<th>domain</th>
<th>range</th>
<th>Notes</th>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor27">ALTREP</a></td>
<td>anything iCal property?</td>
<td>URI</td>
<td>altervative to body</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor28">CN</a></td>
<td>party</td>
<td>string</td>
<td></td>
</tr>
<tr>
<td>: (mailbox)</td>
<td>party</td>
<td>cal-address</td>
<td>Implicit node between a party and that part's mailbox. Represted by
"value" of property</td>
</tr>
<tr>
<td>CUTYPE - type</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor30">DELEGATED-FROM</a></td>
<td>party</td>
<td>cal-address</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor31">DELEGATED-TO</a></td>
<td>party</td>
<td>cal-address</td>
<td></td>
</tr>
<tr>
<td>DIR</td>
<td>party</td>
<td>URI</td>
<td></td>
</tr>
<tr>
<td>eightbit, base64</td>
<td>bits</td>
<td>text</td>
<td>text encodes bits accordingto RFC2045. Was value of encoding
"property"which was faulty model. Now, subclass of generic
ëncoding"property</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor33">ENCODING</a></td>
<td>bits</td>
<td>text</td>
<td>Only in schema, as superclass of eightbit and base64 See <a
href="#4.1.3">notes</a></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor34">FMTTYPE</a></td>
<td>document</td>
<td>mime-type</td>
<td>Why not call it content-type?! Applies to a document. Expect the
implit uri proprerty to tell you which object.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor35">FBTYPE</a></td>
<td></td>
<td></td>
<td>Supertype of the following</td>
</tr>
<tr>
<td>FREE, BUSY, BUSY-UNAVAILABLE, BUSY-TENTATIVE</td>
<td>?</td>
<td>time-interval</td>
<td>enum became subclasses FBTYPE property</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor36">LANGUAGE</a></td>
<td>string-or-doc</td>
<td>iso-language</td>
<td>Equivalent xml:lang</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor37">MEMBER</a></td>
<td>party</td>
<td>cal-address</td>
<td>group membership</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor38">PARTSTAT</a></td>
<td>party</td>
<td>enum</td>
<td>A status: part of some protocol?</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor39">RANGE</a></td>
<td>component</td>
<td></td>
<td>superclass only of ...</td>
</tr>
<tr>
<td>THIS-AND-PRIOR, THISANDFUTURE</td>
<td>component</td>
<td>date-time</td>
<td>subclass of RANGE (was qualifier)</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor40">RELATED</a></td>
<td>component</td>
<td>period@@</td>
<td>superclass of TRIGGER-FROM-START and TRIGGER-FROM-END?</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor41">RELTYPE</a></td>
<td>component</td>
<td>component</td>
<td>Superclass only, of</td>
</tr>
<tr>
<td>PARENT, CHILD, SIBLING</td>
<td>component</td>
<td>component</td>
<td>Subclases of RELTYPE. Hierarchical constraints. Semantics
unclear@@.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor42">ROLE</a></td>
<td>party</td>
<td>enum roleparam</td>
<td>Attendee; role=chair could it be better "chair?". Wait and see
wether it is a separate dimension.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor43">RSVP</a></td>
<td>party</td>
<td>boolean</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor44">SENT-BY</a></td>
<td>party</td>
<td>cal-address</td>
<td>Misleading. "Represented by" would be better. Some message was
sent.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor99">TZID</a></td>
<td>anything taking time or D</td>
<td>timezone</td>
<td>Yuk. should be part of the time string. Makes time complictaed</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor46">VALUE</a></td>
<td>string-or-doc</td>
<td>string</td>
<td>Superclass of the following</td>
</tr>
<tr>
<td>BINARY, BOOLEAN, CAL-ADDRESS, DATE, DATE-TIME DURATION, FLOAT,
INTEGER, PERIOD, RECUR TEXT, TIME, URI, UTC-OFFSET"</td>
<td>string</td>
<td>string</td>
<td>Specifies the datatype of an associated string</td>
</tr>
<tr>
<td>URI</td>
<td>document</td>
<td>URI</td>
<td>Subclass of VALUE but indicates the vale is the <em>content</em> of
the resouce identified.</td>
</tr>
<tr>
<td>calprop</td>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor64">icalobject</a></td>
<td></td>
<td>superclass for the following</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor75">VERSION</a></td>
<td>icalobject</td>
<td>string</td>
<td>subclass of calprop. unique.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor74">PRODID</a></td>
<td>icalobject</td>
<td>string</td>
<td>subclass of calprop
<p>semantics? unique.</p>
</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor72">CALSCALE</a></td>
<td>icalbobject</td>
<td>string</td>
<td>subclass of calprop</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor73">METHOD</a></td>
<td>icalobject</td>
<td>string</td>
<td>This is a hook for a protocol definition</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor65">VEVENT</a></td>
<td>icalobject</td>
<td>event</td>
<td>Property VENVENT of calendar implies component is of type event.
See spec for properties including this in their domain</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor66">VTODO</a></td>
<td>icalobject</td>
<td>todo</td>
<td>similar</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor67">VJOURNAL</a></td>
<td>icalobject</td>
<td>journal</td>
<td>similar</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor68">VFREEBUSY</a></td>
<td>icalobject</td>
<td>freebusy</td>
<td>similar</td>
</tr>
<tr>
<td>VTIMEZONE</td>
<td>icalobject</td>
<td>timezonedef</td>
<td>similar Definition of a timezone.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor70">VALARM</a></td>
<td>?component</td>
<td>alarm</td>
<td>can nest in component</td>
</tr>
<tr>
<td>CALSCALE</td>
<td>icalobject</td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<p></p>
<h2><a name="Appendix:">Appendix: Calendar component Properties</a></h2>
<p>See <a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor77">spec
4.8</a></p>
<p>The columns E, T etc indicate whether the subject of the property is
permitted to be an event, todo, journal, freebusy, alarm or timezone
component.</p>
<table border="1">
<caption>Properties of calendar components</caption>
<tbody>
<tr>
<td>iCalendar name</td>
<td>E</td>
<td>T</td>
<td>J</td>
<td>F</td>
<td><p>A</p>
</td>
<td>Tz</td>
<td>range</td>
<td>Notes</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor78">ATTACH</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td>y</td>
<td></td>
<td>text-or-doc</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor79">CATEGORIES</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>text</td>
<td>List of enums</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor80">CLASS</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>classification</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor81">COMMENT</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td>text</td>
<td>no comment</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor82">DESCRIPTION</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td>y</td>
<td></td>
<td>text</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor83">GEO</a></td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>float float</td>
<td>lat long. @@ Split into two properties?</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor84">LOCATION</a></td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>text</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor85">PERCENT-
COMPLETE</a></td>
<td></td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>integer</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor86">PRIORITY</a></td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>integer</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor87">RESOURCES</a></td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>text</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor88">STATUS</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>text</td>
<td>enum - see the spec.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor89">SUMMARY</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td>y</td>
<td></td>
<td>text</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor91">COMPLETED</a></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>date-time</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor92">DTEND</a></td>
<td>y</td>
<td></td>
<td></td>
<td>y</td>
<td></td>
<td></td>
<td>date-time or date</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor93">DUE</a></td>
<td></td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>date-time or date</td>
<td></td>
</tr>
<tr>
<td>DTSTART</td>
<td>y</td>
<td>y</td>
<td></td>
<td>y</td>
<td></td>
<td>y</td>
<td>date-time or date</td>
<td></td>
</tr>
<tr>
<td>DURATION</td>
<td>y</td>
<td>y</td>
<td></td>
<td>y</td>
<td>y</td>
<td></td>
<td>duration</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor96">FREEBUSY</a></td>
<td></td>
<td></td>
<td></td>
<td>y</td>
<td></td>
<td></td>
<td>period</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor97">TRANSP</a></td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>text</td>
<td>really boolean!</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor99">TZID</a></td>
<td>a</td>
<td>a</td>
<td>a</td>
<td>a</td>
<td>a</td>
<td>a</td>
<td>text</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor100">TZNAME</a></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>y</td>
<td>text</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor101">TZOFFFROM</a></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>y</td>
<td>utc-offset</td>
<td>like -0500</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor102">TZOFFTO</a></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>y</td>
<td>utc-offset</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor103">TZURL</a></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>y</td>
<td>URI</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor105">ATTENDEE</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>party</td>
<td>@@ If language is specified, it applies to CN: Kludge! @@@</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor106">CONTACT</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td>text</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor107">ORGANIZER</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td>party</td>
<td>Note in FREEBUSY the use is different</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor108">RECURRENCE-ID</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>date-time or date</td>
<td><strong>Could be a problem</strong>. Not a property of an event,
but its presence makes it a reference to a specific occurrence of a
repeated event.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor109">RELATED-TO</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>text (really URI whcih is UID of component)</td>
<td>Subclass only of PARENT, CHILD, SIBLING above.</td>
</tr>
<tr>
<td>PARENT , CHILD, SIBLING</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>see RELATED-TO</td>
</tr>
<tr>
<td>URI</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td>URI</td>
<td>document "associated with" component. For more information.</td>
</tr>
<tr>
<td>UID</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td>UID - URI without mid:</td>
<td>@@ Missing scheme!!! @@ replace with midL: URI</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor113">EXDATE</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>date-time or date</td>
<td>Excludes the dates given @@ implicit logic makes search logic
difficult.</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor114">EXRULE</a></td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>recur</td>
<td></td>
</tr>
<tr>
<td>RDATE</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>date-time or date</td>
<td></td>
</tr>
<tr>
<td>RRULE</td>
<td>y</td>
<td>y</td>
<td>y</td>
<td></td>
<td></td>
<td></td>
<td>recur</td>
<td></td>
</tr>
</tbody>
</table>
<p></p>
<table border="1">
<caption>Properties ofAlarm coponents and config control and misc</caption>
<tbody>
<tr>
<th>name</th>
<th>domain</th>
<th>range</th>
<th>Notes</th>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor118">ACTION</a></td>
<td>A</td>
<td>text</td>
<td>really an enum</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor119">REPEAT</a></td>
<td>A</td>
<td>Ainteger</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor120">TRIGGER</a></td>
<td>A</td>
<td>duration or date-time</td>
<td>See RELATED. @ Split into two properties?</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor122">CREATED</a></td>
<td>ETJ</td>
<td>date-time</td>
<td></td>
</tr>
<tr>
<td>DTSTAMP</td>
<td>ETJF</td>
<td>date-time</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor124">LAST-MODIFIED</a></td>
<td>ETJTz</td>
<td>date-time</td>
<td></td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor125">SEQUENCE</a></td>
<td>ETJ</td>
<td>integer</td>
<td>fuzzy rules for incrementing this</td>
</tr>
<tr>
<td><a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor128">REQUEST-STATUS</a></td>
<td>ETJF</td>
<td>text</td>
<td>eg 3.1.1</td>
</tr>
</tbody>
</table>
<p></p>
<table border="1">
<caption>Properties from <a
href="http://memory.palace.org/public/rfcs/html/rfc2445.html#anchor57">recurrence
rules</a></caption>
<tbody>
<tr>
<th>name</th>
<th>domain</th>
<th>range</th>
<th>Notes</th>
<td></td>
</tr>
<tr>
<td>UNTIL</td>
<td>rrule</td>
<td>text</td>
<td rowspan="13">text - all these are text with various constraints and
substructure</td>
<td></td>
</tr>
<tr>
<td>COUNT</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>INTERVAL</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYSECOND</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYMINUTE</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYHOUR</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYDAY</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYMONTHDAY</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYYEARDAY</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYWEEKNO</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYMONTH</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>BYSETPOS</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>WKST</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>FREQ</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<p></p>
<table border="1">
<caption>Properties of</caption>
<tbody>
<tr>
<th>name</th>
<th>domain</th>
<th>range</th>
<th>Notes</th>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<p></p>
<h2><a name="Examples">Examples</a></h2>
<pre>@@@</pre>
<h2 id="References">References</h2>
<p>There must be a much better list of resources for hacking calendar files
of various formats - but until I find it here are some random things I
found.</p>
<ul>
<li>The iCalendar RFC: <a
href="http://www.ietf.org/rfc/rfc2445.txt">RFC2445</a></li>
<li>Jetstream: <a
href="http://java.apache.org/jetspeed/api/org/apache/jetspeed/calendar/properties/package-summary.html">Java
classes in Apache's Jetstream</a> which represent the iCalendar
properties.</li>
<li>Open source <a
href="http://www.openhandheld.org/software.html#desktop">handheld
synchronisation software </a>at openhandheld.org</li>
<li><a href="http://www.palmos.com/dev/tech/docs/">PalmOs
documentation</a>; file formats (<a
href="/2000/10/Palm/fileformats.pdf">pdf copy</a>)</li>
<li><a href="/People/Connolly/drafts/web-research#when">Dan Connolly's
design research notebook on this</a></li>
</ul>
<p></p>
<p></p>
<hr>
<small>$Id: foo.html,v 1.47 2005/02/02 18:26:43 timbl Exp $</small>
<address>
<a href="/People/Berners-Lee">TimBL</a>, Oct 2001
</address>
</body>
</html>