VSCHEDULE - Table for queries or not?

[sman@xxxxxxxxxxxx (Steve Mansour)]

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

begin:vcard 
adr;dom:;;;Mountain View;CA;94043;
n:Mansour;Steve
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
tel;fax:650-937-2103
tel;work:650-937-2378
x-mozilla-cpt:;0
fn:Steve Mansour
end:vcard