Subject: VSCHEDULE - Table for queries or not?

From: [email-masked] (Steve Mansour)
Date: Mon, 19 Jul 1999 18:45:00 -0700

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

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.
  2. it is verbose (not a big deal, but keeping things concise is a good
     goal)

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.

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

-Steve

---

From: Doug Royer <[email-masked]>
Date: Mon, 26 Jul 1999 09:17:56 -0700 (PDT)

> Date: Fri, 23 Jul 1999 17:03:58 -0700
> From: [email-masked] (Steve Mansour)
> 
> Doug Royer wrote:
> 
> > >
> > >      BEGIN:VQUERY
> > >      QUERY:SELECT (*);
> > >      FROM (*);
> > Or more simply:
> >       WHERE (METHOD != CREATE);
> >      END:VQUERY
> 
> this will work provided there is no other value for METHOD that is not a
> scheduling method. Did we ever decide how tombstoned appointments will look.
> Wouldn't their method be DELETE ?  Even so,, we would have (METHOD != CREATE
> and METHOD != DELETE).

So far we only have booked or scheduled items.  If we invent a new
scheduling METHOD, then the original proposal will not work for the
same reason.

> > Why not in the same table?
> 
> They certainly could be in the same table. If no one wants to make a case for
> VSCHEDULE, we should keep them in the same table.
> 
> > 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.
> 
> yep
> 
> > One set of tables. Use METHOD != CREATE or METHOD == CREATE.
> 
> If anyone thinks that VSCHEDULE should be a table of its own, please speak up.
> I thought there were some folks in Oslo that spoke in favor of it. If not,
> we'll press on without VSCHEDULE.
> 
> -Steve

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL