Re: VSCHEDULE - Table for queries or not?

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Mon, 19 Jul 1999 18:45:00 -0700
> From: sman@netscape.com (Steve Mansour)
> X-Accept-Language: en
> To: CalSched working group <ietf-calendar@imc.org>
> Subject: VSCHEDULE - Table for queries or not?
> List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
> 

> In Oslo, we discussed a VSCHEDULE table. It is described in the CAP
> draft. Conceptually, it can be thought of as the place where
> "scheduling" messages are kept until they handled or booked.
> 
> One issue that came up is whether or not VSCHEDULE should be used as a
> table in a query. That is, to query for components that have been
> scheduled (not booked) there are a couple of approaches. One way would
> look something like this:
> 
>      BEGIN:VQUERY
>      QUERY:SELECT (*);
>      FROM (*);
>      WHERE (METHOD = REQUEST OR  METHOD = PUBLSH OR
>      METHOD = ADD OR  METHOD = CANCEL OR  METHOD = REFRESH OR
>      METHOD = COUNTER OR  METHOD = DECLINECOUNTER);
>     END:VQUERY

Or more simply:

      BEGIN:VQUERY
      QUERY:SELECT (*);
      FROM (*);
      WHERE (METHOD != CREATE);
     END:VQUERY

> A couple of issues with with this query are:
> 
>   1. where are things like REFRESH messages kept? They aren't VEVENTs or
>      VTODOs or VJOURNALs.
     
Why not in the same table?

>  2. it is verbose (not a big deal, but keeping things concise is a good
>     goal)

The only "booked" appointment was "CREATE" (I think).

> Another way to do this might be:
>
>     BEGIN:VQUERY
>     QUERY:SELECT (*);
>      FROM (VSCHEDULE_TABLE);
>     END:VQUERY
>
> If we go this route, it means that VSCHEDULE gets a more formal role in
> our schema. It addresses the issue of where scheduling messages go until
> they are handled. But it was not clear that people wanted this.

It also means that the number of tables double. Don't forget that
a VEVENT is not just one table, its a collection of property and
x-component tables.

> Are there other issues with these approaches?  Which approach do you
> prefer?  Is there yet another way?

One set of tables. Use METHOD != CREATE or METHOD == CREATE.

> -Steve