Subject: RE: CAP Searching Proposal

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Thu, 4 Mar 1999 09:36:58 -0800

John is correct -- DASL would work great.  The DAV/DASL model is not what
you assume, Frank.

DAV already allows for XML representations of properties.  Thus, we could
model "an appointment" (or any other iCalendar object) as a DAV resource,
with properties such as "dtstart" and "dtend".  Each iCalendar object is
modelled as a single resource, even if it has inline attachments.
(Attachments can also be linked to as separate objects.)  Resources have
properties, so an appointment would have properties such as "dtstart",
"dtend", "rrule".

DASL works well with this model -- it supports searches on properties such
as "dtstart" for values such as "greater than 1999-01-01".  It supports
combining queries on several properties.

Furthermore, I'd like to point out that you're making implementation
assumptions.  John suggested a logical protocol mapping, or model.  You
assumed that the back-end MUST store objects as XML.  In fact, this is not
the case -- the protocol model need only be mappable to the back-end model,
not identical.  Your back-end could store a user's entire calendar in one
file, if you think that's scalable, as long as your protocol engine can map
to the protocol model.  Your back-end could store appointments in some
binary format, as long as your engine can translate to the protocol format.

Here's what a DASL request to my calendar might look like.  This query would
search my calendar for all items that start after today.

SEARCH /private/lisal/calendar 
Host: myserver.com
Content-type: text/xml
Connection: close
Content-length: xxx

<?xml version="1.0"?>
<D:searchrequest xmlns:D="DAV:" xmlns:C="iCalendar">
  <D:response>
    <D:basicsearch>
      <D:select><D:prop><D:href></D:prop></D:select>
      <D:where>
        <D:gt>
          <D:prop><C:dtstart></D:prop>
          <D:literal>19990304T0000</D:literal>
        </D:gt>
      </D:where>
      <D:orderby>
        <D:order>
          <D:prop><C:dtstart></D:prop>
          <D:ascending>
        </D:order>
      </D:orderby>
    </D:basicsearch>
  </D:response>
</D:searchrequest>

Pretty simple, and it specifies ordering, scoping, wildcard matching, "like"
and "contains" for text searches, can limit the number of responses, and is
easily extensible.

I presented the DASL model at a previous CAP requirements authors meeting --
I can provide notes if you'd like to  refresh your memory.

Lisa

-----Original Message-----
From: Frank Dawson [mailto:[email-masked]]
Sent: Wednesday, March 03, 1999 7:50 PM
To: John Stracke; IETF Calendaring & Scheduling Mail List
Subject: Re: CAP Searching Proposal

>John Stracke wrote:
>
>It just occurred to me that an alternative would be to define a mapping of
the
>calendar information into the namespace of a Web server, and then search it
>with DASL (an HTTP-based protocol being developed for searching the
contents of
>a server).  The mapping would have the nice side effect that any calendar
entry
>would be available to downlevel browsers via GET, which makes for a
convenient
>migration path for implementors--just write a plugin/helper app that
>understands iCal, and you can get events into your calendar.  It's not
>particularly full-featured, but it's a useful start.
>

Won't scale. The XML representation of an iCalendar object is great for an
on the wire format but is not a practical representation for the backend.
For DASL, you would be searching through documents. If you took this
approach, then each parameter in an iCalendar property might have to be a
separate document (taken to extremes, but I hope you see the problem).

- - Frank

---

From: John Stracke <[email-masked]>
Date: Sun, 07 Mar 1999 23:03:43 +0000

> binary format, as long as your engine can translate to the protocol format.

Right.  A typical implementation might run off a database of some sort.  For
GET, it pulls out the database record and renders it as an iCalendar object;
for PROPFIND/PROPPATCH, it reads/sets the given property(-ies); for SEARCH, it
does a database search and presents the results.  (And, yes, it is perfectly
legal to have properties which are derived from the document; DAV calls them
"live properties".  Some standard examples include getcontenttype and
getcontentlength.)

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/