Subject: CAP: Scope of stored VQUERY.

From: Patrice Lapierre <[email-masked]>
Date: 15 Feb 2002 13:16:09 -0500

The "search", "modify", "move" and "delete" commands can
refer to a stored VQUERY by providing only the QUERYNAME.

e.g.,

  BEGIN:VQUERY
  QUERYNAME:MyQueryName 
  END:VQUERY

I see some issues with this:

(1) For localization and consistency with VCAR and VAGENDA, 
    it seems that a QUERYID should be used to identify the VQUERY, 
    and a property NAME should by used for a localizable 
    display name.

(2) QUERYNAME (or QUERYID in this proposition) is overloaded. 

      i. In a stored VQUERY it is used as an identifier for the
         current query.
         
     ii. When referring to a stored VQUERY it is used as a 
         search criteria (or pointer) to identify a stored 
         VQUERY.
    
    For (ii) it seems that a distinct property should be used
    (e.g., QUERYREF). This would also allow stored VQUERY to
    refer to another stored VQUERY.   
    
(3) It is not specified where the server should search for 
    the stored VQUERY.  It seems that a TARGET property 
    (or a parameter to QUERYREF) should be added to VQUERY 
    to indicate the location of a stored VQUERY, the omission 
    of the property would mean the VCALSTORE.

Examples of stored VQUERYs:   

  BEGIN:VQUERY
  QUERYID:query-01
  NAME:All VEVENTs.
  QUERY:SELECT * FROM VEVENT
  END:VQUERY

  BEGIN:VQUERY
  NAME:A stored query that makes reference to query-01
  NAME;LANGUAGE=fr-CA:Requete faisant reference a query-01
  QUERYID:query-foo
  QUERYREF:query-01
  TARGET:relcalid-1
  END:VQUERY

  To use a stored VQUERY with the QUERYID set to query-01, and located 
in the VAGENDA with the CALID relcalid-01, the following VQUERY should
be passed to the command:

   BEGIN:VQUERY
   QUERYREF:query-01
   TARGET:relcalid-01
   END:VQUERY

--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Feb 2002 19:44:21 -0700

>       i. In a stored VQUERY it is used as an identifier for the

It is used as the ID for the current query.

>          search criteria (or pointer) to identify a stored

In both cases it is an ID. You can give it an ID and
you can fetch it by ID. 

I could agree that we change it to QUERYID as it is an "ID"
and not a "NAME" , and add and optional NAME property to VQUERY.

Other than that I don't see that it is overloaded.

---

From: Patrice Lapierre <[email-masked]>
Date: 18 Feb 2002 11:45:05 -0500

> Patrice Lapierre wrote:
...
> Other than that I don't see that it is overloaded.

  In addition to QUERYID and NAME, can we also agree to add 
the TARGET property to specify where to look for a stored 
VQUERY? 

i.e., point (3) of the original post.

---

From: Doug Royer <[email-masked]>
Date: Mon, 18 Feb 2002 10:26:35 -0700

> i.e., point (3) of the original post.

TARGET is back in the BEGIN/END VCALENDAR section
for all objects to be sent to and from the CS.

As in:

	BEGIN:VCALENDAR
	VERSION:2.0
	TARGET:relcalid-foo
	METHOD:SEARCH
	...

See my recent posts.

---

From: Patrice Lapierre <[email-masked]>
Date: 18 Feb 2002 14:10:51 -0500

> for all objects to be sent to and from the CS.

These TARGETs indicate where to perform the action
i.e., in your example where to search for the components 
to return.

The location of the stored VQUERY to used is a different 
problem.It doesn't seem to be specified, where the CS should 
look for the stored VQUERYs.

For example, consider a "search" command with 5 targets 
that uses the following VQUERY:

 BEGIN:VQUERY
 QUERYID: MyQueryId
 END:VQUERY

What is the behavior?

(1) All 5 targets must contain a VQUERY with the property 
    QUERYID set to MyQueryId, and a different VQUERYs are used when 
    searching in each target.
or

(2) At least one of the 5 targets must contain a VQUERY with  
    its QUERYID set to MyQueryId, and the same query is reused
    is used for searching in all the targets.

  The first leads to duplication, the second to potential
ambiguities. These 2 approaches also reduces the the usefulness 
of storing VQUERYs directly in the VCALSTORE.

 It seems that the location of a stored VQUERY should be 
independent of the where the action is to be performed.

  The proposition was to add a TARGET in the VQUERY. This 
property would be independent of the target(s) in the command 
level. Its sole purpose is to indicate the location of the 
stored VQUERY to use.

For example, the VQUERY in the previous example would become:

  BEGIN:VQUERY
  QUERYID:MyQueryId
  TARGET:calidwherethequeryisstored
  END:VQUERY

and the "search" command would still contain the 5 targets 
indicating where the actual search is to be performed.

---

From: Doug Royer <[email-masked]>
Date: Mon, 18 Feb 2002 13:17:01 -0700

> look for the stored VQUERYs.

That I would think be an implementation detail.
I don't think it matters. If you have assess to 'MyQueryId',
then you can use it. If you don't - it fails.

---

From: Patrice Lapierre <[email-masked]>
Date: 18 Feb 2002 16:12:36 -0500

> then you can use it. If you don't - it fails.

 The question was WHERE can 'MyQueryId' be located (not do we 
have access to it). This is not an implementation detail. We can't 
achieve interoperability with stored VQUERY if CAP doesn't 
clearly specify their scope.

 If we can't reach a consensus on the matter, I propose that 
we remove stored VQUERY from first version of CAP.